APLICACIONES DISTRIBUIDAS

ENTREGABLE 2
Barragán García Ricardo Josué

FELIPE SALAZAR VARGAS

16/03/20
 INGENIERIA INVERSA DE PROGRAMAS

Introducción

El objetivo de la ingeniería inversa es obtener información o un diseño a partir de un

producto accesible al público, con el fin de determinar de qué está hecho, qué lo hace
funcionar y cómo fue fabricado.

Hoy en día (principios del siglo XXI), los productos más comúnmente sometidos a
ingeniería inversa son los programas de computadoras y los componentes electrónicos,
pero, en realidad, cualquier producto puede ser objeto de un análisis de Ingeniería
Inversa.

En el caso concreto del software, se conoce por ingeniería inversa a la actividad que se
ocupa de descubrir cómo funciona un programa, función o característica de cuyo código
fuente no se dispone, hasta el punto de poder modificar ese código o generar código
propio que cumpla las mismas funciones.

La ingeniería inversa nace en el transcurso de la Segunda Guerra Mundial, cuando los

ejércitos enemigos incautaban insumos de guerra como aviones u otra maquinaria de
guerra para mejorar las suyas mediante un exhaustivo análisis.

Definición

El método se denomina así porque avanza en dirección opuesta a las tareas habituales
de ingeniería, que consisten en utilizar datos técnicos para elaborar un producto
determinado. En general, si el producto u otro material que fue sometido a la ingeniería
inversa fue obtenido en forma apropiada, entonces el proceso es legítimo y legal. De la
misma forma, pueden fabricarse y distribuirse, legalmente, los productos genéricos
creados a partir de la información obtenida de la ingeniería inversa, como es el caso de
algunos proyectos de Software libre ampliamente conocidos.

El programa Samba es un claro ejemplo de ingeniería inversa, dado que permite a

sistemas operativos UNIX compartir archivos con sistemas Microsoft Windows. El
proyecto Samba tuvo que investigar información confidencial (no liberada al público en
general por Microsoft) sobre los aspectos técnicos relacionados con el sistema de
archivos Windows. Lo mismo realiza el proyecto WINE para el conjunto de API de
Windows y OpenOffice.org con los formatos propios de Microsoft Office, o se hace para
entender la estructura del sistema de archivos NTFS y así poder desarrollar drivers para
la lectura-escritura sobre el mismo (principalmente para sistemas basados en GNU/Linux).

La ingeniería inversa es un método de resolución. Aplicar ingeniería inversa a algo

supone profundizar en el estudio de su funcionamiento, hasta el punto de que podamos
llegar a entender, modificar y mejorar dicho modo de funcionamiento.

Pero este término no sólo se aplica al software, sino que también se considera ingeniería
inversa el estudio de todo tipo de elementos (por ejemplo, equipos electrónicos,
microcontroladores, u objeto fabril de cualquier clase). Diríamos, más bien, que la
ingeniería inversa antecede al nacimiento del software, tratándose de una posibilidad a
disposición de las empresas para la producción de bienes mediante copiado1 desde el
mismo surgimiento de la ingeniería.

Usos de la ingeniería inversa

La ingeniería inversa suele ser empleada por empresas, para analizar si el producto de su
competencia infringe patentes de sus propios productos.

Muchas veces, la ingeniería inversa es utilizada en el área militar para investigar (y copiar)
las tecnologías de otras naciones, sin obtener planos ni detalles de su construcción o
desarrollo.

En el software y en el hardware, la ingeniería inversa, muchas veces es empleada para

desarrollar productos que sean compatibles con otros productos, sin conocer detalles de
desarrollo de éstos últimos. En otras palabras, quien desarrolla los nuevos productos, no
puede acceder a los detalles de fabricación de los productos de los que intenta ser
compatibles.

La ingeniería inversa también es empleada para comprobar la seguridad de un producto,

generar keygens de aplicaciones, reparación de productos, etc.

Ingeniería inversa del Software

La ingeniería inversa de software es un tipo de ingeniería inversa dedicada a las

aplicaciones.

La ingeniería inversa en software significa descubrir qué hace el software sin tener el
código fuente programado del mismo. Es una tarea que, en general, es complicada.

Suele emplearse con fines de aprendizaje, diagnóstico de software, análisis de seguridad

y pirateo de programas.
Beneficios de la Ingeniería Inversa del software

La aplicación de ingeniería inversa nunca cambia la funcionalidad del software sino que
permite obtener productos que indican cómo se ha construido el mismo. Se realiza
permite obtener los siguientes beneficios:

–          Reducir la complejidad del sistema: al intentar comprender el software se

facilita su mantenimiento y la complejidad existente disminuye.

–          Generar diferentes alternativas: del punto de partida del proceso, principalmente
código fuente, se generan representaciones gráficas lo que facilita su comprensión.

–          Recuperar y/o actualizar la información perdida (cambios que no se

documentaron en su momento): en la evolución del sistema se realizan cambios que no
se suele actualizar en las representaciones de nivel de abstracción más alto, para lo cual
se utiliza la recuperación de diseño.

–          Detectar efectos laterales: los cambios que se puedan realizar en un sistema
puede conducirnos a que surjan efectos no deseados, esta serie de anomalías puede ser
detectados por la ingeniería inversa.

–          Facilitar la reutilización: por medio de la ingeniería inversa se pueden detectar

componentes de posible reutilización de sistemas existentes, pudiendo aumentar la
productividad, reducir los costes y los riesgos de mantenimiento.

La finalidad de la ingeniería inversa es la de desentrañar los misterios y secretos de los

sistemas en uso a partir del código. Para ello, se emplean una serie de herramientas que
extraen información de los datos, procedimientos y arquitectura del sistema existente.

Ingeniería inversa de datos

La ingeniería inversa de datos suele producirse a diferentes niveles de abstracción. En el

nivel de programa, es frecuente que sea preciso realizar una ingeniería inversa de las
estructuras de datos internas del programa, como parte del esfuerzo general de la
reingeniería.

En el nivel del sistema, es frecuente que se efectúe una reingeniería de las estructuras
globales de datos (por ejemplo: archivos, bases de datos) para ajustarlas a los
paradigmas nuevos de gestión de bases de datos (por ejemplo, la transferencia de
archivos planos a unos sistemas de bases de datos relacionales u orientados a objetos).

La ingeniería inversa de las estructuras de datos globales actuales establecen el

escenario para la introducción de una nueva base de datos que abarque todo el sistema.

Estructuras de datos internas. Las técnicas de ingeniería inversa para datos de

programa internos se centran en la definición de clases de objetos5. Esto se logra
examinando el código del programa en un intento de agrupar variables de programa que
estén relacionadas.

En muchos casos, la organización de datos en el seno el código identifica los tipos

abstractos de datos. Por ejemplo, las estructuras de registros, los archivos, las listas y
otras estructuras de datos que suelen proporcionar una indicación inicial de las clases.

Para la ingeniería inversa de clases, se sugiere el enfoque siguiente:

–          Identificación de los indicadores y estructuras de datos locales dentro del

programa que registran información importante acerca de las estructuras de datos
globales (por ejemplo, archivos o bases de datos).

–          Definición de la relación entre indicadores y estructuras de datos locales y las

estructuras de datos globales. Por ejemplo, se podrá activar un indicador cuando un
archivo esté vacío; una estructura de datos local podrá servir como memoria intermedia
de los cien últimos registros recogidos para una base de datos central.

–          Para toda variable (dentro de un programa) que represente una matriz o archivo,
la construcción de un listado de todas las variables que tengan una relación lógica con
ella.

Estos pasos hacen posible que el ingeniero del software identifique las clases del
programa que interactúan con las estructuras de datos globales.

Estructuras de bases de datos. Independientemente de su organización lógica y de su

estructura física, las bases de datos permiten definir objetos de datos, y apoyan los
métodos de establecer relaciones entre objetos.

Por tanto, la reingeniería de un esquema de bases de datos para formar otro exige
comprender los objetos ya existentes y sus relaciones.

Para definir el modelo de datos existente como precursor para una reingeniería que
producirá un nuevo modelo de base de datos se pueden emplear los pasos siguientes:

1-    Construcción de un modelo de objetos inicial. Las claves definidas como parte del
modelo se podrán conseguir mediante la revisión de registros de una base de datos de
archivos planos o de tablas de un esquema relacional. Los elementos de esos registros o
tablas pasarán a ser atributos de una clase.

2-    Determinación de los candidatos a claves. Los atributos se examinan para

determinar si se van a utilizar o no para señalar a otro registro o tabla. Aquellos que sirvan
como punteros pasarán a ser candidatos a claves.

3-    Refinamiento de las clases provisionales. Se determina si ciertas clases similares

pueden o no combinarse dentro de una Única clase.

4-    Definición de las generalizaciones. Para determinar si se debe o no construir una

jerarquía de clases con una clase de generalización como precursor de todos sus
descendentes se examinan las clases que pueden tener muchos atributos similares.
5-    Descubrimiento de las asociaciones. Mediante el uso de técnicas análogas al
enfoque de CRC  se establecen las asociaciones entre clases.

Una vez que se conoce la información definida en los pasos anteriores, se pueden aplicar
una serie de transformaciones para hacer corresponder la estructura de la vieja base de
datos con una nueva estructura de base de datos.

REINGENIERÍA DE BASES DE DATOS

Introducción

La Reingeniería de Bases de Datos (DBRE) consiste en un conjunto de técnicas y

herramientas que permiten construir una descripción conceptual (un modelo de entidades
y relacionamientos) a partir de una base de datos en producción. El uso de la DBRE
permite, entre otras cosas, reconstruir y/o actualizar documentación perdida, incompleta o
inexistente de bases de datos, facilitar el proceso de migración de datos y colaborar en la
exploración y extracción de datos en bases poco documentadas.

Fases de la Reingeniería de bases de datos

Fase lógica utiliza como entrada a un esquema conceptual (un modelo de entidades y
relacionamientos) y produce como salida un esquema lógico (un conjunto de relaciones y
restricciones de integridad).

Fase física acepta como entrada al esquema lógico y produce un esquema físico
optimizado para un DBMS específico. Entonces, durante el proceso de reingeniería de
una base de datos se distinguen a su vez dos fases, denominadas fase de extracción y
fase de conceptualización, que revierten respectivamente a la fase física y a la fase
lógica.

Fase de extracción los procesos acceden a la base de datos fuente para recuperar
información de las estructuras de datos implementadas en el esquema físico. Los
principales objetos de interés son, por ejemplo las tablas, columnas, claves primarias y
claves foráneas. Tales objetos de interés se almacenan en una estructura de datos
denominada base de conocimiento.

Fase de conceptualización, durante la cual se explicitan las estructuras conceptuales

que derivaron en las estructuras de datos implementadas en la base de datos fuente. Esta
fase produce como salida un esquema conceptual utilizando algún modelo semántico.
Este modelo semántico se almacena en una estructura a la que genéricamente se
denomina base de datos semántica. En la base de datos semántica se almacenarán los
objetos conceptuales y los vínculos existentes entre ellos.
Módulos de la herramienta

La herramienta DBRE originalmente propuesta en [CLR97] es un software abierto para

reingeniería de bases de datos. La herramienta se considera “abierta” en el sentido de
que está diseñada para soportar diferentes familias de algoritmos de reingeniería, en
forma intercambiable. En forma general, la herramienta se compone de un conjunto de
algoritmos de reingeniería, un par de repositorios de datos y módulos auxiliares para
conceptualización, diagnóstico, explotación y gestión de la interfaz al usuario.

Los módulos de reingeniería comprenden a los algoritmos que realizan las tareas típicas
de la fase de extracción.

Los algoritmos se agrupan en familias según el tipo de objetos que detectan:

 Detectores de claves (algoritmos-K) [PTB*96]

 Detectores de dependencias funcionales y de inclusión (algoritmos-FD y
algoritmos-ID) [PTB*96] [Chi95]
 Detectores de agrupamientos de atributos (algoritmos-AGR).

Los algoritmos de reingeniería obtienen información de diversos orígenes: el esquema de

la base de datos fuente, la extensión de la misma y las operaciones SQL existentes en las
aplicaciones.

La intervención del usuario experto es requerida por algunos algoritmos. La información

obtenida, así también como el grado de confiabilidad de la misma – dependiente del
origen de donde se obtuvo dicha información- se almacena como resultado intermedio, en
el repositorio denominado base de conocimiento que se describe más adelante.

Repositorios de datos

Los algoritmos utilizan repositorios de datos a los efectos de almacenar la información que
va siendo descubierta durante la reingeniería.
El primer repositorio de datos utilizado se denomina base de conocimiento y almacena
información del esquema físico, que es descubierta durante la fase de extracción.

El segundo repositorio se denomina base de datos semántica y almacena el modelo

conceptual semántico descubierto durante la fase de conceptualización.

• Base de conocimiento (DBRE-KB) es el repositorio que almacena información del

esquema físico, que es descubierta durante la fase de extracción.

• Base de datos semántica almacena el modelo conceptual semántico descubierto durante

la fase de conceptualización

RECONSTRUCCIÓN DE LA ARQUITECTURA

En este último capítulo se trata el tema de reconstrucción de la arquitectura de un sistema

candidato al proceso de reingeniería. La reconstrucción de la arquitectura es una de las
principales actividades que se deben realizar al iniciar un proyecto de reingeniería ya que
esta nos permite entender al programa que sufrirá la transformación mediante la creación
de abstractas del sistema. En el primer subtema se intenta definir cual es el rol de la
reconstrucción de la arquitectura en el proceso de reingeniería para después mencionar
algunas recomendaciones para un proyecto de reconstrucción de la arquitectura. Este
capítulo finaliza explicando a detalle las fases que conforman la actividad de
reconstrucción de la arquitectura dando en algunos casos, ejemplos que ayuden a
entender dichas fases.

EL ROL DE LA RECONSTRUCCIÓN DE LA ARQUITECTURA.

La reconstrucción de la arquitectura según Bergey [Berg 00a] resulta en una

representación arquitectural que puede:

 Ser usada para documentar la arquitectura existente.

 Ser usada para checar la conformidad de la ya implementada arquitectura a la
arquitectura diseñada.
 Servir como un punto de partida para aplicar reingeniería al sistema para diseñar
una nueva arquitectura a través de la estrategia de transformación de la
arquitectura.
 Ser usada para identificar componentes para establecer un método de línea de
aplicación.

Si una organización no tiene documentación actualizada para un sistema existente, este

es a menudo una posibilidad para reconstruir la arquitectura del sistema para proporcionar
documentación actual. Usando apoyo automatizado, las unidades fuentes que construyen
componentes arquitectónicos y las ligas entre ellos sirven como las base para la
construcción de la documentación.
En muchos casos, la ya implementada arquitectura de un sistema tendrá que derivarse en
la arquitectura diseñada. En algunos casos, reconstruyendo la arquitectura del software
ayuda en el chequeo de conformidad de la ya implementada arquitectura contra la
arquitectura diseñada.

En otros casos, una organización deseará actualizar y agregar funcionalidad al sistema.

La arquitectura ya implementada es entonces reconstruida y usada como la base para la
transformación para la nueva arquitectura diseñada.

Cuando se introduce un método a la línea de producción, este normalmente se beneficia

al usar los componentes de la arquitectura existente en la línea de producción. En estos
casos, la reconstrucción de la arquitectura puede ayudar a identificar componentes
comunes que pueden ser el centro activo en la nueva línea de producción de la
arquitectura.

FASES PARA LA RECONSTRUCCIÓN DE LA ARQUITECTURA

La reconstrucción de datos requiere una serie de actividades y técnicas. Con la gran

cantidad de software en la mayoría de sistemas, es casi imposible ejecutar todas las
actividades de reconstrucción manualmente. En lugar de eso, un conjunto de
herramientas (conocidas como workbench) es necesario para apoyar a las actividades de
reconstrucción de la arquitectura.

Un workbench para la reconstrucción de arquitectura debe ser abierto (acoplar fácilmente

nuevas herramientas) y proporcionar una fácil integración de un marco de trabajo
(conocido como framework) para que las nuevas herramientas agregadas al conjunto no
afecten a las herramientas existentes o datos. Un workbench es "ARMIN", el cual
remplaza al workbench "Dali architecture Reconstruction" [Kazm 97]. ARMIN se utiliza
para extraer información desde el código fuente y otros artefactos del sistema, ARMIN
habilita la carga de esta información para que pueda ser usada en el proceso de
reconstrucción.

Usando las herramientas proporcionadas por ARMIN, la reconstrucción de la arquitectura

según Kazman [Kazm 03] comprende las siguientes fases:

 Extracción de la información.
 Construcción de la base de datos.
 Fusión de vistas.
 Composición de las vistas arquitectónicas.

Extracción de la Información

La extracción de la información involucra el análisis del diseño existente y artefactos de

implementación de un sistema para construir un modelo basado en las vistas de las
múltiples fuentes. Desde los artefactos fuente (código, archivos cabecera, archivos
construidos) y otros artefactos (ejecución del programa renglón por renglón) de los
sistemas, los elementos interesantes y las relaciones entre ellos pueden ser identificados
y capturados para producir varias vistas fundamentales del sistema. La siguiente tabla
muestra una lista de elementos típicos y varias relaciones entre los elementos que
pueden ser extraídos de un sistema.

Para ver el gráfico seleccione la opción "Descargar" del menú superior 

Cada una de las relaciones entre los elementos constituye una vista diferente del sistema.
Las relaciones "calls" entre funciones muestran como interactúan varias funciones en el
sistema. Las relaciones "includes" entre archivos muestra las dependencias entre los
archivos del sistema. Las relaciones "access_read" y "access_write" entre funciones y
variables muestra como son usados los datos en el sistema. Ciertas funciones pueden
escribir en un conjunto de datos y otros pueden leerlos. Esta información de relaciones es
usada para determinar como son pasados los datos entre varias partes del sistema.

Si el sistema analizado es grande y dividido dentro de una estructura de directorio,

capturar la estructura del directorio puede ser importante para el proceso de
reconstrucción. Ciertos componentes o subsistemas pueden ser almacenados en
directorios, y capturar las relaciones tales como "dir_contains_dir" y "dir_contains_dir"
puede ayudar a identificar componentes en el proceso de reconstrucción.

El conjunto de elementos y relaciones extraídos dependerá del tipo de sistema analizado

y las herramientas de extracción disponibles. Si el sistema a reconstruir es orientado a
objetos, clases y métodos deben ser agregados a la lista de elementos extraídos, y
relaciones tales como "Class is_subclass Class" y "Class contains Method" deben ser
extraídas y usadas en el proceso de reconstrucción.

Las vistas extraídas pueden ser catalogadas en estáticas o dinámicas. Las vistas
estáticas son aquellas obtenidas por observación de los artefactos del sistema, mientras
que las vistas dinámicas son las obtenidas por la observación del sistema durante su
ejecución. En muchos casos, las vistas estáticas y dinámicas pueden ser combinadas
para crear una representación más completa y exacta del sistema. Si la arquitectura del
sistema cambia en tiempo de ejecución, por ejemplo, un archivo de configuración es leído
por el sistema, y ciertos componentes son cargados en tiempo de ejecución, la
configuración en tiempo de ejecución deber ser capturado y usado cuando se lleve a cabo
la reconstrucción.

Una vista fuente puede ser extraída aplicando cualquiera de las herramientas disponibles,
apropiadas o necesarias para un sistema objetivo dado. El tipo de herramientas que se
usan regularmente en la extracción de información son las siguientes [Kazm 03]:

 Parsers (por ejemplo, "Understand for C/C++/java", "Imagix", "SNiFF+", "C++

Information Abstractor [CIA]", "Rigiparse").
 Analizadores basado en árboles de sintaxis abstractos (AST) (ejemplo, "Gen++",
"Refine").
 Analizadores léxicos (por ejemplo, "Lightweight Source Model Extractor [LSME]").
 Perfiladores.
 Instrumentación de código.
 Ad Hoc (por ejemplo, "Grez", "Perl")

Estas herramientas son aplicadas a las líneas del código fuente. Parsers analizan el
código y generan representaciones internas del código. Típicamente, es posible salvar
esta representación interna para obtener una vista fuente. Los analizadores basados en
AST hacen un trabajo similar, pero ellos construyen una representación del árbol explicito
de la información analizada.

Analizadores léxicos examinan los artefactos fuentes como cadenas de elementos léxicos
o señales. El usuario del analizador léxico puede especificar un conjunto de patrones
léxicos que coincidan y los elementos que regresará. Similarmente se usan una colección
de herramientas ad hoc tales como Grez y Perl para llevar a cabo comparaciones y
búsqueda de patrones léxicos dentro del código en orden de alguna información de salida
requerida.

Todas estas herramientas – parsers, analizadores basados en AST, analizadores léxicos

y ad Hoc – son usadas para extraer información estática.

Las herramientas perfiladoras y de código son usadas para extraer información acerca del
código que esta siendo ejecutado. Usar estas herramientas generalmente no requiere la
agregación de cualquier código nuevo al sistema. Por otro lado, instrumentación de
código – tales como los aplicados en el campo del testeo – involucra agregar código al
sistema para hacer resaltar alguna información especifica (por ejemplo, que procesos se
conectan con otros) mientras el sistema se ejecuta [McCa 02]. Estas herramientas y
técnicas generan vistas dinámicas del sistema.

Construcción de la base de datos.

El conjunto de vistas extraídas son convertidas al formato "Rigi Standard Format" (RSF) o
al "Graph eXchange Language" (GXL) y cargadas en ARMIN durante la fase de
construcción de bases de datos. Esta conversión es hecha usando Perl scripts que leen
los datos y los convierten en un archivo RSF. Las vistas extraídas pueden estar en
diferentes formatos dependiendo de las herramientas usadas para extraerlas. Por
ejemplo, una herramientas de extracción tal como "Understand for C/C++/Java" o "Imagix-
4D", pueden ser usadas para cargar el código fuente dentro de una representación
interna, y esta información puede entonces ser descargada a un conjunto de archivos
bandera indexados por archivos o función. Estos archivos tienen una estructura uniforme,
y los scripts pueden ser desarrollados en Perl para leer esos archivos y extraer
información acerca de los elementos y relaciones. La siguiente figura describe este
proceso.

Una vez que los elementos y relaciones de archivos (la vista extraída) es convertida a
RSF o a GXL, estos pueden ser cargados en ARMIN. La figura 4.2 muestra un extracto de
un archivo RSF ejemplo. El archivo completo puede ser cargado dentro de una base de
datos en ARMIN.

Para ver el gráfico seleccione la opción "Descargar" del menú superior 

Fusión de vistas.
En la fase Fusión de vistas, las vistas extraídas son manipuladas para crear vistas
fusionadas. Por ejemplo, una vista estática puede ser fusionada con una vista dinámica.
Como se puede notar, una vista estática no puede proporcionar toda la información
relevante de la arquitectura. En algunos casos, algunas funciones solo pueden ser
identificables en tiempo de ejecución, entonces se necesitará generar una vista dinámica.
Estas dos vistas necesitan ser compaginadas y fusionadas para producir la gráfica
completa del sistema.

La fase de fusión de vistas compagina y establece conexiones entre las vistas que
proporcionan información complementaria. La fusión es ilustrada usando los ejemplos de
las siguientes sub-secciones. El primer ejemplo muestra el mejoramiento de una vista
estática de un sistema orientado a objetos agregándole información dinámica. El segundo
muestra la fusión de varias vistas para identificar funciones llamadas en un sistema.

Mejorando una vista.

Consideramos las dos vistas de código de la figura 4.3, las cuales son del conjunto de
métodos extraídos desde un sistema implementado en C++.

Para ver el gráfico seleccione la opción "Descargar" del menú superior 

Las diferencias entre estas vistas se muestran en la siguiente figura:

Para ver el gráfico seleccione la opción "Descargar" del menú superior 

La vista dinámica muestra que List::getnth es llamada. Sin embargo, este método no esta
incluido en el análisis de la vista estática porque este no fue identificado por la
herramienta de extracción estática. Esto muestra que la herramienta de extracción
estática no es perfecta, haciendo necesario validar los resultados de la información
extraída. También, las llamadas a los métodos constructores y destructores de InputValue
y List no están incluidas en la vista estática. Esa ausencia de métodos debe ser agregada
a la vista de arquitectura compaginada.

En adición, la extracción estática muestra que la clase PrimitiveOp tiene una llamada al
método Compute. La extracción dinámica no muestra tal clase, pero muestra clases tales
como ArithmeticOp, AttachOp y StringOp, cada una de las cuales tiene un método
Compute y es de echo una subclase de PrimitiveOp, PrimitiveOp es una superclase; este
nunca es llamada en la ejecución del programa. Pero este es la llamada a PrimitiveOp
que se muestra cuando se ejecuta el extractor estático. Para tener una vista exacta de la
arquitectura, las vistas estáticas y dinámicas de PrimitiveOp deben ser compaginadas.

La siguiente figura muestra los ítems que deben ser agregados a la vista fusionada y
aquellos que deben ser removidos desde la vista fusionada.
 Despejando la ambigüedad de las funciones llamadas.

En una aplicación multi procesos, es muy probable que ocurra choque de nombres. Por
ejemplo, varios de los procesos pueden tener un procedimiento llamada main al cual
pueden llamar. Es importante identificar y eliminar la ambigüedad de esas colisiones de
nombres dentro de las vistas extraídas. Otra vez, por medio de la fusión de información
que puede ser extraída fácilmente, podremos remover las ambigüedades potenciales. En
este caso, necesitamos fusionar las vistas estáticas con una vista que contenga
archivos/funciones (para determinar cuales funciones están definidos en cuales archivos)
y con una vista de dependencias (para determinar que archivos están compilados junto a
los ejecutables producidos). La fusión de estas tres fuentes de información hace a los
nombres de procedimientos, métodos y otros elementos nombrados, permitiendo
entonces ser referidos sin ambigüedad en el proceso de reconstrucción de la arquitectura.
Sin la fusión de vistas, la colisión de nombres puede persistir, y los resultados de la
reconstrucción pueden ser ambiguos.

Composición de vistas arquitectónicas.

La fase de composición de vistas arquitectónicas consiste en dos áreas de actividad

principales:

 Visualización e interacción.
 Definición de scripts de comandos e interpretación.

Las áreas de visualización e interacción proporcionan un mecanismo que permite al

usuario visualizar, explorar y manipular vistas interactivamente. El componente
"Aggregator" de ARMIN es usado para presentar vistas al usuario como una gráfica de
descomposición jerárquica [Wong 94]. Una presentación ejemplo de una vista
arquitectónica es mostrada en la figura 4.6. Usando el Aggregator, el usuario puede ver
vistas en una variedad de estilos de diseños incluyendo jerárquicos, espiral y ortogonal.

Para ver el gráfico seleccione la opción "Descargar" del menú superior 

La definición de scripts de comandos y la interpretación proporcionan facilidades para la

abstracción de información de bajo nivel para generar vistas arquitectónicas. Los scripts
de comandos facilitan al usuario para escribir scripts para construir mejores vistas
abstractas desde vistas más detalladas por medio de la identificación de agregación de
elementos. Los scripts ARMIN son escritos usando el ARL y cualquier editor, y son
cargados dentro de ARMIN.
La reconstrucción arquitectónica no es un proceso directo. La construcción arquitectónica
no es representada explícitamente en el código fuente, lo que hace que la reconstrucción
sea especialmente difícil. Adicionalmente, la construcción arquitectónica es realizada por
una diversidad de mecanismos en una implementación. Usualmente estos son
colecciones de funciones, clases, archivos, objetos y demás. Cuando un sistema es
inicialmente desarrollado, los elementos de la arquitectura/diseño de alto nivel son
mapeados para la implementación de elementos. Por consiguiente, cuando los elementos
arquitectónicos son "reconstruidos", se aplica un mapeo a la inversa.

La reconstrucción arquitectónica es un proceso interpretativo, interactivo e iterativo, no un

proceso automático. Este requiere la habilidad y atención tanto de expertos en ingeniería
inversa y arquitectos (o algunos de los que tienen un conocimiento substancial de la
arquitectura). Basándose en los parámetros arquitectónicos que los expertos en la
arquitectura pueden encontrar en el sistema, la ingeniería inversa puede construir varios
scripts de comandos usando ARMIN. Estos scripts resultan en una nueva agregación que
muestra varias abstracciones o agrupamientos de elementos de bajo nivel (los cuales
pueden ser artefactos fuentes o abstracciones). Por la interpretación de estas vistas y el
análisis de estos, es posible refinar los scripts y agregaciones para producir varias
hipótesis de vistas arquitectónicas del sistema. Estas vistas pueden ser interpretadas,
refinadas o rechazadas. No existe un criterio universal para este proceso; este está
completo cuando la representación arquitectónica es suficiente para apoyar el análisis
necesario para los usuarios, entonces las metas de la reconstrucción pueden ser
logradas.

Consideremos el subconjunto de elementos y relaciones mostradas en la siguiente tabla:

Para ver el gráfico seleccione la opción "Descargar" del menú superior 

En este ejemplo, las variables "a" y "b" están definidas en la función "f"; esto es, ellas son
locales a "f". Esta información la podemos representar gráficamente como se muestra en
la figura 4.7.

Para ver el gráfico seleccione la opción "Descargar" del menú superior 

Las variables locales no importan durante una reconstrucción de arquitectura porque ellas
proporcionan poca comprensión de la arquitectura del sistema. Por consiguiente,
instancias de variables locales pueden ser agregadas a la función en la cual ocurren. Un
script tal como el que se muestra a continuación se puede escribir para ese propósito.

La primer línea es un comentario el cual comienza con el signo de libra #. La segunda

línea obtiene los descendientes de una función (usando el comando desc) – en este caso,
variables locales. El comando desc regresa un arreglo tridimensional de la función y sus
variables locales. La tercer línea asocia el nombre de la función con las variables locales
para cada función y agrega un signo más (+) al final del nombre. Usando el comando
collapse, la cuarta línea borrar de la gráfica todos los nombres de variables locales y deja
solo el nombre de la función con el +. Esta nueva gráfica es llamada FUNCTION+. La
última línea despliega la gráfica en la ventana de Aggregator usando el comando show.

El resultado de aplicar el script es representado gráficamente en la siguiente figura. La

mayoría de los scripts de comandos en ARMIN están desarrollados de una manera
similar.

Para ver el gráfico seleccione la opción "Descargar" del menú superior 

El principal mecanismo para manipular las vistas es la aplicación de scripts de comandos.

La siguiente lista muestra algunos ejemplos de scripts:

 Identificar tipos.
 Agregar variables locales con funciones.
 Agregar miembros a las clases.
 Crear elementos del nivel de arquitectura.

Un ejemplo de un script que identifica un componente del nivel de arquitectura,

Logical_Interaction, es mostrada en la siguiente figura. Este script dice que si el nombre
de la clase es Presentation, Bspline, o Color, o si la clase es una subclase de
Presentation, este pertenece al componente Logical_Interaction.

El script esta escrito de esta forma para abstraer información desde la información de bajo
nivel para generar vistas a nivel de arquitectura. El reconstructor crea este script para
probar la hipótesis acerca del sistema. Si un script no produce los resultados esperados,
este puede ser descartado. El reconstructor iteractúa a través de este proceso hasta que
obtiene las vistas arquitectónicas útiles.
 Costo y beneficios de la Reingeniería en sistemas

En un mundo perfecto, todo programa que no se pudiera mantener se retiraría

inmediatamente, para ser sustituido por unas aplicaciones de alta calidad, fabricadas
mediante reingeniería y desarrolladas empleando las prácticas de la ingeniería del
software modernas. Sin embargo, vivimos en un mundo de recursos limitados. La
reingeniería consume recursos que se pueden utilizar para otros propósitos de negocio.
Consiguientemente, antes de que una organización intente efectuar una reingeniería de la
aplicación existente, deberá llevar a cabo un análisis de costes y beneficios.

Una vez que se ha calculado el coste de la reingeniería, la última etapa es comparar los
costes con los beneficios esperados (no es suficiente con examinar los beneficios que
aporte la reingeniería).

Conclusión
Actualmente la forma de darle mantenimiento a los sistemas de información (SI) es bastante
controlada y metodológica, dependiendo de qué tipo de mantenimiento quiera o deba dársele al
sistema. Las técnicas, métodos y procesos que se utilizan siempre tienen como finalidad el
desarrollo de software de calidad. Se explican de forma general que son los sistemas de
información y cuáles son sus funciones en la actualidad, la importancia que representan en las
corporaciones para el manejo de datos e información de gran importancia, de la misma forma
hace mención a los tipos de sistemas más comunes, cuál es su función o para que fueron
diseñados y cuál es la diferencia de otros sistemas, iniciando con los sistemas generales y los de
una utilidad particular, también se hace una descripción de cómo es la estructura principal dentro
de un SI, que sucede en cada fase y cuál es su función, posteriormente se describen como fueron
creados mediante paradigmas de desarrollo y cuáles son los ciclos de vida de un sistema, desde un
sistema clásico en cascada hasta los modelos más recientes diseñados por prototipos. El manejo
del sistema o la administración del mismo debe ser bastante detallada, se debe realizar
documentación y registro de todo lo que es modificado desde su origen hasta la fecha en la que se
encuentra funcionando, para esto existen varios métodos de medición; métricas, modelos,
estándares y procesos. En este trabajo se describen los principales métodos que se utilizan para
garantizar la calidad del software, los estándares de calidad que llevan a la mejora continua de un
sistema de información, así como métodos estadísticos que en base a sus métricas nos indican
cual es la calidad que actualmente se maneja en el sistema. Cuando se elaboran planes para la
estrategia de información, las organizaciones no pueden dejar de considerar que el
mantenimiento de sistemas es la fase más prolongada y costosa del ciclo de vida de los sistemas.
Por eso también se hace mención a los tipos de mantenimiento que tienen una función específica
para poder darle al sistema un mejor desempeño optimizando los procesos que tienen algún
defecto o bien que no tienen defectos pero se puede realizar de una mejor forma, el de
mantenimiento es continuo nunca termina hasta que el ciclo de vida del sistema concluye, por eso
la importancia del mantenimiento que puede prevenir, corregir y mejorar siempre la forma de
operar en un sistema de información.
 Bibliografía
 Tecnicas auxiliares de mantenimiento de sistemas informaticos - PCPI 12/13 INFORMATICA
MARIO. (s. f.). Recuperado 16 de marzo de 2020, de
https://sites.google.com/site/pcpi1213informaticamario/home/modulos/2-mantenimiento/1-
mantenimiento-de-sistemas-informaticos/4-tecnicas-auxiliares-de-mantenimiento-de-sistemas-
informaticos

Mantenimiento de Sistemas de Información (MSI). (2018, mayo 10). Recuperado 16 de marzo de

2020, de https://manuel.cillero.es/doc/metrica-3/procesos-principales/msi/

http://cc.etsii.ull.es/ftp/antiguo/INGSOF2/Metricav3/MSIPROC.PDF