Tarea 1 metodos y modelos de la reingenieria

5,591 views
5,414 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,591
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
154
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Tarea 1 metodos y modelos de la reingenieria

  1. 1. INSTITUTO TECNOLOGICO DE TUXTEPECINFORME SOBRE LAS DIFERENTES METODOLOGIAS DE LA REINGENIERIA DEL SOFTWARE CARRERA: ING. SISTEMAS COMPUTACIONALES MATERIA: REINGENIERIA DEL SOFTWARE PRESENTA: 08350619 RAMON DOMINGUEZ iris_bella_31@hotmail.com IRIS DEL CARMEN 08350626 JUAREZ AGUSTIN eli03_jan@hotmail.com ELIZABETH 08350635 DOMINGUEZ MOJICA XOCHILT MONSERRAT 083506 JARQUIN GONZALEZ zero_jga@hotmail.com ABDIELMarzo 2012 1
  2. 2. INDICEINDICE.……………………………………………………………………2INTRODUCCION………………………………………………………...3ANALISIS DE OPCIONES PARA REINGENIERIA (OAR)……….….4MODELO HERRADURA……………………………………………….. 7MODELO CICLICO……………………………………...…………….. 11CONCLUSION.……………………………………...…………...…….. 14BIBLIOGRAFIA……………………………………………………….... 15 2
  3. 3. INTRODUCCIONExisten varios métodos y modelos que son utilizados para llevar a cabo de manerasatisfactoria la actividad de reingeniería.La metodología surge como consecuencia de la aplicación de procesos dereingeniería del software tradicionales, sobre una aplicación científica deconsiderables dimensiones y por la no consecución de buenos resultadosmediante esas técnicas, que en la mayoría de los casos cuenta con una probadavalidez, pero que aplicadas al tipo de aplicación del caso de estudio no fueronsatisfactoriasEste texto explica de una forma muy breve los métodos y modelos que sonutilizados para llevar a cabo de manera satisfactoria la actividad de reingeniería. Alcomienzo del texto se alude al método de análisis de opciones para reingeniería(OAR por sus siglas en ingles de Options Analysis for Reingeneering) dando sudefinición y explicando la necesidad de aplicarlo, se menciona de forma breve lasactividades principales y especializadas de este método así como la estructura deellas. En los siguientes dos subtemas se trata a dos modelos utilizados para lareingeniería: El modelo herradura y el modelo cíclico, explicando brevemente losniveles o actividades de cada uno. 3
  4. 4. ANÁLISIS DE OPCIONES PARA REINGENIERÍA (OAR)OAR es un método sistemático, de arquitectura central y de toma de decisionespara la identificación y extracción de componentes dentro de grandes y complejossistemas de software. La extracción envuelve rehabilitación de partes de unsistema viejo para su reúso.OAR identifica componentes de arquitectura potencialmente relevantes y analizalos cambios requeridos para usarlos en una línea de producción de software onuevas arquitecturas de software.En esencia, OAR proporciona un conjunto de opciones de extracción junto conestimación de costos, esfuerzo y riesgos asociados con estas opciones. El métodoOAR consiste de cinco actividades principales con tareas escalables. Esas tareasson representadas en la Figura 1.Análisis de las opciones de reingeniería (OAR) es un proceso sistemático,centrado en la arquitectura. Cinco OAR las actividades de identificar loscomponentes potenciales, estimar el costo de la minería, y evaluar el esfuerzonecesario para reutilizar los componentes existentes. OAR revela implícitasupuestos interesados, restricciones y otros conductores principales que afectan ala minería de los componentes, dando así a los administradores informaciónsobre esta compleja tarea. 4
  5. 5. Las cinco principales actividades se describen a continuación:1.- Establecimiento del contexto de extracción (ECE).Es importante para el equipo de OAR entender el contexto para la extracción.Cómo un resultado, la primer actividad de OAR consiste en entrevistar a losaccionistas y estudiar la línea de producción de la organización o nuevosrequerimientos de sistema, base heredada y expectativas para la extracción decomponentes heredados. Estos esfuerzos establecen una línea base de unconjunto de metas, expectaciones y necesidades de componentes. Esto tambiéndescubre los controladores de programa y técnicos para la toma de decisiones.2.- Inventario De Componentes (IC).Después del ECE, el equipo OAR identifica los componentes del sistemaheredado que potencialmente pueden ser extraídos para usarlos en una línea deproducción o en una nueva arquitectura de software.Durante esta actividad, los miembros del equipo identifican componentes de líneasde producción necesarios y evalúan los componentes heredados basados en esoscriterios. Aquellos que no descubran los criterios están incapacitados paracontinuar con el proceso de reingeiería. Esta actividad resulta en un inventario delos componentes heredados candidatos. La actividad de IC tiene seis tareas: 1. Identificar características de los componentes necesarios 2. Identifica las características satisfactorias de los componentes: 3. Compara las necesidades de componentes: 4. Inventario de componentes candidatos: 5. Produce tópicos de extracción 6. Revisión del calendario OAR: 5
  6. 6. 3.- Análisis de componentes candidatos (ACC).El siguiente paso de los miembros del equipo es analizar el conjunto decandidatos de componentes heredados para extraer los tipos de cambios que sonrequeridos. Esta actividad tiene seis tareas: 1. Selección de componentes deseables. 2. Identifica los componentes "Tal como están y de caja negra" 3. Identifica componentes de caja blanca. 4. Determina cambios requeridos: 5. Producción de tópicos de extracción: 6. Revisa el calendario OAR:4 Plan de opciones de extracción (POE).Dado el conjunto de componentes candidatos analizados, el equipo desarrollaralternativas para la extracción basada en consideraciones de calendario, costo,esfuerzo, riesgo y recursos. El equipo OAR también filtra una vez más loscomponentes candidatos y analiza el impacto de agregación de diferentescomponentes. El POE tiene siete tareas: 1. Selecciona componentes favorables: 2. Ejecución de intercambio de componentes: 3. Forma opciones de componentes: 4. Determina costos comparativos y esfuerzos: 5. Analiza dificultad o riesgo: 6. Producción de tópicos de extracción: 7. Revisa el calendario OAR:5 Selección de opciones de extracción (SOE).Finalmente, los miembros del equipo seleccionan la mejor opción de extracción ocombinación de opciones para programas y consideraciones técnicas. Después de 6
  7. 7. evaluar cada opción de extracción, ellos preparan un resumen que presenta yjustifica sus elecciones. La actividad SOE tiene cinco tareas: 1. Elegir la mejor opción: 2. Verificación de opción: 3. Identifica componentes necesarios satisfechos. 4. Presentación de descubrimientos. 5. Producción de resumen. EL MODELO HERRADURALos tres procesos básicos: análisis de un sistema existente, transformación lógicay desarrollo de un nuevo sistema, forman la base del modelo de herradura. Comopuede observarse en la Figura 2, el primer proceso sube el extremo izquierdo dela herradura, el segundo cruza la parte superior y el tercero baja por el extremoderecho de la herradura. La riqueza del modelo de herradura son los tres nivelesde abstracción que pueden ser dotados para las descripciones lógicas.Conceptualmente, este puede ser a través de un conjunto de herraduras anidadas.Las descripciones lógicas pueden ser artefactos tan concretos y simples como elcódigo fuente del sistema o tan complejos y abstractos como la arquitectura delsistema. El propósito de la metáfora visual es para integrar las vistas dereingeniería a nivel de código y arquitectónico del mundo 7
  8. 8. En su más pura y completa forma, el primer proceso recupera la arquitectura pormedio de la extracción de artefactos desde el código fuente. Esta estructurarecuperada es analizada para determinar si esta se adapta a la arquitectura antesdiseñada. La arquitectura descubierta también es evaluada con respecto a unnúmero de calidad de atributos tales como rendimiento, modificabilidad, seguridado confiabilidad.El segundo proceso es la transformación de arquitectura. En este caso, laarquitectura antes construida es recuperada y es reingeniería para hacerla unanueva arquitectura deseable. Esta es reevaluada contra las metas de calidad delsistema y sujetas a otras restricciones organizacionales y económicas.El tercer proceso del modelo de herradura usa el "Architecture-BasedDevelopment (ABD)" [Bass99] para ejemplificar la arquitectura deseable. En esteproceso, ya empaquetados los tópicos son decididas e interconectadas lasestrategias elegidas. Los artefactos a nivel de código del sistema de informaciónheredado son normalmente tapados o reescritos para adaptarlos dentro de lanueva arquitectura. 8
  9. 9. Hay tres niveles de la herradura:1. "Code-estructura de la representación", que incluye el código fuente y losartefactos tales como árboles de sintaxis abstracta (AST) y gráficos de flujoobtenida a través de análisis y memoria operaciones analíticas. En el nivel decódigo existen dos sub-niveles, transformación textual (o basado en cadena) ytransformación basado en el árbol de sintaxis. Mientras algunos métodos hacendistinciones entre transformaciones "1A" textual (sintáctico) y "1B" AST-based(semántico), el modelo herradura los considera a ambos dentro del contexto deestructura de código.2. "La función de nivel de representación", que describe la relación entre elprogramas de funciones (llamadas, por ejemplo), los datos (la función y lasrelaciones de datos) y los archivos (Agrupaciones de funciones y datos).Transformaciones a nivel funcional (nivel "2") tiene que ver con el re-empaquetadode funcionalidad (por ejemplo, migrar desde un diseño funcional a un diseñoorientado a objeto o migrar desde un modelo de base de datos relacional a unmodelo orientado objeto). La encapsulación de un modulo de funcionalidad por undiferente ambiente, es un ejemplo de transformación a nivel funcional.Transformaciones a nivel funcional va más allá de simples transformaciones a laestructura del código, pero no va más allá que una transformación de arquitectura.Ellos son elegidos cuando grandes unidades de funcionalidad pueden sersalvados poniéndolos dentro de un nuevo contexto.3. "Concepto" de nivel, lo que representa grupos de la función y artefactos decódigo de alto nivel que se montan en los subsistemas de componentesrelacionados con la arquitectura o los conceptos.Las transformaciones a nivel de arquitectura (nivel "3") involucran cambios a losbloques básicos de la arquitectura. Estos incluyen los modelos básicos deinteracción incluyendo los tipos de componentes, los conectores usados, laasignación de funcionalidad y el modelo en tiempo de ejecución de control y datos.El nivel de arquitectura es el más abstracto y lejos del alcance de lastransformaciones. Las transformaciones a nivel de arquitectura son hechas 9
  10. 10. cuando es necesario un cambio a la estructura principal debido a las principalesmodificaciones o deficiencias en los sistemas de información heredados. Lastransformaciones generalmente traen mayores compromisos de tiempo y recursos,pero también trae consigo grandes beneficios.Interacción entre niveles.Las transformaciones a la estructura del código se pueden dar sin hacer cambiosde nivel funcional o cambios a la arquitectura. Las transformaciones del nivel másbajo soportan las transformaciones de niveles más altos. Con esta vista multi-nivelde transformaciones, las transformaciones a la arquitectura son normalmente elcontexto en los cuales toman parte niveles más bajos. Sin embargo, lastransformaciones de nivel superior no soportan transformaciones de nivel bajosporque esas transformaciones se pueden dar independientemente de lastransformaciones de niveles superiores. De hecho, uno de los principalespropósitos del modelo herradura es elevar el nivel de abstracción y brindarnoticiones de la arquitectura para las tareas de reingeniería. 10
  11. 11. MODELO CÍCLICOEste modelo propuesto en define seis actividades, las cuales se muestran en laFigura 4. En algunas ocasiones, estas actividades se producen de formasecuencial y lineal, pero esto no siempre es así. Por ejemplo, puede ser que laingeniería inversa (la comprensión del funcionamiento interno de un programa)tenga que producirse antes de que pueda comenzar la reestructuración dedocumentos.Actividades que se definen en el modelo cíclico: Análisis de inventario,Reestructuración de documentos, Ingeniería inversa, Reestructuración de código,Reestructuración de datos e Ingeniería directa.1 Análisis de inventario. Todas las organizaciones de software deberán disponerde un inventario de todas sus aplicaciones. El inventario puede que no sea másque una hoja de cálculo con la información que proporciona una descripcióndetallada (de todas las aplicaciones activas. 11
  12. 12. Es importante destacar que el inventario deberá revisarse con regularidad. Elestado de las aplicaciones puede cambiar en función del tiempo y, comoresultado, cambiarán también las prioridades para la reingeniería.2 Reestructuración de documentos. Una documentación escasa es la marca demuchos sistemas de información heredados. ¿Qué se puede hacer al respecto? Opción 1: La creación de documentación consume muchísimo tiempo. El sistema funciona, y ya nos ajustaremos con lo que se tiene. Opción 2: Es preciso actualizar la documentación, pero se dispone de recursos limitados. Se utilizará un enfoque "del tipo documentar si se modifica Más bien se documentarán por completo aquellas partes del sistema que estén experimentando cambios en ese momento. La colección de documentos útil y relevante irá evolucionando con el tiempo. Opción 3: El sistema es fundamental para el negocio, y es preciso volver a documentarlo por completo. En este caso, un enfoque inteligente consiste en reducir la documentación al mínimo necesario.3 Ingeniería inversa.En esencia, una ingeniería inversa con éxito precede de una o másespecificaciones de diseño y fabricación para el producto, mediante el examen deejemplos reales de ese producto.La ingeniería inversa del software es el proceso de análisis de un programa con elfin de crear una representación de programa con un nivel de abstracción máselevado que el código fuente. La ingeniería inversa se extraerá del programaexistente información del diseño arquitectónico y de proceso, e información de losdatos.4 Reestructuración del código.El tipo más común de reingeniería es la reestructuración del código. Para llevar acabo esta actividad, se analiza el código fuente mediante una herramienta dereestructuración, se indican las violaciones de las estructuras de programaciónestructurada, y entonces se reestructura el código (esto se puede hacer 12
  13. 13. automáticamente). El código reestructurado resultante se revisa y se compruebapara asegurar que no se hayan introducido anomalías. Se actualiza ladocumentación interna del código.5 Reestructuración de datos.Un programa que posea una estructura de datos débil será difícil de adaptar y demejorar. A diferencia de la reestructuración de código, que se produce en un nivelrelativamente bajo de abstracción, la estructuración de datos es una actividad dereingeniería a gran escala. En la mayoría de los casos, la reestructuración dedatos comienza por una actividad de ingeniería inversa. La arquitectura de datosactual se analiza minuciosamente y se definen los modelos de datos necesarios.Se identifican los objetos de datos y atributos y, a continuación, se revisan lasestructuras de datos a efectos de calidad.Cuando la estructura de datos es débil se aplica una reingeniería a los datos.Dado que la arquitectura de datos tiene una gran influencia sobre la arquitecturadel programa, y también sobre los algoritmos que los pueblan, los cambios endatos darán lugar invariablemente a cambios o bien de arquitectura o bien decódigo.6 Ingeniería directa (foward engineering).En un mundo ideal, las aplicaciones se reconstruyen utilizando un "motor dereingeniería" automatizado. En el motor se insertaría el programa viejo, que loanalizaría, reestructuraría y después regeneraría la forma de exhibir los mejoresaspectos de la calidad del software.La ingeniería directa, que se denomina también renovación o reclamación, nosolamente recupera la información de diseño de un software ya existente, sinoque, además, utiliza esta información en un esfuerzo por mejorar su calidad global.En la mayoría de los casos, el software procedente de una reingeniería vuelve aimplementar la funcionalidad del sistema existente, y añade además nuevasfunciones y/o mejora el rendimiento global. 13
  14. 14. CONCLUSIONLa reingeniería no es una actividad que se lleva a cabo de la noche a la mañana,además implica una gran inversión de esfuerzo, tiempo y recursos. Es por ello quees necesario planear de una manera muy cuidadosa todo el proceso. Este procesose inicia con la justificación del proyecto de reingeniería, en el cual se tiene queanalizar cada sistema candidato para así obtener una lista de aplicacionesordenada según sus prioridades. Una vez obtenida la lista, se hace la estimaciónde costes que serán necesarios para modificar todos los componentes. Por últimose comparan los costes con los beneficios esperados.En la reingeniería de software existen métodos y modelos que permiten que estaactividad se pueda desarrollar de una manera bien direccionada para poder crearuna nueva aplicación con un alto nivel de calidad, fiabilidad y plusvalía. En estosmétodos y modelos se puede observar varios puntos en común siendo uno de losmás importantes la "reconstrucción de la arquitectura", ya que esta es la que nosva a brindar la compresión del sistema al que se le va aplicar reingeniería parapoder crear una clara imagen de lo que se va a rediseñar y así poder planificar lasactividades que se llevaran a cabo durante toda la actividad de reingeniería.Ninguna de las actividades llevadas a cabo durante la reingeniería de un sistemaes fácil, es por ellos que cada una debe de estar muy bien planeadas antes deemprenderse y la reconstrucción de la arquitectura no es la excepción. Es por elloque para realizar la reconstrucción de la arquitectura de un sistema de informaciónheredado se recomienda tener bien definidas las metas y objetivos, obtener unavisión general de la arquitectura, identificar y usar la documentación existente, einvolucrar a personas familiarizadas con el sistema. 14
  15. 15. BIBLIOGRAFIA  http://ri.biblioteca.udo.edu.ve/bitstream/123456789/1810/1/TESIS_YG.pdf  http://repository.cmu.edu/cgi/viewcontent.cgi?article=1573&context=sei  http://www.monografias.com/trabajos17/reingenieria-software/reingenieria- software.shtml 15

×