Ind 12277

________________________________________________________________________ 03.20 - Reingeniería de sistemas de información e ingeniería inversa.

1

03.20. Reingeniería de sistemas de información e ingeniería inversa

Autor: Francisco Cortés Sanz

Sumario 03.20.01. Introducción. 03.20.02. Conceptos. 03.20.03. Para que se utilizan la Reingeniería y la Ingeniería Inversa. 03.20.04. Acciones a realizar en los procesos de Reingeniería bajo la perspectiva de Mantenimiento y de Calidad del Software. 03.20.04.01. Planificación del entorno. 03.20.04.02. Plan de trabajo de Reingeniería. 03.20.05. Breve catálogo de herramientas.

Bibliografía - Seinca. "Situación y perspectivas de la Tecnología CASE”, l9W. - Reverse Engineering Newsietter. IEEE Computer Society/TCSE, enero 1992. - Pressman. “ingeniería del Software, un enfoque práctico”. Ed. McGraw-Hill. - Oman. “Maintenance Tods”. IEEE Software, mayo 1990. - Rafael Ruiz de la Torre. “Reingeniería como elemento de calidad”. Novática, octubre 1992. - Sommerville. “Ingeniería del Software”. Ed. Addison-Wesley Iberoamericana, 1992. - Chikofsky y J.H. Cross. “Reverse Engineering and Design Recovery: A Taxonomy, IEEE Software, enero 1990. - Stapleton. “La Ingeniería Inversa solución al pasado”. UNIX SYSTEMS, abril 199.4. - SMS. Strategic Analysis Report. Gartner Group, febrero y agosto 1993. - Rabin. “The Basics of Reengineering”, SDM-Auerbach Publications, 1993. - P.L Seymour. “Critical Success Factors in Reengineering Legacy Systems”, SDM-Auerbach Publications, l - Varios. “Using CASE Tools to Reengineer Existing Applications”, M-Auerbach Publications, 1994. - Raynor y LA. Rolstad. “Reengineering: a guide for the software developer, Faulkner Technical Reports, octubre

1992.

03.20.01. Introducción

El auge que están alcanzando en los últimos tiempos la Reingeniería (y no sólo de los Sistemas de Información) y la Ingeniería Inversa exige alguna reflexión.

Primeramente sobre los propios conceptos para intentar fijar una terminología que hasta no hace mucho era imprecisa y fuertemente dependiente del autor, organismo o compañía comercial que tratara el tema.

En segundo lugar para comprender la razones del auge y tratar de encajar estas técnicas dentro del mundo más amplio de la Ingeniería del Software.

Pretendemos también ser útiles por dos vías: sugerir un plan de trabajo en los procesos de Reingeniería, al tiempo que establecer un breve catálogo de herramientas cuya descripción facilite la comprensión y aplicación de estas técnicas.

03.20.02. Conceptos

El Subcomité de Ingeniería Inversa del IEEE Computer Society ha propuesto una terminología en este área. Por otro lado el grupo de usuarios de IBM Guide Internacional ha trabajado sobre los mismos conceptos proponiendo los términos correspondientes. Se puede mencionar que la mayoría de ponencias sobre los mismos temas comienzan con una expli-cación terminológica. Teniendo esto en cuenta la terminología aquí propuesta ha sido tomada básicamente de las defini-ciones dadas por el grupo de trabajo del IEEE Computer Socíety.

Ingeniería Inversa (Reverse Engineering): es el proceso de analizar un sistema para identificar los componentes y las interrelaciones entre ellos, creando representaciones del sistema en otra forma distinta a la original o bien a un nivel superior de abstracción.

Reestructuracion (Restructuring): es la transformación de una forma de representación de un sistema en otra dis-tinta pero del mismo nivel de abstracción, sin modificar el comportamiento externo del sistema.

Reingeniería (Reengineering): es el examen y modificación de un sistema para ser reconstruido de una forma nueva y además realizar la implantación derivada de esa nueva forma. La Reingeniería normalmente incluye alguna forma de Ingeniería Inversa (con lo cual se consigue una descripción más abstracta) y va seguida de alguna forma de Ingeniería

_________________________________________________________________ VOLUMEN 03 – INGENIERÍA DE LOS SISTEMAS DE INFORMACIÓN

2

“hacia adelante” o también de una Reestructuración.

“Ingeniería Hacia Adelante” (Forward Engineering): es el proceso que va desde un alto nivel de abstracción, que es independiente de la implementación concreta, hasta la propia implementación física del sistema. Es el campo típico de acción de una metodología de desarrollo y de herramientas que la soporten. Se podría traducir como Ingeniería del Software en su vertiente restringida al nuevo desarrollo.

La Ingeniería Inversa implica recuperar las especificaciones de diseño y los requerimientos funcionales desde un código (fuente u objeto) preexistente, o bien desde la definición de los datos, obteniendo casi siempre representaciones gráfi-cas y además, en las herramientas más avanzadas, se puede almacenar esta información en un diccionario de datos o base de conocimiento que suele designarse como repositorio.

La Reingeniería conlleva la aplicación de herramientas técnicas y metodologías para ampliar la vida útil de los Sistemas de Información ya existentes con un enfoque de mejora de la efectividad y de reducción de costes. Proporciona a los desarrolladores medios para incorporar nuevas tecnologías, recuperar el conocimiento de los expertos implícito en el código y la posibilidad de reutilización del propio código.

Reingeniería de Empresas (Business Procese Reengineering ( BPR): en el campo económico también se ha introducido el concepto de Reingeniería que se desarrolla alrededor de tres actividades clave:

- Rediseñando los procesos básicos de trabajo para alcanzar los objetivos de negocio. - Utilizando las nuevas tecnologías para concebir, diseñar y poner en pié nuevas actividades. - Cambiando la forma en la cual trabajan los empleados.

03.20.03. Para qué se utilizan la Reingeniería y la Ingeniería Inversa.

Aunque el concepto de Reingeniería no es actual, la idea de reutilización de los viejos sistemas como parte de nuevos sistemas estratégicos sí es reciente. Por otra parte, las actividades que comprende se vienen realizando desde hace tiempo como parte de las tareas de mantenimiento de los Sistemas Informáticos. Quizás por este hecho no han alcanza-do una mayor difusión hasta ahora pues las tareas de mantenimiento siempre han sido relegadas a un segundo plano por la comunidad informática. Y sin embargo, en algunas organizaciones las labores de mantenimiento suponen hasta el ochenta por ciento de sus recursos dedicados a Sistemas de Información.

Un elemento clave en la utilización de las técnicas aquí descritas es la constitución de repositorios de software o librerías de software reutilizable entre distintos proyectos, que reducen los tiempos de producción y los costes. En el diseño y análisis, las metodologías orientadas a objetos son las que más facilidades ofrecen para el establecimiento de estos repositorios de software reutilizables. En el mantenimiento, la Reingeniería, Ingeniería Inversa y Reestructuración han de emplearse tanto en la constitución Inicial del reposItorio del software a partir de elementos existentes, como en su pos-terior mantenimiento.

Las técnicas de Reingeniería y de Ingeniería Inversa realizan acciones sobre el software para conseguir un sistema man-tenible y reutilizable. Este proceso ha sido considerado por algunos autores como una especie de normalización (evitan-do todo el rigor matemático deL término). Se considera una normalización porque obtiene como resultado una descrip-ción del sistema no ambigua y sin anomalías.

La Reingeniería puede contribuir a la eliminación de software redundante en la organización, al determinar partes de código que realizan la misma función y que pueden ser sustituidos por un código común.

La Reingeniería puede verse como una oportunidad de mejorar la Calidad del Software. La mejora de la calidad puede deberse a la mejora de uno cualquiera de los parámetros de la calidad (mantenibilidad, flexibilidad, fiabilidad, reusabili-dad, eficiencia, integridad, etc.) o varios de ellos. Vale la pena examinar estos parámetros definitorios de la calidad.

Respecto a la mantenibilidad y flexibilidad: las razones principales por las que un código puede ser difícil de mantener son:

- Dificultad de lectura. El empleo de identación y estructuración facilita el mantenimiento del código fuente. - Lógica de decisión compleja. El anidamiento excesivo de estructuras de decisión en un programa dificulta su

comprensión. Al igual que el empleo de la lógica negativa, ya que omite más información de la que aporta. - Empleo de GOTO. Su uso conduce indefectiblemente a la programación “spaghetti”. - Tamaño de líneas de código. A mayor longitud de programa se produce también mayor redundancia en el mismo

que añade una dificultad también mayor para el mantenimiento, al tener que realizar el mismo cambio en distin-tas partes del programa.

Respecto a la reusabilidad o capacidad de reutilización: muchos módulos contienen dos o más funciones que, separadas adecuadamente, podrían usarse por otros programas. Normalmente, la Reingeniería para separar las funciones en módulos aislados será más costosa que su simple Reestructuración.

Respecto a la fiabilidad: la fiabilidad de un programa depende en buena medida de los datos y variables y de la lógica del mismo. Algunos de los problemas más frecuentes respecto a la lógica del programa son:

- La falta de caminos alternativos en estructuras de decisión (caso típico del DEFAULT en sentencias CASE). - Acciones incorrectas después de una comprobación.


3

- Número incorrecto de iteraciones en un bucle, por mal control del mismo.

A todo estos problemas podemos hacer frente con herramientas de Reingeniería o Ingeniería Inversa, cómo pretende-mos mostrar más adelante.

Respecto a la eficiencia: la eficiencia de ordinario se opone al resto de los parámetros de calidad. La Reingeniería puede adaptarse no para favorecer los anteriores parámetros sino para mejorar la eficiencia.

Al efectuar una Reingeniería existen una serie de factores para su desarrollo que permiten aumentar la calidad del soft-ware a modificar, como la existencia de: documentación del sistema; juegos de datos reales para la realización de prue-bas; conocimiento de la operativo del sistema (pantallas, Informes de salida, representaciones de la lógica); registros estadísticos de operaciones o de Informes de errores. La Reingeniería aparece así como un medio de racionalizar el conjunto de software existente.

Suele confundirse a veces el concepto de Reingeniería con el de “Downsizing”. El segundo encierra la idea de descentra-lización o desconcentración tendente a la reducción de costes, mediante la aproximación de las tareas concretas a los usuarios. La Reingeniería es un rediseño más radical que a veces reinventa la manera de procesar la información, lo cual permite dar soporte a nuevas estrategias preconcebidas y aún más, puede dar origen ella misma a nuevas estrategias; no es solamente un paliativo táctico. Esta visión es especialmente fecunda en la Reingenieria de Empresas donde puede llegar a ser una alternativa de construcción de estrategias empresariales basadas en la forma de operar (en su mejora respecto a los competidores) antes que en los productos o en los mercados. La Reingeniería puede ser usada para con-seguir ventajas competitivas mejorando costes y servicios y permitiendo la entrada en nuevos sectores o mercados, ya que a menudo es capaz de Identificar nuevas aplicaciones para los conocimientos y formas de hacer que ya se poseen.

03.20.04. Acciones a realizar en los procesos de Reingeniería bajo una perspectiva de Mante-nimiento y de Calidad de Software

No es nuestra pretensión dar una metodología detallada que haya de seguirse para realizar actividades de Reingeniería, puesto que no existe una fórmula genérica aplicable en todas las oportunidades. Cuando nos encontramos ante un pro-blema de Reingeniería, las actividades a realizar cambian en cada caso, en función de las circunstancias peculiares del mismo. Por ejemplo, no es lo mismo tener como objetivo la mejora del rendimiento de un sistema en cuyo desarrollo se ha participado, y que tiene documentación, que añadir un nuevo modulo funcional a un sistema desarrollado por otras personas y del cual no se posee documentación. No obstante, las acciones a realizar se pueden dosificar en dos grupos: las relativas al entorno y las propias de la Reingeniería.

03.20.04.01. Planificación del entorno

Las consideraciones de entorno incluyen principalmente la existencia de una organización de mantenimiento y de una función de gestión de la configuración.

La organización del mantenimiento incluye entre otros los siguientes puntos:

A. Establecimiento de las distintas funciones asociadas al mantenimiento. Lo cual significa que hay que identificar y asignar (aunque sea de manera informal) a ciertas personas una serie de responsabilidades como:

- Controlador del mantenimiento: será el encargado de recoger las peticiones de mantenimiento y canalizadas a la persona adecuada.

- Supervisor de sistema: será la persona familiarizada con un conjunto de programas o aplicaciones que efectúa la evaluación del alcance del cambio a realizar.

- Autoridad de control de cambios: encargada de determinar las acciones a llevar a cabo en cada caso. - Personal de mantenimiento: persona responsable de efectuar físicamente las modificaciones.

B. Definición de conjunto de Informes que reflejan cada uno de los pasos dados durante las tareas de mantenimien-to (sin que nada se oponga a que dichos Informes descansen sobre una misma hoja de papel):

- Informe de la petición del cambio. - Informe del problema del software. - Informe del análisis y evaluación de Impacto del cambio. - Informe de la realización del cambio.

C. Definición de un flujo de sucesos que especifica el tratamiento que deben recibir los distintos documentos del sis-tema de mantenimiento. Normalmente, los cambios se clasifican atendiendo a su importancia y para cada catego-ría existe un procedimiento normal a seguir, así como un procedimiento de emergencia utilizable cuando un cam-bio debe realizarse sin demora.

D. Sistema de registro de Información de los cambios realizados.

E. Función de evaluación de las actividades de mantenimiento para que puedan corregirse problemas detectados en el pasado.

La gestión de la configuración del software puede existir ya como tal función si durante el desarrollo del sistema se implantó para gestionar los productos del mismo. En caso contrario habrá que establecerla, para lo que habremos de


4

considerar el registro de puntos de referencia que quedan marcados por la recepción de cada elemento de configuración (aprobado mediante una revisión técnica formal) y la identificación elementos de configuración del software surgidos en el proceso de desarrollo y mantenimiento. La gestión de la configuración descansa en estos dos conceptos descritos a fin de garantizar las funciones de:

- Identificación de los elementos de configuración del software con nombres significativos consistentes. - Control de cambios, identificando las distintas versiones del software en coordinación con la organización de

mantenimiento. - Auditorías de configuración para controlar el estado de los cambios solicitados y aprobados. - Generación de informes de estado de la configuración.

03.20.04.02. Plan de trabajo de Reingeniería

Nos referiremos en este punto a las consideraciones propias de la Reingeniería, que si bien no tiene un metodología establecida, ni siquiera un procedimiento formal a aplicar generalmente admitido, es posible sugerir una serie de pasos que faciliten la realización de la tarea; estos pasos serían los siguientes:

Paso 1: Evaluación del potencial de Reingeniería.

Consiste en averiguar sobre qué partes del sistema sería más adecuado concentrar el esfuerzo de las modificaciones. Para ello es necesario:

- Hacer un Inventario de los elementos de la configuración con todas las peticiones de modificación a ellos referi-das y que no hayan sido satisfechas.

- Clasificar las peticiones de modificación como formales ( las que afectan a la forma) y funcionales (las que afec-tan a las funciones del sistema). Conviene también hacer una evaluación sobre las peticiones de servicio que por sus características son atendidas sin seguir estrictamente los procedimientos formales de control de cambios.

- Distinguir entre las oportunidades de Reingeniería y las nuevas oportunidades de desarrollo. Nos serviremos de tres criterios fundamentales: funciones de los sistemas actuales que se corresponden con los sistemas propues-tos; grado en que los sistemas actuales proporcionan datos a los sistemas propuestos y grado en que los siste-mas actuales dependen de la tecnología utilizada para obtener las funciones. El factor coste no es despreciaba: se deben sumar los costes del nuevo software, del nuevo hardware y los Incrementos de coste asociados a algu-nos aspectos de la nueva forma de operar; todo ello ha de ser, minorado con las reducciones a obtener en los costes de nuevos desarrollos, en el mantenimiento. en otros aspectos de la nueva forma de operar y sobre todo, con los incrementos de productividad del usuario final.

Paso 2: Establecimiento de los herramientas adecuadas.

Muchas de las tareas requeridas pueden automatizarse mediante el empleo de un conjunto de herramientas adecuadas a nuestras necesidades que pueden adquirirse o desarrollarse en este paso. Entre las herramientas útiles se pueden destacar:

- Auditor de código fuente. Permite investigar los cambios Incorporados en el software después de revisiones de código.

- Formateador. Permite formatear y presentar el código de acuerdo con unos estándares preestablecidos facilitan-do de este modo su lectura y comprensión.

- Analizador estático. En general, es capaz de obtener una visión detallada y omnicomprensiva de los elementos de un sistema y de la Interrelación lógica entre ellos, y representa dicha visión gráficamente.

- Monitor de cumplimiento de pruebas. Cuantifica los efectos de una estrategia mixta de pruebas que pueda incluir Auditorías, Análisis estático y pruebas de todo tipo.

- Estructurador. Herramienta que sustituye código no estructurado por código estructurado, afectando también al reestructurado de la lógica de decisión compleja.

- Generador de código. - Depurador interactivo de programas. - Generador de juegos de prueba. - Comparador de ficheros para ver las diferencias de versiones sucesivas de código fuente o de salidas de progra-

mas.

Paso 3: Reestructuración.

Este paso consiste en sustituir unos programas por otros que si bien realizan las mismas funciones, son más comprensi-bles y de mayor calidad. Este paso, es automatizable mediante el empleo de herramientas especializadas y tiene como principal labor la adaptación del código fuente para facilitar su lectura. Al hacer la reestructuración conviene tener una perspectiva de Calidad de Software y considerar los siguientes puntos:

- El tamaño de una función se debe limitar a 100 líneas de código fuente. El código debe tener sólo un verbo eje-cutable por línea. Los módulos se deben construir en función del tamaño y de la cohesión funcional

- No se deben admitir más de 10 decisiones por módulo. Las condiciones expresadas en lógica negativa se deben desterrar, pasándolas a lógica positiva.


5

- Identación. La función que debe cumplir es mostrar la estructura y los agrupamientos adecuados

- En las condiciones anidadas hay que evitar pasar de tres niveles de anidamiento. Se pueden usar rutinas para descomponerlas en grupos más fácilmente comprensibles.

- Eliminar tajantemente todas las sentencias del tipo GO TO.

- Aislar una función en cada módulo para asegurar la mantenibilidad, flexibilidad y reusabilidad.

- En la lectura de los datos se deben emplear secuencias de llamada estándar así como tabla estados para minimi-zar en lo posible posteriores cambios de lógica. Es recomendable emplear vectores y tablas para simplicar el pro-ceso y reducir la complejidad de la lógica, así como minimizar redundancia y maximizar la eficiencia de las lectu-ras. Es de todo punto necesario al declarar inicializar las variables su documentación concisa y significativa.

- El código debe ser reusable o reutilizable en la mayor proporción posible.

- Evitar los “literales” encajados en el código de los programas.

- Es necesario tener una perspectiva “Fault tolerant” anticipándose y tratando de soportar fallos.

- La nomenclatura utilizada para funciones, variables y etiquetas deben facilitar la comprensión programa, garanti-zar la unicidad de los nombres y deben ser borrados los nombres de variables utilizadas.

- Deben emplearse lenguajes de alto nivel que Impongan al programador automáticamente estructuración, evitan-do las extensiones no portabas que suelen tener los lenguajes.

- Comentarios. Se debe Incorporar una descripción introductoria a los programas y usar ampliamente comentarios para explicar los aspectos que el código no muestra claramente. El bloque inicial de comentarios al comienzo de cada unidad de código o programa debe describir: nombre, propósito limitaciones, entradas, salidas, algoritmos, cosas que se dan por asumidas y referencia a otros aspectos de la documentación.

- Número de versión. Se recomienda emplear números de versión para controlar la configuración software y la do-cumentación.

- Documentación. Los algoritmos básicos deberán ser documentados literariamente con amplitud en general toda la documentación deberá respetar los estándares que deben haberse establecido

Paso 4: Ingeniería Inversa.

En este paso se pretende crear, en el caso más frecuente, la documentación de un sistema ya existente. Para ello es necesario identificar los distintos componentes del sistema, sus interrelaciones, así como pro-ducir la documentación de acuerdo con unas determinadas reglas de normalización. El paso puede auto-matizarse en buena medida empleando herramientas: analizadores estáticos y estructuradores de código fundamentalmente Estas técnicas pueden ser realizadas sobre las especificaciones de los datos o sobre las de los procesos. Casi ninguna herramienta CASE soporta íntegramente estos dos enfoques, existiendo sin embargo bastantes alternativas de herramientas en el ámbito de las especificaciones de datos (recomen-damos a este respecto revisar el catálogo de herramientas que se adjunta).

Paso 5: Reingeniería.

Consiste en el examen y alteración de un sistema para reconstruido en una nueva forma. Si no se dispone de la documentación adecuada de¡ sistema objeto de la Reingeniería, habrá que realizar una Ingeniería Inversa previamente. El proceso completo es muy difícilmente automatizable, pero si puede serlo en par-tes significativas mediante el empleo de generadores de código y de herramientas de Ingeniería Inversa. En lo nuevos desarrollos, habrá que emplear técnicas de Ingeniería del Software y de Garantía de Calidad de Software.

Paso 6: Evaluación de las consecuencias de la Reingeniería.

Una vez realizada la Reingeniería hay que revisar el nuevo código para comprobar diversos aspectos de su estructura, documentación, comentarios, descripción de datos y variables, lnterfaces, manejo de errores, consistencia y completitud. Hay que revisado desde la perspectiva de la Calidad de Software, establecien-do listas de comprobación de los elementos citados.

03.20.05. Breve catalogo de herramientas

Las herramientas ofrecidas en el mercado para colaborar con el técnico en los procesos de Reingeniería suelen tener dos enfoques: aquellas que forman parte de paquetes CASE de propósito más general y aque-llas que son independientes en sí mismas y se ocupan de una o varias tareas, por lo general, de Ingeniería Inversa.

Somos conscientes que, tanto debido al dinamismo del mercado como al dinamismo de los creadores de las herramientas, cualquier catálogo que se establezca está condenado a no ser exhaustivo y a quedar desactualizado al poco tiempo, entre otros defectos de los que será acusado con seguridad. Sin embargo


6

un catálogo que describa las funcionalidades de las herramientas tiene un valor añadido muy significativo: es capaz casi por si sólo de representar muy intuitivamente qué son la Reingeniería Inversa y la Reinge-niería y cómo pueden ayudar al creador y mantenedor de software. De otra parte suele ser un lugar co-mún en los artículos y ponencias sobre estos temas.

03.20.05.01. Herramientas que se engloban en paquetes CASE

Excelerator Design/Recovery.

Es capaz de leer información de aplicaciones existentes, recogiendo buena parte de las características del diseño de las mismas e importando estos datos al diccionario de Excelerator, donde se generan automáti-camente los diagramas correspondientes a esas aplicaciones.

Bachman/Re-Engineering Product Set.

Permite recuperar el modelo de datos de la aplicación existente, incorporado a su diccionario e Integrarlo en el modelo único de todos los datos. Está Integrado en AD/Cycle de IBM, que es una plataforma abierta donde confluyen varios fabricantes.

Delta/Amelio.

Permite la recuperación y reestructuración del código existente. Está integrado en AD/Cycle de IBM.

IEW.

Permite la recuperación de las descripciones del modelo de datos e incorporadas al repositorio centraliza-do produce un diagrama de entidad relación. 1

Pacbase.

Este paquete CASE incorpora Pacreverse que permite el mantenimiento y migración de aplicaciones exis-tentes al entorno Pacbase. Pacreverse ayuda a realizar un análisis de conversión de aplicaciones e integra las aplicaciones existentes, produciendo una nueva aplicación documentada y estructurada.

Via Center.

Este paquete CASE integra un repositorio de información que identifica la estructura y operación de una aplicación, permitiendo la realización asistida de su mantenimiento y Reingeniería.

03.20.05.02. Herramientas independientes

Objective-C Browser.

Soporta las extensiones del lenguaje Objective-C. Proporciona como tipos de información sobre el código: el contenido, la referencias cruzadas, y la información sobre la jerarquía de la herencia. Puede dar las referencias cruzadas de cualquier función, método o variable para estimar el alcance de cualquier campo.

Vifor.

Permite visualizar programas Fortran como componentes visuales (a través de grafos de relaciones). Em-plea grafos de dos columnas: la de la izquierda para representar los procesos y la de la derecha para re-presentar variables.

Sheela.

Soporta el mantenimiento y la documentación de programas estructurados. Incorpora un visualizador de programas “top-down”, editor de estructura, browser, formateador y documentador de código. Soporta Ada, Cobol, C, Pascal, PL/I y Fortran.

Battle Map & Act.

Permite realizar Ingeniería Inversa y análisis de calidad sobre código existente. Muestra la estructura de un sistema gráficamente, usando una simbología especial para representar la complejidad de cada módu-lo. Permite trabajar con todo el diseño o sólo con cierta parte. Act es la herramienta que analiza la complejidad y se puede adquirir como parte de Battle Map o Independientemente. Produce grafos de flujo para cada modulo y genera caminos de prueba también para cada módulo. Soporta C, Fortran, Cobol, Ada, Basic, PL/I y Pascal.

Grasp/Ada.

Herramienta producida en un proyecto de la Universidad de Aubum que representa de forma gráfica la estructura de control de los programas. Emplea un formateador como base del prototipo de producción de diagramas de la estructura de control. Los diagramas de estructura de control emplean una notación ideada para facilitar la comprensión de los programas en un menor tiempo.

Expert Dataflow and Static Analisys.


7

Permite revisar programas Ada saltándose los detalles innecesarios. A diferencia de las herramientas de análisis dinámico que obligan a editar, recompilar y proporcionar la entrada para recorrer todos los caminos, permite trabajar sobre el código fuente sin compilar. Incluye un formateador de pantalla (para omitir información no necesaria), controlador de flujo (para seguir el flujo normal del código o volver atrás para revisar todos los posibles caminos) y generador de refe-rencias cruzadas (para determinar cuando y donde se emplean las variables).

CA-METRICS.

Crea repositorio y posee amplia caja de herramientas. Soporta varios tipos de ciclos de vida.

Pathvu.

Para programas COBOL: Analizador, estructurador y documentador conforme a estándards suministrados.

ADW.

Para programas COBOL: Analizador, estructurador, documentador y generador de código.

Cadre.

Familia de herramientas de bajo coste en UNIX y PC. Soporta C, C++ y Fortran; lnteracciona bien con herramientas de documentación lntedeaf y FrameMaker. Crea Base de Datos propia muy grande.

Productos Softbech de HP.

Incluyen herramientas de Ingeniería Inversa; soportan C, C+ +, COBOL Y SQL

Northstaf.

Para recuperación de diseños y migraciones a entornos cliente/servidor basado en Windows; heredero de ADW (la herramienta más contrastada). Sólo soporta COBOL

Software Through Pictures.

Analizador estático y generador de diagramas gráficos detallados. Interactúa bien con algunas herramientas de desarro-llo.

Energize.

Paquete con algunas facilidades de Ingeniería Inversa fáciles de usar. Limitaciones a C, C+ +, Plataformas UNIX y mala interacción con otras herramientas.

SmartSystem 2.1.

Muy bueno depurando código viejo aunque sea de varios millones de líneas. Plataformas UNIX y se puede utilizar en solitario o conjuntamente con herramientas STP de IDE, generando documentación muy precisa y código nuevo.


8

Ind 12277

Documents

Transcript of Ind 12277