INGENIERÍA

INVERSA
SEMANA 08

CUARTA GENERACIÓN V
LIC. YUSSELIN MURCIA
¿QUÉ ES INGENIERÍA INVERSA?

• “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”. (Chrfofsky, 1990).
• “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. El
sistema en estudio no es alterado, sino que se produce conocimiento adicional
acerca del sistema” (SEI, 2004).
MISIÓN

• La ingeniería inversa tiene la misión de desentrañar los misterios y secreto de

los sistemas en uso. Consiste principalmente en recuperar el diseño de una
aplicación a partir del código.
• Esto se realiza principalmente mediante herramientas que extraen
información de los datos, procedimientos y arquitectura del sistema existente.
APLICABLE A SISTEMAS CON LAS SIGUIENTES
CARACTERÍSTICAS
• 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 está 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 puedan afectar a parte del
diseño.
• Se prevé que la aplicación pueda tener aún larga vida.
• La ingeniería inversa puede extraer
información de diseño del código
fuente, pero el nivel de abstracción, la
completitud de la documentación, el
grado con el cual trabajan al mismo
tiempo las herramientas y el analista
humano, y la direccionalidad del
proceso son sumamente variables.
(Cass, 1988)
 NIVEL DE ABSTRACCIÓN

• El nivel de abstracción de un proceso de ingeniería inversa y las herramientas que se

utilizan para realizarlo aluden a la sofiaticación de la información de diseño que se
puede extraer del código fuente. El nivel de abstracción ideal deberá ser lo más alto
posible, el proceso de ingeniería inversa debe ser capaz de deribar:
• Sus representaciones de diseño de procedimiento (con un bajo nivel de abstracción).
• La información de las estructuras de datos y de programas (un nivel de abstracción ligeramente más
elevado).
• Modelos de flujos de datos y de control (un nivel de abstracción relativamente alto).
• Modelos de entidades y de relaciones (un elevado nivel de abstracción).
NIVEL DE
ABSTRACCIÓN
• A medida que crece el nivel de
abstracción se proporciona al
ingeniero de software información
que le permitirá comprender más
fácilmente estos programas
(Pressman, 2003)
COMPLETITUD

• La completitud de un proceso de ingeniería inversa alude al nivel de detalle que se

propociona en un determinado nivel de abstracción. En la mayoría de los casos, la
completitud decrece a medica que aumenta el nivel de abstracción. Por ejemplo,
dado un listado del código fuente, es relativamentge sencillo desarrollar una
representación de diseño de procedimientos completa.
• La completitud mejora en proporción directa a la cantidad de análisis efectuado por
la persona que está efectuando la ingeniería inversa (Pressman, 2003)
INTERACTIVIDAD

• La interactividad alude al grado con el cual el ser humano se “integra” con

las herramientas automatizadas para crear un proceso de ingeniería inversa
efectivo. En la mayotía de los casos, a medida que crece el nivel de
abstracción, la interactividad deberá incrementarse, o si no la completitud se
verá reducida (Pressman, 2003).
DIRECCIONALIDAD

• Si la direccionalidad del proceso de ingeniería inversa es monodireccional,

toda la información extraída del código fuente se proporcionará a la
ingenieria del software que podrá entonces utilizarla durante la actividad de
mantenimiento. Si la direccionalidad es bidireccional, entonces la información
se suministrará a una herramienta de reingeniería que intentará reestructurar
o regenerar el viejo programa (Pressman, 2003).
PROCESO DE INGENIERÍA
INVERSA
• El proceso de ingeniería inversa se representa en la figura. Antes de
poder comenzar las actividades de ingeniería inversa, el código fuente
no estructurado (“sucio”) se reestructura de modo que sólo contenga los
constructos de programación estructurados. Esto hace que el código
fuente sea más fácil de leer y que proporcione la base para todas las
actividades de ingeniería inversa posteriores.

• El núcleo de la ingeniería inversa radica en una actividad llamada

extracción de abstracciones. Debe evaluar el programa antiguo y, a
partir del código fuente (con frecuencia no documentado), desarrollar
una especificación significativa del procesamiento que se realiza, de la
interfaz de usuario que se aplica y de las estructuras de datos del
programa o de la base de datos quese usa.
INGENIERÍA INVERSA PARA COMPRENDER DATOS

• La ingeniería inversa de datos ocurre en diferentes niveles de abstracción y con

frecuencia es la primera tarea de reingeniería. En el nivel del programa, las
estructuras de datos internas del programa con frecuencia deben someterse a
ingeniería inversa como parte de un esfuerzo de reingeniería global. En el nivel del
sistema, las estructuras de datos globales (por ejemplo, archivos, bases de datos)
con frecuencia se someten a reingeniería para acomodar nuevos paradigmas de
administración de base de datos (por ejemplo, moverse de un archivo plano a
sistemas de bases de datos relacionales u orientadas a objetos). La ingeniería
inversa de las estructuras de datos globales actuales monta el escenario para la
introducción de una nueva base de datos en todo el sistema.
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. En muchos casos, la organización de datos dentro del código
identifica tipos de datos abstractos. 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.
• Sin importar su organización lógica y su estructura física, una base de datos permite la
definición de objetos de datos y soporta algún método para establecer relaciones entre los
objetos. Por tanto, la reingeniería de un esquema de base de datos en otro nuevo requiere
comprender los objetos existentes y sus relaciones.
• Puede usar los siguientes pasos para definir el modelo de extracción de datos como precursor
de la reingeniería de un nuevo modelo de base de datos:
• Construir un modelo de objeto inicial,
• Determinar claves candidatas (los atributos se examinan para determinar si se usan para apuntar hacia
otro registro o tabla; los que funcionan como punteros se convierten en clases candidatas),
• Refinar las clases tentativas,
• Definir generalizaciones y
• Descubrir asociaciones usando técnicas que sean análogas al enfoque CRC. Una vez que se conoce la
información definida en los pasos anteriores, puede aplicarse una serie de transformaciones para
mapear la antigua estructura de la base de datos en una nueva estructura.
INGENIERÍA INVERSA PARA ENTENDER EL PROCESAMIENTO

• La ingeniería inversa para entender el procesamiento comienza con un intento por

comprender y luego extraer abstracciones procedimentales representadas mediante
el código fuente. Para comprender las abstracciones procedimentales se analiza el
código en varios niveles de abstracción: sistema, programa, componente, patrón y
enunciado.
• La funcionalidad global de todo el sistema de aplicación debe entenderse antes de
que ocurra trabajo de ingeniería inversa más detallado. Esto establece el contexto
para un mayor análisis y proporciona comprensión acerca de los conflictos de
interoperabilidad entre aplicaciones dentro del sistema.
INGENIERÍA INVERSA DE INTERFACES DE USUARIO

• Las GUI (interfaces de usuario gráficas) sofisticadas se han vuelto obligatorias para productos y
sistemas basados en computadora de todo tipo. Por tanto, el redesarrollo de las interfaces de
usuario se ha convertido en uno de los tipos más comunes de actividad de reingeniería. Pero antes
de poder reconstruir una interfaz de usuario, debe realizarse ingeniería inversa.
• 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?
• ¿Qué se entiende por “reemplazo” o, más precisamente, qué concepto de equivalencia de interfaces es
relevante aquí?
REESTRUCTURACIÓN

• La reestructuración de software modifica el código fuente y/o los datos con la intención de
hacerlos sensibles a cambios futuros. En general, la reestructuración no modifica la
arquitectura global del programa. Tiende a enfocarse sobre detalles de diseño de módulos
individuales y sobre estructuras de datos locales definidas dentro de módulos. Si el esfuerzo
de reestructuración se extiende más allá de las fronteras del módulo y abarca la arquitectura
del software, la reestructuración se convierte en ingeniería hacia delante.
• La reestructuración ocurre cuando la arquitectura básica de una aplicación es sólida, aun
cuando el interior técnico necesite trabajarse. Se inicia cuando grandes partes del software
son aprovechables y sólo un subconjunto de todos los módulos y datos necesitan modificación
extensa.
REESTRUCTURACIÓN DE CÓDIGO

• La reestructuración de código se realiza para producir un diseño que produzca la misma función
pero con mayor calidad que el programa original. En general, las técnicas de reestructuración de
código (por ejemplo, las técnicas de simplificación lógica de Warnier [War74]) modelan la lógica
del programa usando álgebra booleana y luego aplican una serie de reglas de transformación
que producen lógica reestructurada. El objetivo es tomar una “ensalada” de código y derivar un
diseño procedimental que se conforme con la filosofía de programación estructurada.
• También se han propuesto otras técnicas de reestructuración para su uso con herramientas de
reingeniería. Un diagrama de intercambio de recursos mapea cada módulo de programa y los
recursos (tipos de datos, procedimientos y variables) que se intercambiarán entre él y otros
módulos. Al crear representaciones de flujo de recursos, la arquitectura del programa
puedereestructurarse para lograr un mínimo acoplamiento entre módulos.
REESTRUCTURACIÓN DE DATOS
• Antes de que pueda comenzar la reestructuración de datos debe realizarse una actividad de
ingeniería inversa llamada análisis de código fuente. Se evalúan todos los enunciados de lenguaje
de programación que contienen definiciones de datos, descripciones de archivo I/O y descripciones
de interfaz.
• La intención es extraer ítems de datos y objetos, obtener información acerca del flujo de datos y
entender las estructuras de datos existentes que se implementaron. Esta actividad en ocasiones se
llama análisis de datos. Una vez completado el análisis de datos, comienza el rediseño de datos.
En su forma más simple, un paso de estandarización de registro de datos clarifica las definiciones
de los datos para lograr consistencia entre nombres de ítem de datos o formatos de registro físico
dentro de una estructura de datos existente o dentro de un formato de archivo.
• Otra forma de rediseño, llamada racionalización de nombre de datos, garantiza que todas las
convenciones de nomenclatura de datos se establezcan de acuerdo con estándares locales y que
los sobrenombres se eliminen conforme los datos fluyen a través del sistema. Cuando la
reestructuración avanza más allá de la estandarización y la racionalización, se realizan
modificaciones físicas a las estructuras de datos existentes para hacer que el diseño de datos sea
más efectivo. Esto puede significar una traducción de un formato de archivo a otro o, en algunos
casos, traducción de un tipo de base de datos a otra.