| << Chapter < Page | Chapter >> Page > |
La primera actividad real de la ingeniería inversa comienza con un intento de comprender y posteriormente, extraer las 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.
Antes de iniciar el trabajo de ingeniería inversa detallado debe comprenderse totalmente la funcionalidad general de todo el sistema de aplicaciones sobre el que se esta operando. Esto es lo que establece un contexto para un análisis posterior, y proporciona ideas generales acerca de los problemas de interoperabilidad entre aplicaciones dentro del sistema. Así pues, cada uno de los programas de que consta el sistema de aplicaciones representará una abstracción funcional con un elevado nivel de detalle, creándose un diagrama de bloques como representación de la iteración entre estas abstracciones funcionales. Cada uno de los componentes de estos diagramas efectúa una subfunción, y representa una abstracción definida de procedimientos. En cada componente se crea una narrativa de procesamientos. En algunas situaciones ya existen especificaciones de sistema, programa y componente. Cuando ocurre tal cosa, se revisan las especificaciones para preciar si se ajustan al código existente, descartando posibles errores.
Todo se complica cuando se considera el código que reside en el interior del componente. El ingeniero busca las secciones del código que representan las configuraciones genéricas de procedimientos. En casi todos los componentes, existe una sección de código que prepara los datos para su procesamiento (dentro del componente), una sección diferente de código que efectúa el procesamiento y otra sección de código que prepara los resultados del procesamiento para exportarlos de ese componente. En el interior de cada una de estas secciones, se encuentran configuraciones más pequeñas. Por ejemplo, suele producirse una verificación de los datos y una comprobación de los límites dentro de la sección de código que prepara los datos para su procesamiento.
Para los sistemas grandes, la ingeniería inversa suele efectuarse mediante el uso de un enfoque semiautomatizado. Las herramientas CASE se utilizan para “analizar” la semántica del código existente. La salida de este proceso se pasa entonces a unas herramientas de reestructuración y de ingeniería directa que completarán el proceso de reingeniería.
Cuando la ingeniería inversa se aplica sobre código de un programa para averiguar su lógica o sobre cualquier documento de diseño para obtener documentos de análisis o de requisitos se habla de ingeniería inversa de procesos.
Habitualmente, este tipo de ingeniería inversa se usa para:
La información extraída son las especificaciones de diseño: se crean modelos de flujo de control, diagramas de diseño, documentos de especificación de diseño, etc. y pudiendo tomar estas especificaciones como nuevo punto de partida para aplicar ingeniería inversa y obtener información a mayor nivel de abstracción.
A la hora de realizar ingeniería inversa de procesos se suelen seguir los siguientes pasos:
A la hora de encontrar los componentes funcionales hay que tener en cuenta que los módulos suelen estar ocupados por componentes funcionales. Además, suele haber componentes funcionales cerca de grandes zonas de comentarios y los identificadores de los componentes funcionales suelen ser largos y formados por palabras entendibles.
Una vez encontrados los posibles componentes funcionales, conviene repasar la lista teniendo en cuenta que un componente es funcional cuando Un componente es funcional cuando su ausencia impide seriamente el funcionamiento de la aplicación, dificulta la legibilidad del código, impide la comprensión de todo o de otro componente funcional o cuando hace caer a niveles muy bajos la calidad, fiabilidad, mantenibilidad, etc.
Vamos a ver cómo a partir de un código java cómo se puede realizar Ingeniería Inversa de Procesos. Tenemos dos clases (Persona y Trabajador)
class Persona {
protected String nombre;
protected int edad;
protected int seguroSocial;
protected String licenciaConducir;
public Persona(String nom, int ed, int seg, String lic) {
set(nom, ed); seguroSocial = seg; licenciaConducir = lic; }
public Persona() {
Persona(null, 0, 0, null); }
public int setNombre(String nom) {
nombre = nom; return 1; }
public int setEdad(int ed) {
edad = ed; return 1; }
public void set(String nom, int ed) {
setNombre(nom); setEdad(ed); }
public void set(int ed, String nom) {
setNombre(nom); setEdad(ed); }
}
class Trabajador extends Persona {
private String empresa;
private int salario;
public Trabajador(String emp, int sal) {
empresa = emp; salario = sal; }
public Trabajador() {
this(null,0); }
public int setEmpresa String emp) {
empresa = emp; return 1; }
public int setSalario(int sal) {
salario = sal; return 1; }
public void set(String emp, int sal) {
setEmpresa(emp); setSalario(sal); }
public void set(int sal, String emp) {
setEmpresa(emp); setSalario(sal); }
}
Si realizamos Ingeniería Inversa, el diagrama UML sería el siguiente:
Figura 1. Diagrama de clase generado a partir del código Java
Notification Switch
Would you like to follow the 'Técnicas de mantenimiento de software' conversation and receive update notifications?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|