Los países más desarrollados que se mantienen a la vanguardia en filosofías de producción y en tecnología son quienes generan la mayor parte de la ingeniería en el mundo. Esto crea un fenómeno de desigualdad tecnológica a nivel mundial que se agudiza debido a la inmensa diferencia en calidad y cantidad de recursos que son destinados a las instituciones dedicadas a la investigación y desarrollo en estos países, en comparación con aquellos que se enfocan sobre todo a formar técnicos (naciones en vías de desarrollo). Ante este panorama, se buscan alternativas para aprovechar y reutilizar todos los conocimientos existentes sobre la forma de crear productos. La ingeniería tradicional parte de un conjunto de especificaciones técnicas que contienen información sobre la funcionalidad de la mercancía, su cumplimiento de normas, sustentabilidad ambiental y viabilidad económica entre otras, para plantear su adecuada fabricación y así llegar a un artículo físico. Se requiere de un considerable tiempo de estudio de mercado, diseño del producto y del proceso de producción, modelado, pruebas de factibilidad y funcionalidad, estudio de materias primas, evaluaciones de costos y tiempos, etcétera. Es un procedimiento ineludible para la obtención de piezas originales.
Una vez que una mercancía ha sido probada con éxito, lo obvio es fabricarla hasta que su ciclo en el mercado termine. Lo anterior suena lógico para el creador, pero ¿qué sucede con la
METODOLOGÍA Y HERRAMIENTA PARA EL ANÁLISIS 38
competencia?, ¿cómo fabricar algo de lo cual no se tiene información original?, ¿cómo obtener mediciones cuando no existen patrones ni instrumentos para extraer la información?, y ¿cómo realizar un estudio ingenieril cuando no se cuenta con los suficientes recursos humanos, económicos y/o tecnológicos?
Para fortuna de muchos (e infortunio de otros) existe una respuesta real, factible y legal a estas preguntas. La ingeniería inversa plantea el camino desde el extremo final del ciclo. Es posible llegar de la parte física a la información ingenieril para de nuevo regresar a ella .
A menudo confundida con la piratería, la ingeniería inversa se define como aquel proceso analítico-sintético que busca determinar las características y/o funciones de un sistema, una máquina o un producto o una parte de un componente o un subsistema. El propósito de la ingeniería inversa es determinar un modelo de un objeto o producto o sistema de referencia (E. Jiménez, 2006).
De la definición anterior se puede apreciar que la ingeniería inversa es un proceso que busca obtener información y es aplicable a diversos campos. Este trabajo está referido a ingeniería inversa de un producto software; específicamente el código fuente almacenado en el componente programable de un CPLD MAX 7000.
La ingeniería inversa del software es un proceso que consiste en analizar un programa, en un esfuerzo por crear una representación del mismo con un nivel de abstracción más elevado que el código fuente. Según va aumentando la abstracción crece la complejidad del trabajo, así como la necesidad de comprensión de la aplicación. La ingeniería inversa debe ser capaz de abstraer, a partir del código fuente, información significativa del procesamiento que se realiza y las estructuras de datos que se usan en el programa.
El nivel de abstracción de un proceso de ingeniería inversa y las herramientas que se utilizan para realizarlo aluden a la sofisticació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, es decir, el proceso de ingeniería inversa debe ser capaz de derivar:
METODOLOGÍA Y HERRAMIENTA PARA EL ANÁLISIS 39
La información de las estructuras de datos y de programas (nivel de abstracción ligeramente elevado).
Modelos de flujo de datos y de control (un nivel de abstracción relativamente alto). Modelos de entidades y de relaciones (un elevado 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. Por tanto, la ingeniería inversa del software aparece como un proceso que ayuda al aseguramiento de la calidad y documentación de aplicaciones con deficiencias en los modelos de análisis y diseño. Además, ayuda en la disminución de costos y tiempos de mantenimiento (E. Jiménez, 2006).
En las siguientes secciones se expondrán diferentes acciones encaminadas a efectuar ingeniería inversa a determinado código fuente.
2.3.1. Ingeniería inversa para comprender el procesamiento
La primera actividad real de la ingeniería inversa comienza con un intento de comprender y extraer abstracciones de procedimientos representadas por el código fuente. Para comprender las abstracciones de procedimientos, se analiza el código en distintos niveles de abstracción: sistema, programa, componente, configuración y sentencia.
La funcionalidad general de todo el sistema de aplicaciones deberá ser algo perfectamente comprendido antes de que tenga lugar un trabajo de ingeniería inversa más detallado. Esto es lo que establece un contexto para un análisis posterior, y se proporciona ideas generales acerca de los problemas de interoperabilidad entre aplicaciones dentro del sistema. Cada uno de los programas de que consta el sistema de aplicaciones representará una abstracción funcional con un elevado nivel de detalle. También se creará un diagrama de bloques como representación de la iteración entre estas abstracciones funcionales. Cada uno de los componentes efectúa una sub-función, y representa una abstracción definida de procedimientos. En cada componente se crea una narrativa de procesamiento (E. Jiménez, 2006).
METODOLOGÍA Y HERRAMIENTA PARA EL ANÁLISIS 40
2.3.2. Ingeniería inversa para reestructurar el código
“La transformación desde una forma de representación a otra en el mismo nivel de abstracción, preservando las características externas del sistema (funcionalidad y semántica)” (Chifofsky, 1990).
La reestructuración del software modifica el código fuente y/o los datos en un intento de adecuarlo a futuros cambios. En general, la reestructuración no modifica la arquitectura global del programa. Tiene a centrarse en los detalles de diseño de módulos individuales y en estructuras de datos locales definidas dentro de los módulos. Si el esfuerzo de la reestructuración se extiende más allá de los límites de los módulos y abarca la arquitectura del software, la reestructuración pasa a ser ingeniería directa (E. Jiménez, 2006).
A continuación algunos beneficios que se pueden lograr cuando se reestructura el software: 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 (Arnold, 1989). La reestructuración se produce cuando la arquitectura básica de la aplicación es sólida, aun cuando sus interioridades técnicas necesiten un retoque. Comienza cuando existen partes considerables del software que son útiles todavía, y solamente existe un subconjunto de todos los módulos y datos que requieren una extensa modificación (Pressman, 2003).
2.3.3. Ingeniería inversa para redocumentar del código
La redocumentación es también una forma de ingeniería inversa. Es el proceso mediante el que se produce documentación retroactivamente desde un sistema existente. Si la redocumentación toma la forma de modificación de comentarios en el código fuente, puede ser considerada una forma
METODOLOGÍA Y HERRAMIENTA PARA EL ANÁLISIS 41
suave de reestructuración. Sin embargo, puede ser considerada como una sub-área de la ingeniería inversa porque la documentación reconstruida es usada para ayudar al conocimiento del programa. Se piensa en ella como una transformación desde el código fuente a pseudocódigo y/o prosa, esta última considerada como más alto nivel de abstracción que la primera.
Para el caso específico de esta tesis, que tiene como material de estudio un código fuente en lenguaje VHDL, perteneciente a un CPLD EPM7256SRI208 MAX 7000; como primer punto se examinará la funcionalidad general de todo el sistema, para tener una visión general de la interoperabilidad entre aplicaciones, posteriormente se enfocará el análisis en uno de los subsistemas; al que se le realizarán abstracciones de procedimientos representadas por su código fuente, para esto se creará una narrativa de procesamiento de dicho subsistema basada en diagramas de bloques. También se realizará una documentación del código fuente, mediante la inserción de comentarios a cada línea de código, en vistas a facilitar el conocimiento del programa. Para realizar este procedimiento se empleará como herramienta de apoyo el software Quartus II, que permitirá comprobar los resultados del análisis efectuado al código VHDL, a través de la simulación.