Presentación sobre ingeniería inversa

2. Ingeniería Inversa

3. Ingeniería Inversa
• Es el análisis de un sistema para identificar sus componentes actuales y las dependencias que existen entre ellos, para
extraer y crear abstracciones de dicho sistema e información de su diseño.
• Es el proceso de analizar el código, documentación y comportamiento de un sistema para identificar sus componentes
actuales y sus dependencias para extraer y crear una abstracción del sistema e información de diseño.

4. •Documentación inexistente o totalmente obsoleta.
•Programación en bloque de códigos muy grandes y/o sin estructurar.
•Inexistencia de documentación interna en los programas, o bien ésta es
incomprensible o está desfasada.
•La aplicación cubre gran parte de los requisitos y del rendimiento esperado.
•La aplicación está sujeta a cambios frecuentes, que pueden afectar a parte del
diseño.
•Se prevé que la aplicación pueda tener aún larga vida.
Aplicable a

5. Nivel de Abstracción
Tienen que ver con la sofisticación de la información de diseño que puede extraerse del código fuente.
El proceso de ingeniería inversa debe ser capaz de inferir representaciones de:
•Diseño procedimental (una abstracción de bajo nivel)
•Información de estructura de programa y datos (un nivel de abstracción un poco más alto)
•Modelos de objeto, modelos de datos y/o flujo de control (un nivel de abstracción relativamente alto)
•Modelos de relación de entidad (un nivel de abstracción alto).

6. Completitud
Se refiere al nivel de detalle que se proporciona en un nivel de abstracción. En la mayoría de los casos, la
completitud disminuye conforme aumenta el nivel de abstracción.
Por ejemplo, dada una lista de código fuente, es relativamente sencillo desarrollar una representación de
diseño procedimental completa. También pueden inferirse representaciones de diseño arquitectónico
simples, pero es mucho más difícil desarrollar un conjunto completo de diagramas o modelos UML.

7. Interactividad
La interactividad tiene que ver con el grado en el que el ser humano se “integra” con las herramientas
automatizadas para crear un proceso de ingeniería
inversa efectivo.
En la mayoría de los casos, conforme aumenta el nivel de abstracción, la interactividad debe aumentar o
decaerá la completitud.

8. Direccionalidad
Si la direccionalidad del proceso de ingeniería inversa es de una vía, toda la información extraída del código
fuente se proporciona al ingeniero de software que luego puede usarla, durante cualquier actividad de
mantenimiento.
Si la direccionalidad es de dos vías, la información se alimenta a una herramienta de reingeniería que
intenta reestructurar o regenerar el programa antiguo.

9. Proceso Ingeniería Inversa

10. Reestructuración
• La reestructuración del software modifica el código fuente y/o los datos en un intento de adecuarlo a futuros cambios.
• La reestructuración no modifica la arquitectura global del programa. Tiende a centrarse en los detalles de diseño de
módulos individuales y en estructuras de datos locales definidas dentro de los módulos.

11. Beneficios de la Reestructuración
• Programas de mayor calidad – con mejor documentación y menos complejidad, y ajustados a las prácticas y estándares de la ingeniería del software moderna.
• Reduce la frustración entre ingenieros del software que deban trabajar con el programa, mejorando por tanto la productividad y haciendo más sencillo el
aprendizaje.
• Reduce el esfuerzo requerido para llevar a cabo las actividades de mantenimiento.
• Hace que el software sea más sencillo de comprobar y de depurar.

12. Ingeniería inversa para comprender datos
En el nivel del sistema, las estructuras de datos globales con frecuencia se someten a reingeniería para acomodar los diferentes nuevos paradigmas.
Estructuras de datos internas. Las técnicas de ingeniería inversa para datos internos del programa se enfocan en la definición de clases de objetos. Esto se logra al examinar el
código del programa con la intención de agrupar variables del programa relacionadas. Por ejemplo, el registro de estructuras, archivos, listas y otras estructuras de datos con
frecuencia proporciona un indicador inicial de clases.
Estructura de la base de datos. La reingeniería de un esquema de base de datos en otro nuevo requiere comprender los objetos existentes y sus relaciones.

13. Ingeniería inversa de interfaces de usuario
Para comprender completamente una interfaz de usuario existente, deben especificarse la estructura y el comportamiento de la interfaz. Merlo et al. [Mer93] sugieren tres preguntas básicas que deben responderse conforme
comienza la ingeniería inversa de la UI.
• ¿Cuáles son las acciones básicas (por ejemplo, golpes de tecla y clics de ratón) que debe
procesar la interfaz?
• ¿Cuál es la descripción compacta de la respuesta de comportamiento del sistema a
dichas acciones?
La notación de modelado de comportamiento puede proporcionar un medio para desarrollar respuestas a las preguntas. Mucha de la información necesaria para crear un modelo de comportamiento puede obtenerse al observar la
manifestación externa de la interfaz existente. Pero información adicional necesaria para crear el modelo de comportamiento debe extraerse del código.
Es importante observar que un reemplazo de GUI puede no reflejar con exactitud la antigua interfaz. Por ejemplo, una antigua UI solicita que un usuario proporcione un factor de escala (que va de 1 a 10) para encoger o ampliar una
imagen gráfica. Una GUI sometida a reingeniería puede usar una barra de desplazamiento y ratón para lograr la misma función.

14. Bibliografía
Roger S. Pressman, P. (2010). Ingenieria del Software, un enfoque practico.
Connecticut: McGraw Hill; 7ma Edición

15. Gracias por su atención
Mayo 2018
Elizabeth Ramirez-1151256
José Hernandez-1151252
Janes Duran-1151238
Jhocel Suescun-1151241
Dumar Basto-1151222
Rafael Cano-1151216