Informe reing

532 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
532
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Informe reing

  1. 1. S.E.P. D.G.E.S.T. S.N.E.S.T. INSTITUTO TECNOLÓGICO de Tuxtepec INFORMES SOBRE LAS DIFERENTES METODOLOGIAS DE LA REINGENIERIA DEL SOFTWARE UNIDAD III Métodos y modelos de la reingeniería del software CARRERA: Ingeniería en Sistemas Computacionales MATERIA: Reingeniería de Software PRESENTAN: Bolaños Duran Juan Carlos Pérez Antonio Julio Cesar Vázquez Gómez Guadalupe Vicente Azamar Timoteo Zarate Castillo Celeste Yamín CATEDRÁTICO: L. I. María de los Ángeles Martínez MoralesISC – 2010/01 Marzo de 2012
  2. 2. NOMBRE DEL CORREO ELECTRONICO N° DE CONTROL ALUMNO Bolaños Duran Juan scorpion_03k@hotmail.com Carlos 08350634 Pérez Antonio Julio jcpat_10@hotmail.com Cesar 08350355 Vázquez Gómez Guadalupe lupev_g@hotmail.com 08350380 Vicente Azamar Timoteo alkon_1_15@hotmail.com 08350384Zarate Castillo Celeste Yamín celeste_tux@hotmail.com 08350385 2
  3. 3. INDÍCEINTRODUCCIÓN .............................................................................................................................. 4MÉTODOS Y MODELOS DE LA REINGENIERIA DE SOFTWARE DE SOFTWARE ......... 5EL MÉTODO ANÁLISIS DE OPCIONES PARA REINGENIERÍA ............................................ 5EL MODELO HERRADURA ........................................................................................................... 8EL MODELO CÍCLICO .................................................................................................................. 11CONCLUSION ................................................................................................................................ 14REFERENCIA ................................................................................................................................. 15 3
  4. 4. INTRODUCCIÓNEn este apartado se explican losmétodos y los modelos de la reingeniería delsoftware. Organizado con puntos importantes para el mayor entendimiento de loslectores.Tratamos de dar una visión general de lo que es la reingeniería de software ycuáles sus métodos y modelos para saber en que momento podemos adquirirlo enuna operación del cual se ejecuta y saber si es de eficiencia y conocer sudisponibilidad.Los métodos y los modelos surgen como una consecuencia de laaplicación de los procesos dentro de la reingeniería del software, su aplicaciónconsiste en las técnicas para verificar la aprobación del caso de estudio.La reingeniería de software debe ser entendida como un proceso mediante el cualse mejora un software existente haciendo uso de técnicas de ingeniería inversa yrestructuración de código. Para llevar a cabo la reingeniería del Software se puederealizar a través del: (1) método de análisis de opción para reingeniería, (2) elmodelo herradura y (3) el modelo cíclico.Donde el método de análisis de opción para reingeniería es el encargado de tomarlas decisiones para la identificación y la extracción de componentes del sistema,mientras que el modelo herradura se basa del análisis, transformación y desarrollodel sistema, y por ultimo el modelo cíclico consta de seis actividades la cualexplicaremos en este apartado.Este documento cuenta con principales características de los modelos y losmétodos, esperando que sea entendible cada punto y así poder tener mayorconocimiento del tema. 4
  5. 5. MÉTODOS Y MODELOS DE LA REINGENIERIA DE SOFTWAREDESOFTWAREEL MÉTODO ANÁLISIS DE OPCIONES PARA REINGENIERÍASus siglas en ingles, Options analysis for reengineering, es un método sistemático,de arquitectura central y de toma de decisiones para la identificación y extracciónde componentes dentro de grandes y complejos sistemas de software. Laextracción envuelve rehabilitación de partes de un sistema anterior para su re-uso.El análisis de opciones para reingeniería (OAR) identifica componentes dearquitectura potencial relevantes y analiza los cambios requeridos para usarlos enuna line de producción de software o nuevas arquitecturas de software. OARproporciona un conjunto de opciones de extracción junto con estimación decostos, esfuerzos y riesgos asociados con estas opciones.La extracción de componentes casi siempre había sido discutido como unaalternativa, pero requería el entendimiento de que tipos de componentes valían lapena extraer y como se debería extraer. Estos puntos son importantes para larealización de la extracción: Componentes existentes casi siempre eran pobremente estructurados y documentados. Componentes existentes diferían en niveles de granuralidad. Ho había una guía clara sobre cómo salvar componentes.Este tipo de método consiste de cinco actividades principales con tareasescalables.Establecimiento Del Contexto De Extracción (ECE): Es importante para el equipode OAR entender el contexto para la extracción. Cómo un resultado, la primeractividad de OAR consiste en entrevistar a los accionistas y estudiar la línea deproducción de la organización o nuevos requerimientos de sistema, baseheredada y expectativas para la extracción de componentes heredados. 5
  6. 6. Inventario De Componentes (IC): En esta actividad los miembros del equipoidentifican componentes de líneas de producción necesarios y evalúan loscomponentes heredados basados en esos criterios. Aquellos que no descubranlos criterios están incapacitados para continuar con el proceso de reingeniería.Esta actividad resulta en un inventario de los componentes heredados candidatos.La IC consta de las siguientes tareas:  Identificar características de los componentes necesarios.  Identifica las características satisfactorias de los componentes.  Compara las necesidades de componentes.  Inventario de componentes candidatos.  Produce tópicos de extracción.  Revisión del calendario OAR.Análisis De Componentes Candidatos (ACC): En este paso es analizar el conjuntode candidatos de componentes heredados para extraer los tipos de cambios queson requeridos. Sus tareas principales son:  Selección de componentes deseables.  Identifica los componentes Tal como están y de caja negra.  Identifica componentes de caja blanca.  Determina cambios requeridos.  Producción de tópicos de extracción.  Revisa el calendario OAR.Plan De Opciones De Extracción (POE): Dado el conjunto de componentescandidatos analizados, el equipo desarrollar alternativas para la extracciónbasada en consideraciones de calendario, costo, esfuerzo, riesgo y recursos. ElPOE consta de las siguientes tareas:  Selecciona componentes favorables.  Ejecución de intercambio de componentes.  Forma opciones de componentes. 6
  7. 7.  Determina costos comparativos y esfuerzos.  Analiza dificultad o riesgo.  Producción de tópicos de extracción.  Revisa el calendario OAR.Selección De Opciones De Extracción (SOE): Al final de seleccionan la mejoropción de extracción o combinación de opciones para programas yconsideraciones técnicas. Después de evaluar cada opción de extracción, ellospreparan un resumen que presenta y justifica sus elecciones. SOE tiene cincotareas que son:  Elegir la mejor opción.  Verificación de opción  Identificar componentes necesarios satisfechos  Presentación de descubrimientos.  Producción de resumen.Cada actividad tiene un potencial de conjunto de actividades especializadas paradireccionar circunstancias que pueden de otro modo imposibilitar la cumplimientode la actividad.Cada actividad esta compuesta de tareas y sub-tareas diseñadas para contestarun conjunto de preguntas de actividades especificadas. Las actividades estánestructuradas de acuerdo a un formato “EITVOX”.Los criterios de entrada se analizan para determinar si hay suficiente datos ytecnológica disponible para ejecutar la actividad exitosamente. Si no es satisfechoel criterio la tarea especializada debe ser desarrollada.Los criterios de validación son dadas después de que las tareas fueroncomplementadas. Los criterios de salida son sugeridos antes de complementar elestablecimiento del contexto de extracción. 7
  8. 8. EL MODELO HERRADURAAnálisis de un sistema existente, transformación lógica y desarrollo de un sistema,son los tres procesos básicos para formar la base del modelo de herradura. Elprimer proceso sube el extremo izquierdo de la herradura, el segundo cruza laparte superior y el tercero baja por el extremo derecho de la herradura.Los tres niveles de abstracción que pueden ser adoptados para las descripcioneslógicas es la riqueza del modelo de herradura. Las descripciones lógicas puedenser artefactos tan concretos y simples como el código fuente del sistema o tancomplejos y abstractos como la arquitectura del sistema.El propósito de la metáfora visual es para integrar las vistas de reingeniería a nivelde código y arquitectónico del mundo.El primer proceso recupera la arquitectura por medio de la extracción de artefactosdesde el código fuente. Esta estructura recuperada es analizada para determinarsi esta se adapta a la arquitectura antes diseñada. La arquitectura descubiertatambién es evaluada con respecto a un número de calidad de atributos tales comorendimiento, modificabilidad, seguridad o 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 revaluada contra las metas de calidad delsistema y sujetas a otras restricciones organizadas y económicas.El tercer proceso usa el “Architectura-Based DEvelopment (ABD), para ejemplificarla arquitectura deseable. En este proceso, ya empaquetados los tópicos sondecididas e interconectadas las estrategias elegidas. Los artefactos a nivel decódigo del sistema de información heredado son normalmente tapados o rescritospara adaptarlos dentro de la nueva arquitectura.El modelo de herradura consta de tres niveles que son: 8
  9. 9.  Representación de la estructura de código: este incluye el código fuente y artefactos tales como arboles de sintaxis abstractas y diagramas de flujo obtenidos a través del análisis gramatical y operaciones analíticas de rutina.  Representación del nivel funcional: es el cual describe la relación entre las funciones del programa, datos y archivos.  Nivel conceptual: aquí se representa grupo tanto de funciones y artefactos de nivel de código que son ensamblados dentro de subsistemas de componentes relacionados o conceptos.El modelo completo no solo hace transformaciones en el nivel de arquitectura,también lo hace en los niveles subsidiarios. Los ejemplos simples detransformaciones a cada nivel se mencionan a continuación:Nivel De Código: Existen dos sub-niveles, transformación textual y transformaciónbasado en el árbol de sintaxis. Mientras algunos métodos hacen distinciones entretransformaciones “1A” textual y “1B” AST-based, el modelo herradura losconsidera a ambos dentro del contexto de estructura de código.  Transformación Textual: En el nivel 1A, las transformaciones textuales son realizadas a través de varias comparaciones de cadenas simples y remplaza métodos. Las transformaciones son elegidas por las organizaciones cuando el problema es suficientemente simple o cuando se requiere un resultado rápido y sucio.  Transformación al árbol de sintaxis: En el nivel 1B, las transformaciones a la estructuras de código basada en arboles de sintaxis soportan cambios que son inmunes a las variaciones superficiales de sintaxis. La representación del código fuente es independiente de las expresiones o la forma en que los lenguajes de programación representan números.Transformaciones A Nivel funcional: Tiene que ver con el re-empaquetado defuncionalidad. La encapsulación de un modulo de funcionalidad por un diferenteambiente. Transformaciones a nivel funcional va másallá de simples 9
  10. 10. transformación de arquitectura. Ellos son elegidos cuando grades unidades defuncionalidad pueden ser salvados poniéndolos dentro de un nuevo contexto.Transformaciones A Nivel De Arquitectura: Involucran cambios a los bloquesbásicos de la arquitectura. Estos modelos básicos de interacción incluyen los tiposde componentes, los conectores usados, la asignación de funcionalidad y elmodelo en tiempo de ejecución de control y datos. A este nivel es el mas abstractoy lejos de alcance de las transformaciones.Las trasformaciones son hechas cuando es necesario un cambio a la estructuraprincipal debido a las principales modificaciones o deficiencias en los sistemas deinformación heredados.Interacción Entre Niveles: Las transformaciones a la estructura del código sepueden dar sin hacer cambios de nivel funcional o cambios a la arquitectura. Lastransformaciones del nivel mas bajo soportan las transformaciones de niveles másaltos.Las transformaciones a la arquitectura son normalmente el contexto en los cualestoman parte niveles más bajos. Las transformaciones se pueden darindependientemente de las transformaciones de niveles superiores. 10
  11. 11. EL MODELO CÍCLICOEste modelo define seis actividades, estas actividades se producen de formasecuencial y lineal, pero esto no siempre es así.El paradigma de la reingeniería es un modelo cíclico, esto es que cada una de lasactividades es parte del paradigma que pueden repetirse en otras ocasiones. Paraun ciclo en particular, el proceso puede terminar después de cualquier actividad.Las actividades del modelo cíclico son:Análisis de inventario, Restructuración de documentos, Ingeniería Inversa,Restructuración de código, Restructuración de datos e Ingeniería directa.El análisis de inventario: todas las organizaciones de software deberán disponerde un inventario de todas sus aplicaciones. El inventario pueden que no sea masque una hoja de calculo con la información que proporciona una descripcióndetallada de todas las aplicaciones activas.Los candidatos a la reingeniería aparecen cuando se ordena esta información enfunción de su importancia para el negocio, longevidad, mantenibilidad actual yotros criterios localmente importantes. Es entonces cuando es posible asignarrecursos a las aplicaciones candidatas para el trabajo de reingeniería.Es importante destacar que el inventario deberá revisarse con regularidad. Elestado de las aplicaciones puede cambiar en función del tiempo y, comoresultado, cambiaran también las prioridades para la reingeniería.Restructuración de documentos: Una documentación escasa es la marca demuchos sistemas de información heredados. Para esto se tiene que hacer:  La creación de documentación consume muchísimo tiempo. El sistema funciona, y ya nos ajustaremos con lo que se tiene. En algunos casos, este es el enfoque correcto. No es posible volver a crear la documentación para cientos de programas de computadoras. Si un programa es relativamente 11
  12. 12. estático esta llegando la final de vida útil, y no es probable que experimente muchos cambios.  Es preciso actualizar la documentación, pero se dispone de recursos limitados. Quizá no es necesario volver a documentar por completo la aplicación. Más bien se documentan por completo aquellas partes del sistema que están experimentando cambios en ese momento. La colección de documentos útil y relevante ira evolucionada con el tiempo.  El sistema es fundamental para el negocio, y es preciso volver a documentar por completo. Un enfoque inteligente consiste en reducir la documentación al mínimo necesario.Todas y cada una de estas opciones son viables. Las organizaciones del softwaredeberán seleccionar aquella que resulte más adecuada para cada caso.Ingeniería Inversa: tiene sus orígenes en el mundo del hardware. Una ciertacompaña desensambla un producto de hardware un producto de hardwarecompetitivo en un esfuerzo por comprender los secretos del diseño y fabricaciónde su competidor. Estos secretos se podrán comprender más fácilmente si seobtuvieran las especificaciones de diseño y fabricación del mismo. Pero estosdocumentos son privados y no están disponibles para la compañía que efectúa laingeniería inversa.La ingeniería inversa del software es algo bastante similar. Sin embargo, en lamayoría de los casos, el programa del cual hay que hacer una ingeniería inversano es el de un rival, sino, más bien, el propio trabajo de la compañía.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. Esta se extraerá del programa existente informacióndel diseño arquitectónico y de proceso, e información de los datos.Restructuración del Código: este es el tipo más común. Algunos sistemasheredados tiene una arquitectura de programa relativamente solida, pero losmódulos individuales han sido codificados de una forma que hace comprenderlos, 12
  13. 13. comprobarlos y mantenerlos. En este caso, se puede restructurar el códigoubicado dentro de los módulos sospechosos.Para llevar a cabo esta actividad, se analiza el código fuente mediante unaherramienta de restructuración, se indican las violaciones de las estructuras deprogramación estructurada, y entonces se restructurar el código. El códigorestructurado resultante se revisa u se comprueba para asegurar que no se hayanintroducido anomalías. Se actualiza la documentación interna del código.Restructuración de Datos: Un programa que posea una estructura de datos débilserá difícil de adaptar y de mejorar. De hecho, para muchas aplicaciones, laarquitectura de datos tiene más que ver con la viabilidad a largo plazo delprograma que el propio código fuente. Cuando la estructura de datos es débil, seaplica 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.Ingeniería Directa: las aplicaciones se reconstruyen utilizando un motor dereingeniería automatizado. En el motor se insertaría el programa viejo, que loanalizaría, restructuraría y después regeneraría la forma de exhibir los mejoresaspectos de la calidad del software.Lo que es mas importante, estas herramientas de reingeniería cada vez son massofisticadas.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, si noque, además, utiliza esta información en un esfuerzo por mejorar su calidad global. 13
  14. 14. CONCLUSIONLa reingeniería del software es un tema muy importante para muchas empresasyorganismos que tienen que seguir manteniendo sus aplicaciones porque susdesarrollos han sidocostosos y adaptados a sus necesidades, lo que en muchoscasos hace que no existanaplicaciones comerciales similares. En muchos casosno pueden adaptarse a los avances del hardware, porque estos nuevosequiposincorporan sistemas operativos para los que no fueron pensados lossistemas legados.Existen los modelos y métodos de desarrollo que abordan esta problemática,algunas de ellas específicas para determinados aspectos, como recuperar eldiseño, desarrollar la documentación pérdida, o convertir un código. Nuestroproceso de desarrollo trata de mantener la funcionalidad del sistema, manteniendolos datos, pero utilizando un nuevo código en un lenguaje orientado a objetos,portanto, ya estructurado, con una interfaz de usuario totalmente nueva, que dotea las aplicaciones de un aire de modernidad y que, por tanto, facilite su utilizaciónpor parte del usuario final. Además, añade nuevas especificaciones con sucorrespondiente documentación, lo que permitirá la ampliación del sistema.Una ventaja de esta los modelos y métodos que explicamos es que algunas desus fases pueden llevarse a cabo sin complicaciones. Otra ventaja es que seadapta a dominios científicos, en los que el tiempo de procesamiento esimportante y está claramente diferenciada la interfaz de usuario del procesamientoy la obtención de resultados.Esperando que este informe haya sido explicado de una manera entendible y asípuedan los lectores utilizar este documento para la realización de reingeniería 14
  15. 15. REFERENCIAS 15

×