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

Enviado por Nicolás Johnatan Flores Carmona

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:

Identificar características de los componentes necesarios:

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

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.

Compara las necesidades de componentes:

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

Inventario de componentes candidatos:

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

Produce tópicos de extracción

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

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:

Selección de componentes deseables.

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

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

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

Identifica componentes de caja blanca.

Determina aquellos componentes que necesitarán ser modificados.

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.

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

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

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:

Selecciona componentes favorables:

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

Ejecución de intercambio de componentes:

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

Forma opciones de componentes:

Desarrolla criterios para agregar componentes.

Determina costos comparativos y esfuerzos:

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

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.

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:

Elegir la mejor opción:

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

Verificación de opción:

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

Identifica componentes necesarios satisfechos.

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

Presentación de descubrimientos.

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

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:

Revisión de metas y objetivos:

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

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

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

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.

Revisión de sistemas heredados y documentación:

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

Determinar controladores de extracción:

Identificar controladores programáticos y técnicos.

Validar metas y objetivos:

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

Identificar componentes candidatos:

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

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.

Evaluar el estado de preparación:

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

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