Reconstrucción de la arquitectura: Una actividad de la reingeniería de software

3. Capítulo 1.
   Reingeniería de procesos en la
   Administración
4. Capítulo 2. Sistemas
   heredados y reingeniería de software
5. Capítulo 3.
   Métodos y modelos de la reingeniería de
   software
6. Capítulo 4.
   Reconstrucción de la arquitectura
7. Conclusiones
8. Glosario
9. Bibliografía

INTRODUCCIÓN

La evolución del software esta dividida en
varias etapas, una de ellas es la llamada "crisis del
software". Esta crisis fue el resultado de la introducción de la tercera
generación del hardware. El hardware dejo
de ser un impedimento para el desarrollo de
la informática; redujo los costos y mejoro
la calidad y
eficiencia en
el software producido. La crisis se caracterizo por los
siguientes problemas:

• Imprecisión en la planificación del proyecto y
  estimación de los costos.
• Baja calidad del software.
• Dificultad de mantenimiento de programas con
  un diseño poco estructurado, etc.

A raíz de esta crisis se vio la necesidad de
crear estándares de desarrollo del software, esto dio
lugar a lo que hoy llamamos "Ingeniería de software" el cual es el
establecimiento y uso de principios de la
ingeniería a fin de obtener económicamente software
que sea fiable y que funcione eficientemente.

A pesar de la creación de estos
estándares, muchos sistemas
siguieron siendo desarrollados y mantenidos sin aplicar ninguna
practica de ingeniería de
software por lo que hoy en día, muchas organizaciones se
ven obligadas a seguir viviendo en esta crisis dado que sus
sistemas son vitales para el funcionamiento de dichas
organizaciones.

La reingeniería de software es la actividad con
el cual se pretende dar solución a estas organizaciones.
La reingeniería de software pretende dejar morir esos
sistemas imposibles de mantener, no sin antes extraer de ellos
conocimientos que permitan crear un nuevo sistema fiable,
eficiente y de fácil mantenimiento.

Dado que en muchos de los casos, la reingeniería
de software se convierte en la única solución a
estos sistemas de baja calidad, esta monografía pretenden dar una breve
introducción a dicha solución para mostrarle al
lector que a pesar de que el esfuerzo de aplicar
reingeniería es un proceso
difícil, trae grandes beneficios si se emplea de manera
adecuada.

¿Cómo está organizada esta
monografía?

Esta monografía esta organizada en cuatro
capítulos:

Capítulo 1: Reingeniería de
procesos

Esta primera parte de la monografía proporciona
una breve visión general de lo que es reingeniería
desde un punto de vista administrativo. Se comienza por narrar el
primer caso de reingeniería de procesos, el
cual se aplicó en el proceso de disparar proyectiles por
parte de la Marina de los Estados Unidos.
En el subtema 2 se da y explica la definición de reingeniería
de procesos y se hace mención a la esencia de la
reingeniería. Por último, este Capítulo hace
una comparación de la reingeniería contra los
programas de mejora incremental.

Capítulo 2: Sistemas de
información heredados y reingeniería de
software

Ya que se definió el concepto de
reingeniería desde el ámbito administrativo en el
Capítulo anterior, se podrá abordar el tema de
reingeniería de software. En este Capítulo se
detalla las características de los sistemas de información heredados, que son aquellos a
los que es necesario aplicarles reingeniería para
después abordar por completo el concepto de
reingeniería de software y sus objetivos.
También se menciona la importancia de aplicar
reingeniería de software en los sistemas de
información heredados. Antes de finalizar este
Capítulo, se explica el modelo que
propone Sneed para calcular los costes de un proyecto de
reingeniería.

Capítulo 3: Métodos y
modelos de la
reingeniería de software

Este Capítulo explica de una forma muy breve los
métodos y modelos que son utilizados para llevar a cabo de
manera satisfactoria la actividad de reingeniería. Al
comienzo del Capítulo se alude al método de
análisis de opciones para
reingeniería (OAR por sus siglas en ingles de Options
Analysis for Reingeneering" dando su definición y
explicando la necesidad de aplicarlo, se menciona de forma breve
las actividades principales y especializadas de este
método así como la estructura de
ellas. En los siguientes dos subtemas se trata a dos modelos
utilizados para la reingeniería: El modelo herradura y el
modelo cíclico, explicando brevemente los niveles o
actividades de cada uno.

Capítulo 4: Reconstrucción de la
arquitectura

El último Capítulo de esta
monografía 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.

CAPÍTULO 1

REINGENIERIA DE
PROCESOS

Para poder hablar
de la reingeniería de software, es necesario conocer el
origen de esta actividad, el cual se dio en el ámbito de
la
administración. En este capítulo se aborda el
concepto de reingeniería desde un punto de vista
administrativo, ya que fue en este enfoque donde la
reingeniería hace su aparición. En el primer
subtema de este capítulo se narra el primer caso de
reingeniería de procesos, el cual se aplicó en el
proceso de disparar proyectiles por parte de la Marina de los
Estados Unidos. En el subtema 2 se da y explica la
definición de reingeniería de procesos y se hace
mención a la esencia de la reingeniería. Por
último, este capítulo hace una comparación
de la reingeniería contra los programas de mejora
incremental.

1.1 PRINCIPIOS DE LA
REINGENIERÍA

Para explicar el origen de la reingeniería de
procesos es necesario retroceder al año 1898 durante la
guerra de los
Estados Unidos con España.
Durante esta guerra, la Marina de los Estados Unidos
disparó un total de 9500 proyectiles, de los cuales
sólo 121 (1.3%) hicieron impacto sobre el objetivo.
Durante este año, ese porcentaje representaba la
máxima eficiencia mundial aunque en tiempos actuales ese
porcentaje sería desastroso.

En 1899, haciendo una nueva demostración del
liderazgo que
entonces ejercía en cañoneo naval de
precisión, la Marina de los Estados Unidos realizó
una exhibición de práctica de tiro para referenciar
su rendimiento. En un total de veinticinco minutos de fuego
contra un blanco que era un buque situado a una distancia
aproximada de una milla (1.6 Km.), se registraron exactamente dos
impactos, y éstos en las velas del buque que servía
de blanco.

Pero en 1902, las Marina de los Estados Unidos
podía dar en un blanco parecido cuantas veces
disparará un cañón; la mitad de las balas
podían hacer impacto dentro de un cuadrado de 50 pulgadas
por lado (1.7 m). Este espectacular rendimiento fue logrado
gracias a un oficial de artillería naval llamado William
Sonden Sims, el cual se puede decir que fue el primero en
utilizar el proceso que hoy llamamos
reingeniería. [Mang 95]

Hace un siglo, apuntar un cañón hacia un
blanco en alta mar era una actividad muy aleatoria. El
cañón, el blanco y los mares que los rodeaban se
hallaban en movimiento
continuo. Los héroes tradicionales de los combates navales
eran los navegantes que maniobraban para colocar el buque en una
u otra posición y dar a los cabos de cañón
la oportunidad de cumplir su difícil tarea. Pero en unas
maniobras que se hicieron en el Mar de la China, Sims
observó los avances decisivos que los artilleros ingleses
habían empezado a lograr en la manera de apuntar y
disparar.

Los elementos del proceso para la artillería
naval eran bastante sencillos hace un siglo: un
cañón, una manivela para levantarlo al
ángulo de la trayectoria deseada para un alcance normal de
una milla, y un anteojo de larga vista montado sobre el
cañón mismo a fin de mantener el blanco en la mira
hasta un instante después del disparo y el retroceso de la
pieza. Sims descubrió una manera muy sencilla de mejorar
espectacularmente la puntería compensando la
elevación y el tiempo del
balanceo del barco.

Lo primero que sugirió fue reglamentar la
relación de los engranajes de tal manera que el artillero
pudiera elevar o bajar fácilmente el cañón
siguiendo el blanco en los balanceos del buque. En segundo lugar
propuso cambiar de sitio la mira del cañón para que
el artillero no fuera afectado por el retroceso al disparar. Esta
innovación le permitiría conservar
el blanco en la mira durante todo el acto del disparo. El
resultado sería fuego de puntería
continua.

Basándose en los cálculos que hizo en sus
notas, Sims predijo que sus modificaciones al proceso
tenían el potencial de aumentar la precisión de
tiro en más del 3000 por ciento, sin costos adicionales,
sin usar tecnología adicional,
y sin necesidad de aumentar el personal de
maniobra. Los consiguientes avances decisivos en productividad
fueron enormes, ¡y llegaron al 3000 por ciento que
había predicho Sims!

Después de haber revisado el primer caso de
reingeniería podríamos dar una vaga idea sobre el
proceso llamado Reingeniería; el cual tiene como resultado
un cambio radical
en los procesos obsoletos para obtener un mejor aprovechamiento y
rendimiento de la productividad. Este es considerado como el
primer caso documentado en el que se aplica reingeniería
ya que cumple con la definición que se da en el siguiente
tema, el cual a grandes rasgos, es realizar un cambio radical a
todo un proceso para lograr la productividad de una organización.

1.2 REINGENIERÍA DE PROCESOS

Una definición de
Reingeniería basada en [Mang 95] y [Hamm 94]
sería: es la actividad en el que los procesos son objeto
de una revisión fundamental y rediseño radical,
para lograr así la optimización de los flujos del
trabajo y la
productividad de una organización.

Para poder analizar esta definición es necesario
también definir lo que es un proceso. "Definimos un
proceso de negocios como
un conjunto de actividades que recibe uno o más insumos y
crea un producto de
valor para el
cliente." [Hamm
94]

Se dice que durante una reingeniería, los
procesos son objeto de una revisión fundamental ya que es
necesario realizarse las preguntas básicas sobre su
compañía y como funciona sin dar nada por sentado.
La reingeniería determina primero qué debe
hacer una compañía para después determinar
cómo debe hacerlo. Se olvida por completo de lo que
es y se concentra en lo que debe ser.

La revisión fundamental de un proceso nos
permitirá aplicarle un rediseño radical lo cual no
es simplemente realizar cambios superficiales o correcciones a lo
que ya esta instalado. Se trata de desechar por completo los
viejos procedimientos e
inventar nuevas formas de realizar el trabajo.
Rediseñar es reinventar el negocio, no mejorarlo o
modificarlo.

Al aplicar la reingeniería a un proceso
lograremos optimizar los flujos de trabajo y la productividad
dando resultados que deben ser notables y hasta sorprendentes,
esto debido a que el programa de reingeniería es
difícil y nunca se conseguirá un apoyo ejecutivo
sin promesas de resultados más que simplemente
incrementales.

La Esencia de la Reingeniería

"En el corazón de
la reingeniería esta la noción del pensamiento
discontinuo – de reconocer y romper desde afuera las viejas
reglas y suposiciones con respecto a las operaciones. Una
vez que cambiemos las reglas, nosotros simplemente reacomodaremos
las sillas en el Titanic." [Hamm 90]

Todos los negocios están llenos de reglas que se
tienen desde las primeras décadas. Esas reglas de
diseño de trabajo están basadas en vejas
suposiciones acerca de los objetivos de la tecnología,
gente y organizaciones. El repertorio actual de
información tecnológica disponible es grande y se
distribuye rápidamente. Calidad, innovación y
servicios son
más importantes que el costo,
crecimiento y control.

Para las empresas
deberá ser una sorpresa que sus procesos de negocios y
estructuras
están fuera de moda y obsoletos:
las estructuras de trabajo y procesos no tienen lugar con los
cambios en tecnología, demografía y objetivos de
negocios.

En reingeniería, los administradores rompen con
los procesos pasados de moda y principios fundamentales de
diseño y crean nuevos; para ello, la reingeniería
requiere de la observación de los procesos fundamentales
de los negocios desde una perspectiva funcional para formar un
equipo que represente las unidades funcionales involucrados en el
proceso que sufrirá reingeniería y todos las
unidades que dependen de él.

El equipo deber analizar y encuestar los procesos
existentes hasta que realmente entiendan que los procesos
están tratando de terminar. En lugar de que el equipo
busque oportunidades de mejorar el proceso, deberá
determinar cuales de esos pasos realmente agregan valor y buscar
nuevas formas de registrar los resultados.

1.3 LA REINGENIERÍA VS LOS PROGRAMAS DE MEJORA
INCREMENTAL

Como ya hemos visto, la reingeniería consiste en
un cambio radical y si hay algo que las empresas quieren evitar
es el cambio radical. La mejora continua incremental – en
contraposición a la Reingeniería de Procesos
– está más de acuerdo con la manera como las
organizaciones se entienden naturalmente con el cambio. La mejora
continua hace hincapié en cambios pequeños,
incrementales; el objeto es mejorar lo que una
organización ya está haciendo.

Estos cambios incrementales para mejorar el rendimiento
de los negocios revisten formas distintas, por ejemplo, calidad,
automatización, reorganización,
reducción o rectificación del tamaño. Pero
¿qué ocurre cuando uno aplica técnicas
de mejora continua en un mundo de negocios en que el ritmo del
cambio ya no es continuo? Termina viéndose un panorama
sembrado de programas fallidos de mejora, y el fracaso de las
personas bienintencionadas que han tratado de sacarlos adelante.
La falla reside más bien en un mundo que
súbitamente exige avances decisivos en lugar de cambios
incrementales.

La Reingeniería de Procesos se diferencia de los
programas de mejora incremental continua en varias formas
importantes (figura 1.1). Reingeniería de Procesos
según Manganelli [Mang 95] es:

• No sólo automatización, aún
  cuando con frecuencia utiliza tecnología en formas
  creativas e innovadoras.
• No sólo reorganización, aun cuando
  casi siempre requiere cambios organizacionales.
• No sólo reducción del tamaño,
  aun cuando esto generalmente mejora la
  productividad.
• No sólo calidad, aún cuando casi
  siempre se enfoca en la satisfacción del cliente y en
  los procesos que la apoyan.

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

La Reingeniería de Procesos es un enfoque
equilibrado que puede contener elementos de los programas
más tradicionales de mejoramiento con los cuales a veces
se confunde. Pero la Reingeniería de Procesos es mucho
más.

En primer lugar, la Reingeniería de Procesos
busca avances decisivos en medidas importantes del rendimiento,
más que mejoras incrementales. En segundo lugar, busca
metas multifacéticos de mejoramiento, incluyendo calidad,
costos, flexibilidad, rapidez, precisión y
satisfacción de los clientes, todo
simultáneamente, mientras que los demás programas
se concentran en unas pocas metas o relaciones entre
ellas.

Para lograr estos resultados, la reingeniería de
procesos adopta una perspectiva de procesos sobre los negocios,
mientras que otros programas conservan una perspectiva funcional
u organizacional. La gestión de
calidad total si examina los procesos, pero para mejorarlos
incrementalmente, no para rediseñarlos.

También comprende la voluntad de pensar
cómo debe hacerse el trabajo, y hasta de descartar
totalmente las prácticas corrientes si se ve que es
necesario. Finalmente, la reingeniería de procesos adopta
para la mejora de los negocios un enfoque integral que abarca
tanto los aspectos técnicos de los procesos
(tecnología, normas,
procedimientos, sistemas y controles) como los aspectos sociales
(organización, dotación de personal, políticas,
cargos, planes de carreras e incentivos). En
otras palabras, la reingeniería de procesos multiplica
el poder de la tecnología y faculta a las
personas.

CAPÍTULO 2

SISTEMAS DE INFORMACIÓN
HEREDADOS Y REINGENIERIA DE SOFTWARE

Ya que se definió el concepto de
reingeniería desde el ámbito administrativo en el
Capítulo anterior, se podrá abordar el tema de
reingeniería de software. En el subtema 2.1 se detalla las
características de los sistemas de información
heredados, que son aquellos a los que es necesario aplicarles
reingeniería. En el segundo subtema se emprende por
completo el concepto de reingeniería de software y sus
objetivos. En el siguiente subtema se menciona la importancia de
aplicar reingeniería de software en los sistemas de
información heredados. Al final de este Capítulo,
se explica el modelo que propone Sneed para calcular los costes
de un proyecto de reingeniería.

2.1 SISTEMAS DE INFORMACIÓN
HEREDADOS

Los sistemas de información heredados
generalmente son la columna vertebral del flujo de
información de las empresas y la principal forma de
agruparla. Un Sistema de Información
Heredado (LIS por sus siglas en ingles Legacy Information
System) puede ser definido como "cualquier sistema de
información que significativamente se resiste a la
modificación y evolución" [Brod 94]. Tales LISs
pueden causar serios problemas a la
organización:

• Los LISs casi siempre son ejecutados sobre hardware
  obsoleto que son lentos y caros de mantener.
• El mantenimiento del software puede ser caro,
  porque carecen de la documentación necesaria para el
  entendimiento de los detalles del sistema y su seguimiento es
  costoso y consume mucho tiempo.
• Una falta de interfaces limpias hace que la
  integración de los LISs con otros
  sistemas sea difícil.
• Los LISs son también difíciles mas no
  imposibles ampliarlos.

La solución a estos problemas según
Weiderman [Weid 97] caen en las siguientes
categorías:

• Mantenimiento: es un proceso incremental e
  iterativo en el cual se hacen pequeñas modificaciones
  al sistema.
• Modernización: implica cambios
  más extensos que el mantenimiento pero conserva partes
  considerables del sistema existente.
• Remplazarlo: el cual consiste en reconstruir
  desde los inicios al sistema. Esta solución consiste
  en aplicarle al sistema actividades de
  Reingeniería.

2.2 REINGENIERÍA DE SOFTWARE

Reingeniería de Software es una forma de
modernización para mejorar las capacidades y/o
mantenibilidad de los sistemas de información heredados
mediante la aplicación de tecnologías y practicas
modernas. La Reingeniería de Software ofrece una disciplina de
preparación para migrar un sistema de información
heredado hacia un sistema evolucionable. El proceso aplica
principios de ingeniería para un sistema existente para
encontrar nuevos requerimientos.

"El Instituto de Ingeniería de software (SEI)
desarrollo una definición de Reingeniería como:
Reingeniería es la transformación
sistemática de un sistema existente dentro de una nueva
forma de realizar mejoramientos de calidad en unas operaciones,
capacidad del sistema, funcionabilidad, rendimiento o
evolucionabilidad a bajo costo, agendas o riesgos para
el cliente." [Till 95]

El propósito de la reingeniería es que los
sistemas existentes tomen ventajas de las nuevas
tecnologías y habilitar el nuevo esfuerzo de
desarrollo para que aproveche las ventajas de reutilizar sistemas
existentes. La reingeniería tiene el potencial de mejorar
la productividad y calidad del software a través de todo
el ciclo de
vida.

La reingeniería casi siempre implica cambiar la
forma de un programa y mejorar su documentación. En este
caso, la funcionabilidad del programa no es cambiada; sólo
su forma es modificada. En otros casos, la reingeniería va
más allá de la forma e incluye rediseñar
para cambiar la funcionabilidad del programa para buscar mejores
requerimientos de usuario.

Los objetivos de la reingeniería son: [McCl
92]

• Proporcionar asistencia automatizada para el
  mantenimiento.
• Reducir los errores y costos del
  mantenimiento.
• Incrementar la intercambiabilidad del grupo de
  mantenimiento.
• Hacer sistemas fáciles de entender, cambiar
  y probar.
• Habilitar la conversión y migración de sistemas.
• Reforzar el apego a estándares.
• Mejorar la respuesta a peticiones de
  mantenimiento.
• Mejorar el estado
  de ánimo del grupo de mantenimiento.
• Proteger y extender la vida del
  sistema.
• Usar CASE para apoyar sistemas
  existentes
• Re-usar componentes de sistema
  existentes.

La reingeniería puede ayudar a entender sistemas
existentes y descubrir los componentes de software que son
comunes en todo el sistema. Estos componentes comunes pueden ser
re-usados en el desarrollo (o redesarrollo) de sistemas y
así reducir el tiempo y riesgos del desarrollo de
sistemas.

La reingeniería requiere tiempo; implica un coste
de dinero enorme
y absorbe recursos que de
otro modo se podrían emplear en preocupaciones más
inmediatas. Por todo esto, la reingeniería no se lleva a
cabo en unos pocos meses, ni siquiera en unos pocos años.
La reingeniería de sistemas de información es una
actividad que absorberá recursos de las tecnologías
de la información durante muchos años.

2.3 LA IMPORTANCIA DE APLICAR REINGENIERÍA DE
SOFTWARE

Las Viejas Aplicaciones

Mucha gente al ver las grandes y viejas mansiones queda
asombrado de su belleza, pero no se preguntan que tan bien se
puede vivir en ellas. Las personas que lo hacen dicen que es una
pesadilla mantenerlas. Todas ellas fueron construidas con viejas
tecnología estándar. Sus paredes externas no tienen
aislamiento. El alambrado eléctrico tiene limitaciones y
claramente es inadecuada para las necesidades de energía
de hoy y su cableado decadente crea un severo peligro
eléctrico.

Los viejos sistemas son muy similares a los grandes y
viejos edificios. Ellos tienen los mismos problemas de
mantenimiento, un hecho en gran parte irreconocible por parte de
la comunidad
corporativa. Muchos de esos edificios son demolidos por que no
son mantenibles y ya no sirven para las necesidades de sus
ocupantes.

Las viejas computadoras
tal vez se puedan ver solamente en museos. Pero en muchos casos,
software escrito para viejos modelos de computadora
están ejecutándose hoy en día. Un caso
extremo es el de un software escrito para una IBM 1401 Autocoder.
Cuando la compañía remplazó la 1401 con una
IBM 360/40, compraron un emulador de la 1401 para poder ejecutar
el software. Esa aplicación hoy día corre en una PC
– la compañía compro otro
emulador.

Los clientes demandan que las nuevas capacidades sean
agregadas al código
escrito en sus viejos sistemas. Casi siempre, las empresas
encuentran que no pueden modificar su código – el
programador que lo mantenía murió recientemente o
nadie sabe programar en el lenguaje en
el que fue escrito. Por lo que la funcionalidad de ese programa
quedará así para siempre.

La siguiente lista son las razones por las que es
aplicable la reingeniería a los sistemas de
información heredados:

• Frecuentes fallas de producción (fiabilidad
  cuestionable).
• Problemas de rendimiento.
• Tecnología obsoleta.
• Problemas de integración del
  sistema.
• Código de calida pobre.
• Dificultad (peligroso) al cambio.
• Dificultad para probar.
• Mantenimiento caro.
• Incremento de problemas del sistema.

Estas razones pueden ser solucionadas al aplicar un
proceso de mantenimiento de software, pero cuando dicho
mantenimiento deja de ser viable, entonces se toma la
decisión de aplicar reingeniería.

Nuevas Ideas, Nuevo Software

Aunque la reingeniería se usa principalmente
durante el mantenimiento del software, va mas allá de una
simple ayuda para el mantenimiento. La reingeniería es el
puente desde viejas tecnologías hacía nuevas
tecnologías que las organizaciones deben usar en la
actualidad para responder al cambio de requerimientos del
negocio.

Los viejos programas representan la tecnología
del ayer. Ahora sabemos que los años tienen cuatro
dígitos y no dos, que los datos pueden ser
manejados mejor en bases de datos y
que tenemos nuevos diseños de construcción y lenguajes de
programación que permiten diseñar programas
notablemente mantenibles.

Cuando el costo de mantener viejos edificios es
altamente excesivo, se remplazan estos edificios. Nosotros
deberíamos hacer lo mismo con los programas. Los programas
no se hacen obsoletos al paso del tiempo ya que fueron escritos
para hardware y sistemas
operativos que ya no existen, muchos están llenos de
características y parches no documentados.

Sólo cuando hayamos aprendido a que es mejor
invertir en nuevo hardware y nuevos edificios podremos reconocer
el valor de remplazar los viejos sistemas
raquíticos.

2.4 COSTES Y BENEFICIOS DE LA
REINGENIERÍA.

Antes de reconstruir un sistema en uso, es altamente
recomendable analizar las diversas alternativas
disponibles:

• Dejar el producto como está.
• Adquirir uno en el mercado
  que realice la misma función.
• Reconstruirlo.

Evidentemente, elegiremos la opción que mejor
relación coste/beneficio nos ofrezca. Para calcular los
costes de un proyecto de reingeniería, Harry Sneed [Snee
95] propone un modelo basado en cuatro etapas:

• Justificación del proyecto de
  reingeniería.
• Análisis de la cartera de
  aplicaciones.
• Estimación de costes.
• Análisis de costes / beneficios.

2.4.1 Justificación Del Proyecto De
Reingeniería.

Para justificar un proyecto de reingeniería se
requiere de un análisis del software existente, de los
procesos de mantenimiento actuales y del valor de negocio que
tienen las aplicaciones; todo esto con el objeto de hacer una
evaluación en posibles aumentos de valores sobre
estos tres factores.

La mayoría de las organizaciones sólo
toman en consideración los procesos de reingeniería
cuando el coste de un nuevo desarrollo es demasiado alto. En
cualquier caso, y aunque a primera vista parezca la única
o la mejor alternativa, es necesario confirmar la necesidad de
reconstruir el sistema.

Existen cuatro operaciones que nos pueden dar una idea
de los costes del proyecto y del valor del software actual dentro
del negocio:

• Introducción de un sistema de
  evaluación de los costes del mantenimiento. Es
  recomendable que esta tarea la lleve a cabo la
  organización anticipándose con suficiente
  anticipación al momento en que se percibe la necesidad
  de aplicar reingeniería.
• Análisis de la calidad del software actual,
  para lo cual pueden utilizarse auditores de código
  automáticos que proporcionan datos del tamaño,
  complejidad y métricas de calidad del código
  fuente. Estos valores son incorporados a una base de
  datos que es utilizada por otra herramienta para realizar
  comparaciones y obtener resultados.
• Análisis de los costes de mantenimiento: Se
  proponen tres métricas para medir los procesos de
  mantenimiento: "Dominio del
  impacto" o proporción de instrucciones y elementos de
  datos afectados por una tarea de mantenimiento con respecto
  al total de instrucciones y elementos de datos del sistema;
  "Esfuerzo empleado", que es el número de horas
  dedicadas a tareas de mantenimiento, con lo que se puede
  obtener una media del número de horas por tarea de
  mantenimiento; y "Tasa de errores de segundo nivel", que es
  el número de errores causados por acciones
  de mantenimiento. Si se observa que estas tres medidas se
  incrementan, es muy probable que los costes de mantenimiento
  se incrementen con el tiempo.
• Evaluación del valor de negocio del sistema
  actual, que es realizado por la dirección de la
  organización.

2.4.2 Análisis De La Cartera De
Aplicaciones.

En esta etapa se cotejan la calidad técnica y el
valor de negocio de cada aplicación, con el objetivo de
construir una lista de aplicaciones, ordenada según sus
prioridades en el proceso de reingeniería.

La calidad técnica de un producto es una medida
relativa, dependiente de cada organización, que se calcula
en función de diversas características (complejidad
ciclomática o errores/KLDC, por ejemplo).

Para cada variable que interviene en la calidad
técnica e fijan unos límites
inferior y superior (que representan los valores
máximos y mínimo de calidad). Para hallar el nivel
de calidad de la variable considerada se puede utilizar la
siguiente formula:

 Por ejemplo, si establecemos los valores
mínimo y máximo de calidad en 0 y 7 errores por
KLDC, y actualmente hay 3, Ci = 0.571.

Asociando un punto de un plano para cada
aplicación, e interpretando el valor de negocio y la
calidad técnica como coordenadas de estos puntos, se puede
representar como en el diagrama de la
siguiente figura [Piat 00]:

Las aplicaciones situadas en el cuadrante superior
izquierdo tienen alta calidad y bajo valor de negocio, por lo que
no requieren reingeniería; las situadas en el cuadrante
inferior izquierdo tienen poco valor en ambos parámetros,
por lo que pueden ser desarrolladas de nuevo o remplazadas por
productos
comerciales; las del superior derecho tienen un gran valor de
negocio y alta calidad: se les puede aplicar reingeniería,
pero sin excesiva prioridad; las del inferior derecho tienen alto
valor de negocio y baja calidad técnica, por lo que
serán las primeras candidatas a la
reingeniería.

2.4.3 Estimación De Costes.

Se realiza identificando y ponderando, mediante
métricas adecuadas, todos los componentes del software que
se van a modificar.

Se deben considerar los costes de cada proyecto de
reingeniería: si éstos son superiores a los
beneficios, la reingeniería no será una alternativa
viable y la aplicación deberá ser desarrollada de
nuevo o bien adquirirse en el mercado.

Para estimar los costes de la reingeniería, se
tienen ciertas ventajas respecto a la misma estimación en
proyectos de
ingeniería directa: no se debe calcular factores
influyentes como el número de líneas de
código, sentencias ejecutables, elementos de datos,
accesos a archivos, etc.,
ya que son medidas que se pueden tomar directamente de la
aplicación.

Se aconseja utilizar como variables para
calcular los costes las que se ofrecen a continuación, y
que deben ser debidamente ponderadas en función de su
influencia en el coste total:

• Número de líneas de código no
  comentadas.
• Coste de los casos de prueba, que se calcula
  multiplicando el coste medio de cada caso de prueba por el
  número de éstos, que es función de la
  complejidad ciclomática del problema.
• Número de accesos a archivos, bases de datos
  y campos. En la ponderación de estas entradas/salidas
  consideramos la complejidad de las estructuras de
  información y el grado de independencia de la aplicación respecto
  de los datos.
• Número de operaciones que realizan los
  usuarios de la aplicación, número de ventanas,
  número de informes,
  etc., para el caso de las interfaces de usuario.

2.4.4 Análisis De
Costes/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).

El beneficio proporcionado por continuar manteniendo el
producto sin reingeniería es el siguiente:

BM = [P3
– (P1 + P2)] *
P16

Deberá retocarse la fórmula cuando los
diversos costes varíen de un año para
otro.

Si se desarrolla de nuevo el sistema, se obtiene este
beneficio:

BD = [(P12
– (P10 + P11)) * (P16
– P14) – (P13 *
P15)] – BM

El beneficio producido por la reingeniería
es:

BR = [(P6
– (P4 + P5)) * (P16
– P8) – (P7 * P9)]
– BM

Donde:

P1 = Coste de mantenimiento actual para una
aplicación (anual).

P2 = Coste de operación de una
aplicación (anual).

P3 = Valor del negocio actual
(anual).

P4 = Coste previsto de mantenimiento tras la
reingeniería (anual).

P5 = Coste previsto de operaciones tras la
reingeniería (anual).

P6 = Valor de negocio previsto tras la
reingeniería (anual).

P7 = Coste estimado de la
reingeniería.

P8 = Duración estimada de la
reingeniería.

P9 = Factor de riesgo de la
reingeniería.

P10 = Coste previsto de mantenimiento tras el
redesarrollo (anual).

P11 = Coste previsto de operaciones tras el
redesarrollo (anual).

P12 = Valor de negocio previsto el nuevo
sistema (anual).

P13 = Coste estimado del
redesarrollo.

P14 = Duración estimada del
redesarrollo.

P15 = Factor de riesgo del
redesarrollo.

P16 = Vida esperada del sistema.

CAPÍTULO 3

METODOS Y MODELOS DE LA
REINGENIERÍA DE SOFTWARE

Este Capítulo explica de una forma muy breve los
métodos y modelos que son utilizados para llevar a cabo de
manera satisfactoria la actividad de reingeniería. Al
comienzo del Capítulo se alude al método de
análisis de opciones para reingeniería (OAR por sus
siglas en ingles de Options Analysis for Reingeneering) dando su
definición y explicando la necesidad de aplicarlo, se
menciona de forma breve las actividades principales y
especializadas de este método así como la
estructura de ellas. En los siguientes dos subtemas se trata a
dos modelos utilizados para la reingeniería: El modelo
herradura y el modelo cíclico, explicando brevemente los
niveles o actividades de cada uno.

3.1 EL METODO ANÁLISIS DE OPCIONES PARA
REINGENIERÍA ("OPTIONS ANALYSIS FOR REINGENEERING"
(OAR))

3.1.1 Definición y Necesidad Del
Análisis De Opciones Para
Reingeniería

El Análisis de Opciones para Reingeniería
(OAR por sus siglas en ingles de Options Analysis for
Reengineering) es un método sistemático, de
arquitectura central y de toma de
decisiones para la identificación y extracción
de componentes dentro de grandes y complejos sistemas de
software. La extracción envuelve rehabilitación de
partes de un sistema viejo para su re-uso. OAR identifica
componentes de arquitectura potencialmente relevantes y analiza
los cambios requeridos para usarlos en una línea de
producción de software o nuevas arquitecturas de software.
En esencia, OAR proporciona un conjunto de opciones de
extracción junto con estimación de costos, esfuerzo
y riesgos asociados con estas opciones.

Muchas organizaciones se comprometen a esfuerzos para
actualizar sus sistemas de software intensivos y para establecer
más formas eficientes de desarrollo de software. Una
tendencia emergente había sido la implementación de
líneas de producción de software para realizar
medidas de economías y grandes eficiencias en el
desarrollo de de software [Clem 01].

Desde entonces muchas organizaciones tienen una
substancial base de software heredado activo, algunas
líneas de producción de desarrollo o esfuerzos de
migración. Sin embargo, hasta ahora, estas habían
sido formas no sistemáticas para identificar componentes
para re-uso y para entender los tipos de cambios requeridos para
insertar componentes de sistemas heredados dentro de una
línea de producción de software o una nueva
arquitectura [Mull 00]. En la mayoría de los casos, las
opciones habían sido para cualquiera experimentar el
costoso y alto riesgoso proceso de reingeniería de un
sistema completo o para simplemente crear los componentes
requeridos o sistemas desde cero.

La extracción de componentes casi siempre
había sido discutido como una alternativa, pero
requería el entendimiento de que tipos de componentes
valían la pena extraer y como se debería extraer.
Los siguientes puntos son motivos para el cambio:

• Componentes existentes casi siempre eran pobremente
  estructurados y documentados.
• Componentes existentes diferían en niveles
  de granuralidad.
• No había una guía clara sobre como
  salvar componentes.

OAR proporciona un acercamiento sistemático para
direccionar esos puntos y tomar decisiones requeridas para el
costo efectivo y eficiente de extraer componentes de sistemas
heredados.

El método OAR consiste de cinco actividades
principales con tareas escalables. Esas tareas son representadas
en la figura 3.1 y resumen las siguientes secciones.

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

Estas actividades serán abordadas brevemente en
las siguientes secciones.

3.1.2 ACTIVIDADES PRINCIPALES DEL METODO
OAR

Establecimiento del contexto de extracción
(ECE).

Es importante para el equipo de OAR entender el contexto
para la extracción. Cómo un resultado, la primer
actividad de OAR consiste en entrevistar a los accionistas y
estudiar la línea de producción de la
organización o nuevos requerimientos de sistema, base
heredada y expectativas para la extracción de componentes
heredados. Estos esfuerzos establecen una línea base de un
conjunto de metas, expectaciones y necesidades de componentes.
Esto también descubre los controladores de programa y
técnicos para la toma de decisiones.

Inventario De Componentes (IC).

Después del ECE, el equipo OAR identifica los
componentes del sistema heredado que potencialmente pueden ser
extraídos para usarlos en una línea de
producción o en una nueva arquitectura de
software.

Durante esta actividad, los miembros del equipo
identifican componentes de líneas de producción
necesarios y evalúan los componentes heredados basados en
esos criterios. Aquellos que no descubran los criterios
están incapacitados para continuar con el proceso de
reingeiería. Esta actividad resulta en un inventario de los
componentes heredados candidatos. La actividad de IC tiene seis
tareas:

1. Identificar características de los componentes
   necesarios:

• Determina las características requeridas de
  los potenciales componentes heredados.

1. Identifica las características satisfactorias
   de los componentes:

• Crea una tabla de componentes heredados con
  detalles de sus características.
• Filtra los componentes que no satisfacen las
  características requeridas.

1. Compara las necesidades de componentes:

• Compara los componentes heredados en contraste con
  la línea de producción de componentes
  necesarios.

1. Inventario de componentes candidatos:

• Actualiza la tabla de componentes con mas detalles
  acerca de los componentes candidatos
  seleccionados.

1. Produce tópicos de
   extracción

• Revisa cualquier tópico de extracción
  e inquietudes que fueron identificados durante la
  actividad.

1. Revisión del calendario OAR:

• Actualiza el calendario de OAR si fuera
  necesario.

Análisis de componentes candidatos
(ACC).

El siguiente paso de los miembros del equipo es analizar
el conjunto de candidatos de componentes heredados para extraer
los tipos de cambios que son requeridos. Esta actividad tiene
seis tareas:

1. Selección de componentes
   deseables.

• Determinar criterios deseables para cada componente
  heredado.
• Deja fuere aquellos que no satisfacen esos
  criterios.

1. Identifica los componentes "Tal como están y
   de caja negra"

• Determina aquellos componentes que pueden ser
  tapados o usados "tal como están".

1. Identifica componentes de caja blanca.

• Determina aquellos componentes que
  necesitarán ser modificados.

1. Determina cambios requeridos:

• Determina los tipos de cambio que cada componente
  necesitará, el costo y esfuerzo involucrados, el nivel
  de dificultad y riesgo, el costo y esfuerzo comparativo para
  el desarrollo de componentes desde cero.

1. Producción de tópicos de
   extracción:

• Revisa cualquier tópico de extracción
  e inquietudes que fueron identificados durante la
  actividad.

1. Revisa el calendario OAR:

• Actualiza el calendario OAR si fuera
  necesario.

Plan de opciones de extracción
(POE).

Dado el conjunto de componentes candidatos analizados,
el equipo desarrollar alternativas para la extracción
basada en consideraciones de calendario, costo, esfuerzo, riesgo
y recursos. El equipo OAR también filtra una vez
más los componentes candidatos y analiza el impacto de
agregación de diferentes componentes.

El POE tiene siete tareas:

1. Selecciona componentes favorables:

• Desarrolla criterios, tales como costo o niveles de
  esfuerzo requeridos.

1. Ejecución de intercambio de
   componentes:

• Identifica un componente (o combinación) por
  linea de producción de componentes
  necesarios.

1. Forma opciones de componentes:

• Desarrolla criterios para agregar
  componentes.

1. Determina costos comparativos y
   esfuerzos:

• Compara el costo por cada agregación con el
  costo de desarrollar desde cero.

1. Analiza dificultad o riesgo:

• Determina el nivel de dificultada y el riesgo
  involucrados por cada agregación.

6. Producción de tópicos de
extracción:

• Revisa cualquier tópico de extracción
  e inquietudes que fueron identificados durante la
  actividad.

1. Revisa el calendario OAR:

• Actualiza el calendario OAR si fuera
  necesario.

Selección de opciones de extracción
(SOE).

Finalmente, los miembros del equipo seleccionan la mejor
opción de extracción o combinación de
opciones para programas y consideraciones técnicas.
Después de evaluar cada opción de
extracción, ellos preparan un resumen que presenta y
justifica sus elecciones.

La actividad SOE tiene cinco tareas:

1. Elegir la mejor opción:

• Determina los controladores para seleccionar entre
  las opciones.
• Selecciona una opción o combinación
  de ellas.

1. Verificación de opción:

• Guarda todos los detalles acerca de cada una de las
  opciones escogidas.

1. Identifica componentes necesarios
   satisfechos.

• Completa la lista final de componentes necesarios
  satisfechos y no satisfechos a través de las opciones
  seleccionadas.

1. Presentación de descubrimientos.

• Prepara la presentación de descubrimientos
  que proporciona detalles acerca de las opciones
  seleccionadas.

1. Producción de resumen.

• Producción de un reporte final detallando
  las opciones seleccionadas y las razones para esas
  elecciones.

3.1.3 Tareas Especializadas.

Cada actividad también tiene un potencial
conjunto de actividades especializadas para direccionar
circunstancias que pueden de otro modo imposibilitar la
cumplimiento de la actividad. Estas tareas pueden aplicarse bajo
las siguientes condiciones:

• El criterio existente para las actividades
  prescritas no han sido satisfechas.
• Mas trabajo puede ser requerido para que la
  actividad sea razonablemente completada en la actividad de
  las tareas involucradas.
• Se requieren datos adicionales para completar una
  tarea particular o para direccionar necesidades especiales
  del cliente.
• Existe una necesidad de complementar tareas
  estándares OAR para afinar la toma de decisiones y
  reducir riesgos.

La siguiente sección incluye ejemplos de tareas
especializadas.

3.1.4 Estructura De Actividades

Cada actividad esta compuesta de tareas y sub-tareas
diseñadas para contestar un conjunto de preguntas de
actividades especificas. Esas preguntas definirán la
actividad y también servirán como una lista de
comprobación para ser incluidas en los criterios de cada
actividad.

Las actividades están estructuradas de acuerdo a
un formato "EITVOX (Entry Criteria, Inputs, Task, Validation,
Outputs, Exit Criteria)" [Berg 01] que se muestra a
continuación:

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

Las siguientes secciones muestran cómo la
actividad ECE es estructurada de acuerdo al el formato EITVOX.
Cada una de las otras actividades siguen este formato. Bergey et
al., proporciona este nivel de detalle. [Berg 01]

3.1.4.1 Ejemplo De Actividad: Establecimiento Del
Contexto De Extracción.

Preguntas fundamentales.

Las tareas de ECE fueron desarrolladas para direccionar
un conjunto de cuestiones que incluyen:

• ¿Qué esperan los administradores del
  esfuerzo de extracción?
• ¿Cuáles son los requerimientos (ej.
  Calidad de atributos) y controladores primarios (ej.
  Prioridades y restricciones) para la extracción de
  componentes?
• ¿Qué restricciones explicitas (e
  implícitas), reglas y suposiciones
  aplican?
• ¿Cuál línea de
  producción de componentes específicos
  necesitarán ser direccionados?
• ¿Cuáles sistemas heredados son
  relevantes y que documentos
  están disponibles?
• ¿Qué documentos disponibles describen
  los componentes heredados (ej. Funcionalidad, granuralidad e
  interfaces)?
• ¿Cuál es el nivel del estado de
  preparación de las organizaciones en los
  términos de experiencia, habilidades, recursos
  disponibles y margen de tiempo de OAR?

El conjunto completo de estas cuestiones fundamentales
se revisan durante la validación para asegurar que fueron
respondidas satisfactoriamente.

Criterios de entrada.

Los siguientes criterios de entrada se analizan para
determinar si hay suficientes datos y tecnológica
disponible para ejecutar la actividad exitosamente. Los criterios
de entrada para esta actividad son:

• La organización ha decidido mover una
  línea de producción y quiere calcular
  rápidamente la viabilidad de la extracción de
  componentes.
• La arquitectura de línea de
  producción ha sido definida y necesita componentes que
  han sido identificados.
• Un conjunto de metas de extracción y
  objetivos han sido establecidos.
• Uno de tres sistemas heredados ha sido identificado
  como la fuente de componentes para la
  extracción.
• Un "equipo de extracción" ha sido
  establecido y esta disponible para la duración de
  actividades de OAR.

Si el criterio de entrada no es satisfecho, una tarea
especializada debe ser desarrollada.

Artefactos de entrada.

Cada actividad se basa en un conjunto de artefactos de
soporte. Los siguientes artefactos se requieren para el
establecimiento del contexto de extracción:

• Metas y objetivos para el esfuerzo de
  extracción.
• Requerimientos de la línea de
  producción y componentes necesarios.
• Documentación que describe el alcance de la
  línea de producción, arquitectura y
  especificaciones de componentes.
• Visión general del sistema heredado y
  documentación de componentes.
• Reportes de experiencia de otros esfuerzos de
  extracción/reingeniería.
• Perfil de calendario OAR
  típico.*

La actividad ECE se divide en diez tareas. Esas tareas
son ejecutadas en orden. Varias de estas tareas son subdivididas.
Para ayudar al equipo OAR a ejecutar las tareas y sub-tareas, el
SEI (Software Engeneering Institute) desarrollo plantillas de
ejecución y datos. Estas plantillas de ejecución
muestran los pasos, fundamentos y suposiciones para las tareas y
sub-tareas. Las plantillas de datos proporcionan ejemplos
típicos y ofrecen varios puntos de inicio para producir
información de los clientes.

Las tareas logran lo siguiente:

1. Revisión de metas y objetivos:

• Determina las metas y objetivos de los accionistas
  para el esfuerzo de extracción.

1. Revisión de Línea de
   producción / Nuevos requerimientos de
   sistema:

• Identificar línea de producción o
  nuevos requerimientos de sistema.

1. Revisión y selección de componentes
   necesarios:

• Identificar componentes necesarios que
  deberán ser direccionados para la
  extracción.

_________________

* El "Perfil de calendario OAR" es una plantilla
proporcionada por el SEI

Estructura de tareas.

1. Revisión de sistemas heredados y
   documentación:

• Revisión de sistemas heredados y
  documentación de componentes disponibles.

1. Determinar controladores de
   extracción:

• Identificar controladores programáticos y
  técnicos.

1. Validar metas y objetivos:

• Determinar la compatibilidad de los controladores
  de extracción con las metas y objetivos.

1. Identificar componentes candidatos:

• Determinar criterios para componentes heredados de
  gran valor.
• Selección del conjunto de componentes
  candidatos.

1. Producción de tópicos de
   extracción:

• Revisión de cualquier tópico de
  extracción e inquietudes que fueron identificados
  durante la actividad.

1. Evaluar el estado de
   preparación:

• Determinar los niveles de estado de
  preparación de la organización.

1. Revisión del calendario OAR:

• Actualizar el calendario OAR si fuera
  necesario.

Algunas tareas tienen sub-tareas. La tarea cuatro por
ejemplo es subdividida en:

• Revisión de sistemas heredados.
• Revisión de documentación de
  componentes.

Ejemplo de ejecución y plantillas de
datos.

La plantilla de ejecución (tabla 3), especifica
como ejecutar la revisión de documentación de
componentes (sub-tarea 4.2).

La plantilla de datos "EMC-4.2-DT" (tabla 3) sugiere que
los siguientes tipos de datos
deben ser recolectados:

• Lista de componentes heredados.
• Documentación de componentes (ej.
  Funcionalidad y descripción de interfaces).
• Código fuente de componentes
  heredados.
• Historia de mantenimiento para componentes
  heredados (ej. Costo, modificación, margen de tiempo,
  recursos de utilización).

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

Validación.

Después de que las tareas fueron completadas, las
preguntas fundamentales para la actividad son revisadas. Algunos
de los criterios de validación para el ECE son los
siguientes:

• Las expectaciones son esquematizadas y
  entendidas.
• Todos los sistemas de información heredados
  son identificados.
• Un conjunto de 10 a 20 componentes de línea
  de producción necesarios con alto potencial han sido
  seleccionadas para ser satisfechas a través de la
  extracción.
• Controladores y prioridades son identificados y
  entendidos.
• Un conjunto de 15 a 30 componentes heredados han
  sido seleccionados como candidatos para la
  extracción.
• El nivel de preparación de extracción
  ha sido evaluado.

Artefactos de salida.

Establecer contextos de extracción produce los
siguientes artefactos de salida:

• Un conjunto de relevantes sistemas de
  información heredados y
  documentación.
• Un conjunto de componentes de línea de
  producción necesarios.
• Programas principales y controladores
  técnicos.
• Una conjunto de componentes heredados y
  documentación de componentes asociados.
• Evaluación del estado de
  preparación.
• Lista de tópicos de extracción e
  inquietudes.
• Revisión del perfil del calendario
  OAR.

Criterios de salida.

Antes de completar el establecimiento del contexto de
extracción, es necesario cubrir los siguientes criterios
de salida:

• El equipo de extracción ha identificado un
  conjunto razonable de líneas de producción
  necesarias y componentes candidatos.
• La expectación de la organización es
  consistente con los niveles del estado de
  preparación.
• El perfil del calendario OAR ha sido revisado y
  cualquier cambio necesario ha sido aceptado.
• Todos los artefactos de salida de esta actividad
  han sido producidos.
• Todas las preguntas fundamentales para esta
  actividad han sido contestadas
  satisfactoriamente.

Ejemplos de tareas especializadas.

Si los criterios de salida no son cumplidos, puede ser
apropiado una tarea especializada. Los siguientes son ejemplos de
tareas especializadas para la actividad de establecer del
contexto de extracción:

• Impulsar los esfuerzos para identificar los
  controladores de extracción y resolver los problemas
  programáticos y tópicos
  técnicos.
• Impulsar la definición de los requerimientos
  de línea de producción y componentes necesarios
  en términos de funcionalidad e interfaces.
• Aislando e identificando la funcionalidad e
  interfaces de los componentes heredados.
• Desarrollando los niveles requeridos de
  documentación para los componentes
  heredados.

3.2 El MODELO HERRADURA

Los tres procesos básicos – análisis
de un sistema existente, transformación lógica
y desarrollo de un nuevo sistema – forman la base del
modelo de herradura. El primer proceso sube el extremo izquierdo
de la herradura, el segundo cruza la parte superior y el tercero
baja por el extremo derecho de la herradura. La riqueza del
modelo de herradura son los tres niveles de abstracción
que pueden ser adoptados para las descripciones lógicas.
Conceptualmente, este puede ser a través de un conjunto de
herraduras anidadas. Las descripciones lógicas pueden ser
artefactos tan concretos y simples como el código fuente
del sistema o tan complejos y abstractos como la arquitectura del
sistema. El propósito de la metáfora visual es para
integrar las vistas de reingeniería a nivel de
código y arquitectónico del mundo. [Berg
99]

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

En su más pura y completa forma, el primer
proceso recupera la arquitectura por medio de la
extracción de artefactos desde el código fuente.
Esta estructura recuperada es analizada para determinar si esta
se adapta a la arquitectura antes diseñada. La
arquitectura descubierta también es evaluada con respecto
a un número de calidad de atributos tales como
rendimiento, modificabilidad, seguridad o
confiabilidad.

El segundo proceso es la transformación de
arquitectura. En este caso, la arquitectura antes construida es
recuperada y es reingenierada para hacerla una nueva arquitectura
deseable. Esta es reevaluada contra las metas de calidad del
sistema y sujetas a otras restricciones organizacionales y
económicas.

El tercer proceso del modelo de herradura usa el
"Architecture-Based Development (ABD)" [Bass99] para ejemplificar
la arquitectura deseable. En este proceso, ya empaquetados los
tópicos son decididas e interconectadas las estrategias
elegidas. Los artefactos a nivel de código del sistema de
información heredado son normalmente tapados o reescritos
para adaptarlos dentro de la nueva arquitectura.

3.2.1 Los Tres Niveles Del Modelo
Herradura

En el modelo herradura existen tres niveles:

• "Representación de la estructura de
  código", el cual incluye código fuente y
  artefactos tales como árboles de sintaxis abstractos
  (Abstract syntax tree; ASTs) y diagramas de
  flujo obtenidos a través del análisis
  gramatical y operaciones analíticas de
  rutina.
• "Representación del nivel funcional", el
  cual describe la relación entre las funciones del
  programa (llamadas), datos (funciones y relaciones de datos),
  y archivos (agrupamiento de funciones y datos).
• "Nivel conceptual", el cual representa grupo tanto
  de funciones y artefactos del nivel de código que son
  ensamblados dentro de subsistemas de componentes relacionados
  o conceptos.

El modelo completo no solo hace transformaciones en el
nivel de arquitectura, también lo hace en los niveles
subsidiarios. A continuación se proporcionan algunos
ejemplos simples de transformaciones en cada nivel.

Nivel de código.

En el nivel de código existen dos sub-niveles,
transformación textual (o basado en cadena) y
transformación basado en el árbol de sintaxis.
Mientras algunos métodos hacen distinciones entre
transformaciones "1A" textual (sintáctico) y "1B"
AST-based (semántico), el modelo herradura los considera a
ambos dentro del contexto de estructura de
código.

Transformación Textual:

En el nivel 1A, las transformaciones textuales son
realizadas a través de varias comparaciones de cadenas
simples y remplaza métodos. Por ejemplo, el mayor de los
esfuerzos de solución al "Year 2000" (Y2K) fueron
enfocadas en el código fuente, el cual representaba los
años como manipulaciones de dos dígitos (por
ejemplo: 99 para 1999), la solución entonces fue
remplazarlos con codigo que
manipulara cuatro dígitos. Otros ejemplos incluyen
transformaciones textuales de nombres o palabras claves cuando
portaban un sistema desde una plataforma o sistema operativo
a otro. Las transformaciones del nivel 1A son relativamente
simples, directas y relativamente baratas. Estas transformaciones
son elegidas por las organizaciones cuando el problema es
suficientemente simple o cuando se requiere un resultado
rápido y sucio (quick and dirty).

Transformación al árbol de
sintaxis:

En el nivel 1B, las transformaciones a la estructura de
código basada en árboles de sintaxis (ASTs)
soportan cambios que son inmunes a las variaciones superficiales
de sintaxis. Así, la representación del
código fuente es independiente de las expresiones o la
forma en que los lenguajes de programación representan números.
Transformaciones a la estructura de código basado en
árboles de sintaxis son normalmente usadas para
implementar nuevos lenguajes (por ejemplo de COBOL a C++) o
para hacer cambios al código automáticamente (por
ejemplo, métodos más sofisticados para el problema
Y2K).

Transformaciones a nivel funcional.

Transformaciones a nivel funcional (nivel "2") tiene que
ver con el re-empaquetado de funcionalidad (por ejemplo, migrar
desde un diseño funcional a un diseño orientado a
objeto o migrar desde un modelo de base de datos relacional a un
modelo orientado objeto). La encapsulación de un modulo de
funcionalidad por un diferente ambiente, es
un ejemplo de transformación a nivel funcional.
Transformaciones a nivel funcional va más allá de
simples transformaciones a la estructura del código, pero
no va más allá que una transformación de
arquitectura. Ellos son elegidos cuando grandes unidades de
funcionalidad pueden ser salvados poniéndolos dentro de un
nuevo contexto.

Transformaciones a nivel de
arquitectura.

Las transformaciones a nivel de arquitectura (nivel "3")
involucran cambios a los bloques básicos de la
arquitectura. Estos incluyen los modelos básicos de
interacción incluyendo los tipos de
componentes, los conectores usados, la asignación de
funcionalidad y el modelo en tiempo de ejecución de
control y datos. El nivel de arquitectura es el más
abstracto y lejos del alcance de las transformaciones. Las
transformaciones a nivel de arquitectura son hechas cuando es
necesario un cambio a la estructura principal debido a las
principales modificaciones o deficiencias en los sistemas de
información heredados. Las transformaciones generalmente
traen mayores compromisos de tiempo y recursos, pero
también trae consigo grandes beneficios.

Interacción entre niveles.

Las transformaciones a la estructura del código
se pueden dar sin hacer cambios de nivel funcional o cambios a la
arquitectura. Las transformaciones del nivel más bajo
soportan las transformaciones de niveles más altos. Con
esta vista multi-nivel de transformaciones, las transformaciones
a la arquitectura son normalmente el contexto en los cuales toman
parte niveles mas bajos. Sin embargo, las transformaciones de
nivel superior no soportan transformaciones de nivel bajos porque
esas transformaciones se pueden dar independientemente de las
transformaciones de niveles superiores. De echo, uno de los
principales propósitos del modelo herradura es elevar el
nivel de abstracción y brindar noticiones de la
arquitectura para las tareas de reingeniería.

3.3 EL MODELO CÍCLICO

Este modelo define [Pres 02] seis actividades las cuales
se muestran en la figura 3.3. En algunas ocasiones, estas
actividades se producen de forma secuencial y lineal, pero esto
no siempre es así. Por ejemplo, puede ser que la
ingeniería inversa (la comprensión del
funcionamiento interno de un programa) tenga que producirse antes
de que pueda comenzar la reestructuración de
documentos.

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

El paradigma de
la reingeniería mostrado en la figura es un modelo
cíclico. Esto significa que cada una de las actividades
presentadas como parte del paradigma pueden repetirse en otras
ocasiones. Para un ciclo en particular, el proceso puede terminar
después de cualquier de estas actividades.

3.3.1 Actividades Del Modelo
Cíclico.

En esta sección se dará una breve
explicación de las actividades que se definen en el modelo
cíclico: Análisis de inventario,
Reestructuración de documentos, Ingeniería inversa,
Reestructuración de código, Reestructuración
de datos e Ingeniería directa.

Análisis de inventario.

Todas las organizaciones de software deberán
disponer de un inventario de todas sus aplicaciones. El
inventario puede que no sea más que una hoja de calculo
con la información que proporciona una descripción
detallada (por ejemplo: tamaño, edad, importancia para el
negocio) de todas las aplicaciones activas.

Los candidatos a la reingeniería aparecen cuando
se ordena esta información en función de su
importancia para el negocio, longevidad, mantenibilidad actual y
otros criterios localmente importantes. Es entonces cuando es
posible asignar recursos a las aplicaciones candidatas para el
trabajo de reingeniería.

Es importante destacar que el inventario deberá
revisarse con regularidad. El estado de las aplicaciones (por
ejemplo, la importancia con respecto al negocio) puede cambiar en
función del tiempo y, como resultado, cambiarán
también las prioridades para la
reingeniería.

Reestructuración de documentos.

Una documentación escasa es la marca de muchos
sistemas de información heredados. ¿Qué se
puede hacer al respecto?

• Opción 1: La creación de
  documentación consume muchísimo tiempo. El
  sistema funciona, y ya nos ajustaremos con lo que se tiene.
  En algunos casos, éste es el enfoque correcto. No es
  posible volver a crear la documentación para cientos
  de programas de computadoras. Si un programa es relativamente
  estático está llegando al final de vida
  útil, y no es probable que experimente muchos cambios:
  ¡dejémoslo así!.
• Opción 2: Es preciso actualizar la
  documentación, pero se dispone de recursos limitados.
  Se utilizará un enfoque "del tipo documentar si se
  modifica". Quizá no es necesario volver a documentar
  por completo la aplicación. Más bien se
  documentarán por completo aquellas partes del sistema
  que estén experimentando cambios en ese momento. La
  colección de documentos útil y relevante
  irá evolucionando con el tiempo.
• Opción 3: El sistema es fundamental para el
  negocio, y es preciso volver a documentarlo por completo. En
  este caso, un enfoque inteligente consiste en reducir la
  documentación al mínimo necesario.

Todas y cada una de estas opciones son viables. Las
organizaciones del software deberán seleccionar aquella
que resulte más adecuada para cada caso.

Ingeniería inversa.

El término "ingeniería inversa" tiene sus
orígines en el mundo del hardware. Una cierta
compañía desensambla un producto de hardware
competitivo en un esfuerzo por comprender los "secretos" del
diseño y fabricación de su competidor. Estos
secretos se podrán comprender más fácilmente
si se obtuvieran las especificaciones de diseño y
fabricación del mismo. Pero estos documentos son privados,
y no están disponibles para la compañía que
efectúa la ingeniería inversa. En esencia, una
ingeniería inversa con éxito
precede de una o más especificaciones de diseño y
fabricación para el producto, mediante el examen de
ejemplos reales de ese producto.

La ingeniería inversa del software es algo
bastante similar. Sin embargo, en la mayoría de los casos,
el programa del cual hay que hacer una ingeniería inversa
no es el de un rival, sino, más bien, el propio trabajo de
la compañía (con frecuencia efectuado hace muchos
años). Los "secretos" que hay que comprender resultan
incomprensibles porque nunca se llegó a desarrollar una
especificación. Consiguientemente, la ingeniería
inversa del software es el proceso de análisis de un
programa con el fin de crear una representación de
programa con un nivel de abstracción más elevado
que el código fuente. La ingeniería inversa se
extraerá del programa existente información del
diseño arquitectónico y de proceso, e
información de los datos.

Reestructuración del
código.

El tipo más común de reingeniería
es la reestructuración del código. Algunos sistemas
heredados tienen una arquitectura de programa relativamente
sólida, pero los módulos individuales han sido
codificados de una forma que hace difícil comprenderlos,
comprobarlos y mantenerlos. En estos casos, se puede
reestructurar el código ubicado dentro de los
módulos sospechosos.

Para llevar a cabo esta actividad, se analiza el
código fuente mediante una herramienta de
reestructuración, se indican las violaciones de las
estructuras de programación estructurada, y entonces se
reestructura el código (esto se puede hacer
automáticamente). El código reestructurado
resultante se revisa y se comprueba para asegurar que no se hayan
introducido anomalías. Se actualiza la
documentación interna del código.

Reestructuración de datos.

Un programa que posea una estructura de
datos débil será difícil de adaptar y de
mejorar. De hecho, para muchas aplicaciones, la arquitectura de
datos tiene más que ver con la viabilidad a largo plazo
del programa que el propio código fuente.

A diferencia de la reestructuración de
código, que se produce en un nivel relativamente bajo de
abstracción, la estructuración de datos es una
actividad de reingeniería a gran escala. En la
mayoria de los casos, la reestructuración de datos
comienza por una actividad de ingeniería inversa. La
arquitectura de datos actual se analiza minuciosamente y se
definen los modelos de datos necesarios. Se identifican los
objetos de datos y atributos y, a continuación, se revisan
las estructuras de datos a efectos de calidad.

Cuando la estructura de datos es débil (por
ejemplo, actualmente se implementan archivos planos, cuando un
enfoque relacional simplificaría muchísimo el
procesamiento), se aplica una reingeniería a los
datos.

Dado que la arquitectura de datos tiene una gran
influencia sobre la arquitectura del programa, y también
sobre los algoritmos que
los pueblan, los cambios en datos darán lugar
invariablemente a cambios o bien de arquitectura o bien de
código.

Ingeniería directa (foward
engineering).

En un mundo ideal, las aplicaciones se reconstruyen
utilizando un "motor de
reingeniería" automatizado. En el motor se
insertaría el programa viejo, que lo analizaría,
reestructuraría y después regeneraría la
forma de exhibir los mejores aspectos de la calidad del software.
Después de un espacio de tiempo corto, es probable que
llegue a aparecer este "motor", pero los fabricantes de CASE han
presentado herramientas
que proporcionan un subconjunto limitado de estas capacidades y
que se enfrentan con dominios de aplicaciones específicos
(por ejemplo, aplicaciones que han sido implementadas empleando
un sistema de bases de datos específico). Lo que es
más importante, estas herramientas de reingeniería
cada vez son más sofisticadas.

La ingeniería directa, que se denomina
también renovación o reclamación [Chi 90],
no solamente recupera la información de diseño de
un software ya existente, sino que, además, utiliza esta
información en un esfuerzo por mejorar su calidad global.
En la mayoría de los casos, el software procedente de una
reingeniería vuelve a implementar la funcionalidad del
sistema existente, y añade además nuevas funciones
y/o mejora el rendimiento global.

CAPÍTULO 4

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.

4.1 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.

4.2 RECOMENDACIONES Y FASES PARA LA
RECONSTRUCCIÓN DE LA ARQUITECTURA

4.2.1 Recomendaciones Para La Reconstrucción
De Arquitectura

Los siguientes, según Kazman [Kazm 97] son
recomendaciones generales para el proyecto de
reconstrucción de la arquitectura:

• Tener una meta y un conjunto de objetivos o
  preguntas en mente antes de emprender un proyecto de
  reconstrucción de datos. Por ejemplo, re-usar partes
  del sistema en una nueva aplicación puede ser una
  meta. Sin estas metas u objetivos, gran parte del esfuerzo
  puede ser gastado en la extracción de la
  información y generar vistas arquitectónicas
  que pueden no ser útiles.
• Obtener una visión de alto nivel de la
  arquitectura del sistema antes de comenzar el detallado
  proceso de reconstrucción. Esta visión
  guía la:
• • Procesos de extracción para ayudar a
    identificar la información que se necesita ser
    extraída del sistema.
  • Procesos de reconstrucción para ayudar a
    determinar que se ve en la arquitectura y que vistas se
    generarán.
• Usar la documentación existente para generar
  solo vistas de alto nivel de los sistemas. En muchos casos,
  la documentación existente para un sistema puede no
  reflejar exactamente el sistema como esta implementado, pero
  este puede dar una indicación de conceptos de alto
  nivel.
• Involucrar a la gente que esta familiarizado con el
  sistema en el proyecto para obtener un mejor entendimiento
  del sistema que será reconstruido. Herramientas pueden
  ayudar al esfuerzo y acorta los procesos de
  reconstrucción, pero ellos no pueden ejecutar una
  reconstrucción completa automáticamente. La
  reconstrucción de arquitectura requiere que se
  involucre la gente (arquitectos, desarrolladores y gente de
  mantenimiento del software) quienes están
  familiarizados con el sistema.
• Asignar a alguien de tiempo completo para trabajar
  sobre el proyecto de reconstrucción de arquitectura.
  La reconstrucción de arquitectura involucra un extenso
  y detallada análisis de un sistema y requiere un
  significante esfuerzo.

4.2.2 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.

4.2.2.1 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.

4.2.2.2 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 

4.2.2.3 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.

4.2.2.4 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.

CONCLUSIONES

El software siempre ha sido y será lo que le
puede dar vida y plusvalía a la computación; sin el software, las
computadoras serían inservibles y no podrían ser
utilizadas para ningún beneficio. Es el software el que
realiza los procesos necesarios a los datos introducidos para
así obtener nuevos datos con los que se pueden tomar
decisiones, en muchos de los casos, decisiones críticas.
Conforme pasa el tiempo, hemos visto que las computadoras son
utilizadas en casi todos los aspectos de la vida del ser humano,
hoy en día se ven computadoras en los bancos, tiendas,
automóviles, oficinas gubernamentales, empresas privadas,
el hogar y en un futuro cercano hasta en el propio cuerpo humano.
Esta simbiosis que el ser humano ha realizado con la computadora
es debida en gran parte a que el software, aprovechando la
velocidad con
que las computadoras pueden procesar datos y arrojar resultados,
facilita y agiliza las tareas del hombre.

En la actualidad se puede observar que una falla en el
software, en el mejor de los casos puede dar como resultados la
pérdida de tiempo pero en algunos otros casos
también puede resultar en perdidas de vidas humanas.
Conforme pase el tiempo, el hombre es
más y más dependiente de las computadoras y sus
beneficios, pero siempre existirá la incertidumbre y la
intranquilidad de que el software puede fallar y causar serios
problemas ya que el software es desarrollado por seres humanos
que por naturaleza
cometen errores.

El desarrollo de software siempre ha estado en un
proceso continuo de evolución, y como en cualquier
actividad evolutiva, los primeros años siempre van
acompañados de grandes dificultades debidas en gran parte
a que no se cuenta con las herramientas ni los conocimientos para
realizar bien las tareas que involucra esta actividad. Esto es
muy palpable en el ser humano, nadie va a llegar a este mundo
sabiendo caminar, este es un proceso en el que se tienen que
sufrir tropiezos y caídas, pero que al paso de los
años se logra dominar. En los primeros años del
desarrollo del software, este fue hecho sin tener absolutamente
ningún tipo de conocimiento ni estrategia que permitiera
el buen desarrollo, estos años son conocidos como la
"crisis de software". Los sistemas que fueron desarrollados en
estos años se fueron convirtiendo en parte vital de muchas
organizaciones, por lo que se veía la constante necesidad
de corregirlos, estas correcciones seguían
ejecutándose de una manera no muy convenientes, generando
así nuevos errores o poco a poco haciendo imposible la
corrección de los sistemas; estos sistemas han recibido el
nombre de "sistemas de información heredados".

Al hablar de sistemas de información heredados
puede hacerse una analogía con la obra de uno de los
más grandes autores de la literatura
latinoamericana, Gabriel García
Márquez y su obra "Cien años
de soledad". El relato adopta una apariencia virtualmente
lineal pero en realidad el tiempo de la novela no es
sucesivo o cronológico, sino cerrado. El presente, el
pasado y el futuro pueden ser narrados en un tiempo a cualquier
tiempo por el narrador. Por eso, el tiempo en Cien años de
soledad es circular. La novela tiene una
declaración que se desarrolla y explica de una manera
lógica, que ninguna otra explicación puede ser
posible.

El pasado se repite en el presente y el futuro es
previsible porque, de alguna manera, ya ocurrió. El tiempo
no existe en Macondo (lugar donde se desarrolla la mayor parte de
la obra), está congelado. Ursula (uno de los personajes
principales) es el que tiene la mas clara conciencia de
vivir en una dimensión intemporal, propia de los
sueños: cuando José Arcadio Segundo concibe el loco
proyecto de establecer un sistema de navegación, el
comentario de Ursula es " ya esto me lo se de memoria". Es como
si el tiempo diera vueltas en redondo y hubiéramos vuelto
al principio (como la historia de la humanidad,
quien comete los mismos errores una y otra vez). La
acción
concentra la espesa historia de Macondo en un tiempo
inmóvil, donde mil cosas pasan y mil cosas vuelven, y
sostiene la presencia de varios protagonistas, que se alternan en
el primer plano y el trasfondo temporal, sin perder en
ningún momento la tensión narrativa.

Así como en Cien años de Soledad, el
mantenimiento de algunos sistemas ha seguido una línea en
el tiempo circular, en la cual se siguen cometiendo los mismos
errores que se cometieron al crear el sistema, heredando
así año con años los errores cometidos. Es
en este momento, en el cual el mantenimiento de un sistema se
hace imposible donde la "Reingeniería de software" se
vislumbra como única solución a los sistemas de
información heredados. La reingeniería de software
pretende terminar de una vez por todas con la vida útil
del sistema, no sin antes extraer de el la mayor parte del
conocimiento que pueda brindar, conocimientos que serán
utilizados para crear un nuevo sistema aplicando las buenas
practicas que nos brinda la ingeniería de
software.

La reingeniería no es una actividad que se lleva
a cabo de la noche a la mañana, además implica una
gran inversión de esfuerzo, tiempo y recursos.
Es por ello que es necesario planear de una manera muy cuidadosa
todo el proceso. Este proceso se inicia con la
justificación del proyecto de reingeniería, en el
cual se tiene que analizar cada sistema candidato para así
obtener una lista de aplicaciones ordenada según sus
prioridades. Una vez obtenida la lista, se hace la
estimación de costes que serán necesarios para
modificar todos los componentes. Por último se comparan
los costes con los beneficios esperados.

En la reingeniería de software existen
métodos y modelos que permiten que esta actividad se pueda
desarrollar de una manera bien direccionada para poder crear una
nueva aplicación con un alto nivel de calidad, fiabilidad
y plusvalía. En estos métodos y modelos se puede
observar varios puntos en común siendo uno de los
más importantes la "reconstrucción de la
arquitectura", ya que esta es la que nos va a brindar la
compresión del sistema al que se le va aplicar
reingeniería para poder crear una clara imagen de lo que
se va a rediseñar y así poder planificar las
actividades que se llevaran a cabo durante toda la actividad de
reingeniería.

Ninguna de las actividades llevadas a cabo durante la
reingeniería de un sistema es fácil, es por ellos
que cada una debe de estar muy bien planeadas antes de
emprenderse y la reconstrucción de la arquitectura no es
la excepción. Es por ello que para realizar la
reconstrucción de la arquitectura de un sistema de
información heredado se recomienda tener bien definidas
las metas y objetivos, obtener una visión general de la
arquitectura, identificar y usar la documentación
existente, e involucrar a personas familiarizadas con el
sistema.

La reconstrucción de la arquitectura genera una
representación de la arquitectura del sistema que puede
ser usado de diversas formas. El principal uso de esta
representación es para documentar la arquitectura de un
sistema. Si la documentación existente o disponible es
obsoleta, la recuperación de la arquitectura puede ser
utilizada como base para la redocumentación de la
arquitectura. La representación de la arquitectura
también puede ser usada como punto de partida para la
reingeniería del sistema. Por último, esta
representación puede ser útil para identificar la
funcionalidad de los componentes para reutilizarlos o
establecerlos como la arquitectura base.

GLOSARIO

Abstract Syntax Tree (AST): Vea "Árbol
de Sintaxis Abstracto".

Análisis de Opciones para
Reingeniería: Método sistemático, de
arquitectura central y de toma de decisiones para la
identificación y extracción de componentes dentro
de grandes y complejos sistemas de software.

Árbol de Sintaxis Abstracto: es una
estructura de datos que representa algo que se ha analizado,
utilizado a menudo como un recopilador o representación
interna de interpretes de un programa de computadora mientras
que se está optimizando y qué realiza
generación del código.

CASE: Ingeniería de software asistida
por computadora. CASE proporciona al ingeniero la posibilidad
de automatizar actividades manuales y de
mejorar su visión general de la
ingeniería.

Formato Estándar Rigi: Es el formato
usado por la herramienta Rigi.

Graph eXchange Language (GXL): Vease "Lenguaje de
Intercambio Gráfico".

KLDC: Miles de líneas de código,
KiloLDC.

LDC: Líneas de código.

Legacy Information System (LIS): Vea "Sistema
de Información Heredado".

Lenguaje de Intercambio Gráfico: es un
formato de intercambio estándar basado en XML para
compartir datos entre herramientas. Este lenguaje representa
los gráficos escritos, atribuidos, dirigidos
y ordenados los cuales se extienden para representar
hipergrafos y gráficos jerárquicos. Para mayor
información puede visitar la página http://www.gupro.de/GXL/

Rigi: Es una herramienta interactiva y visual
diseñada para ayudar a entender y re-documentar
software. Para mayor información puede visitar la
página http://www.rigi.csc.uvic.ca/

Rigi Standard Format (RSF): Vea "Formato
Estándar Rigi".

Sistema de Información Heredado:
Cualquier sistema de información que significativamente
se resiste a la modificación y
evolución.

Options Analysis for Reingeneering (OAR): Vea
"Análisis de Opciones para
Reingeniería".

BIBLIOGRAFÍA

Para ver el texto
seleccione la opción "Descargar" del menú
superior 

FLORES CARMONA NICOLÁS JOHNATAN

PARA OBTENER EL TITULO DE

INGENIERIO EN SISTEMAS COMPUTACIONALES

Con la asesoría de:

M.C.C. MARTHA ALICIA ROCHA
SÁNCHEZ

Instituto Tecnológico de León

León, Guanajuato Septiembre del 2004