Ingeniería inversa

Introducción

La ingeniería inversa invoca una imagen de «ranura mágica». En la ranura se inserta una lista fuente sin documentar y diseñado casualmente, y del otro extremo sale una descripción completa del diseño para el programa de computadora. Desdichadamente, la ranura mágica no existe.

El grado de abstracción de un proceso de ingeniería inversa y las herramientas utilizadas para efectuarlo se refieren a la sofisticación de la información de diseño de procedimiento (grado de abstracción bajo), información de estructura de programa y datos (grado de abstracción un poco más elevado), modelos de objeto, modelos de flujo de datos o control (grado de abstracción relativamente alto) y clases UML, diagramas de estado y despliegue (grado alto de abstracción).  Conforme el grado de abstracción aumenta, el ingeniero de software obtiene información que le permitirá comprender con más facilidad el programa.

La completud de un proceso de ingeniería inversa se refiere al grado de detalle que se ofrece en un grado de abstracción. La integridad disminuye conforme el grado de abstracción aumenta, por ejemplo, dada una lista del código fuente, es relativamente sencillo desarrollar una representación completa del diseño del procedimiento, pero es mucho más difícil desarrollar un conjunto completo de diagramas o modelos UML.

Si la direccionalidad del proceso de ingeniería inversa es unidireccional, toda la información extraída del código fuente se ofrece al ingeniero de software que entonces puede usarla durante cualquier actividad de mantenimiento.

Ingeniería inversa para comprender los datos

Al nivel de programa, las estructuras de datos internos del programa usualmente deben someterse a reingeniería inversa como parte de una reingeniería. La ingeniería inversa de las actuales estructuras globales de datos establece el escenario para introducción de una nueva base de datos que abarque todo el sistema.

Ingeniería inversa para comprender el procesamiento

Comienza con un intento por comprender y luego extraer abstracciones de procedimientos representadas por el código fuente. La funcionalidad global de todo un sistema de aplicación se debe comprender antes de que ocurra un trabajo de ingeniería inversa más detallado.

En sistemas grandes la ingeniería inversa, por lo general, se logra utilizando un enfoque semi automatizado. Las herramientas automatizadas ayudan al ingeniero de software a comprender la semántica del código existente.

Ingeniería inversa de interfaces de usuario

Desarrollar de nuevo las interfaces de usuario se ha vuelto uno de los tipos más comunes de actividad de reingeniería. Pero antes de que una interfaz de usuario se pueda reconstruir deberá realizarse una actividad de ingeniería inversa.

Se sugieren tres preguntas básicas que deben responder conforme comienza la ingeniería inversa de la interfaz de usuario:

• ¿Cuáles son las acciones básicas (presiones de tecla o clics de ratón, por ejemplo) que debe procesar el sistema?
• ¿Cuál es la descripción compacta de las respuestas de comportamiento del sistema a estas acciones?
• ¿Qué se entiende por «reemplazo» o, más exactamente, qué concepto de equivalencia de interfaces es relevante en este caso?