Sistemas heredados (legados)

Las compañías gastan mucho dinero en sistemas informáticos y, para obtener un beneficio de
esa inversión, el software o el hardware debe utilizarse varios años. El tiempo de vida de los
sistemas informáticos es muy variable, pero muchos sistemas grandes se pueden llegar a
utilizar hasta más de 20 años. Muchos de estos sistemas antiguos aún son importantes para sus
respectivos negocios, es decir, las empresas cuentan con los servicios suministrados por estos
sistemas y cualquier fallo en estos servicios tendría un efecto serio en el funcionamiento de la
organización. Estos sistemas antiguos reciben el nombre de sistemas heredados o legados
(legacy system).

Lo habitual es que los sistemas heredados, los que ya suponen un problema para una empresa
u organización por la dificultad para sustituirlos, no sean los mismos sistemas que
originalmente se empezaron a utilizar en la empresa. Muchos factores externos e internos,
como el estado de las economías nacional e internacional, los mercados cambiantes, los
cambios en las leyes, los cambios de administración o la reorganización estructural, conducen
a que los negocios experimenten cambios continuos. Estos cambios generan o modifican los
requerimientos del sistema de información, por lo que éste va sufriendo cambios conforme
cambian los negocios. Por esta razón, los sistemas heredados incorporan un gran número de
actualizaciones hechas a lo largo de su vida útil. Muchas personas diferentes pueden haber
estado involucradas en la realización de estas modificaciones a lo largo del tiempo, y es
inusual para cualquier usuario o administrador del sistema tener un conocimiento completo
del mismo, sobre todo cuando éste tiene una cierta envergadura.

Figura 1: Análisis del sistema heredado

Algunas preguntas al respecto?

1. El hardware sobre el que funciona está vigente?

2. Es acorde con las políticas institucionales de tecnologías de información?
3. El lenguaje de desarrollo ofrece posibilidades de actualización a entornos dinámicos y
distribuidos?
4. El software de apoyo como sistemas operativos, librerías o herramientas tiene soporte
del fabricante?
5. La funcionalidad que ofrece el sistema es acorde con los procesos de negocio que
maneja la organización?
 6. Los datos que maneja el sistema de software son consistentes, poseen niveles de
redundancia aceptados y tiene características de formato compatibles?
7. Las reglas de negocio que implementa el software se ajustan a la realidad?
8. En qué proporción están documentados el código, el diseño y los requerimientos?

Análisis de las alternativas

Abandonar el sistema heredado

• Perdida de la contribución a los procesos de negocio.

• Costo de hacer reingeniería resulta muy alto.
• Más razonable invertir en nuevas tecnologías de hardware o software.
• Un riesgo importante es el consumo de más recursos que muchas veces exige
mantener los dos sistemas en operación durante un largo periodo de tiempo.
• Un aspecto esencial de esta perspectiva es plañera la migración del sistema heredado a
un nuevo sistema.

Figura 2: Abandonar el sistema heredado

Mantenimiento

Se consideran cuatro tipos de mantenimiento:

Correctivo: localizar y eliminar defectos.

Adaptativo: cambios en hardware o en entorno de ejecución.
Perfectivo: actividades para mejorar y adicionar funcionalidades.
Preventivo: mejorar calidad y mantenibilidad.
 Figura 3: Proceso de mantenimiento del software.

• Enfoque más amplio y drástico para evolucionar un sistema.

o Mejoramiento de la eficiencia en el uso de recursos disponibles (hardware y
software)
o Reestructuración amplia
o Nuevas funcionalidades
o Reducción drástica de los costos de mantenimiento
o Mayor compresibilidad (comunicación)

• Se debe tener en cuenta el aporte al valor del negocio.

o Es una forma de reutilizar código.

Figura 4: Proceso de reingeniería propuesto por Sommerville.

Aspectos de reingeniería

Problema delimitado
• cambio de estado del sistema actual a un sistema deseado

Sistema
• un modelo guía del proceso
• actividades
Administrativo
• objetivos
• activos del sistema heredado
• plan para recuperar archivos y cumplir objetivos

Software
• reutilización
• mantenibilidad

Reingeniería del software

Modernización de caja blanca
• reconocer componentes más importantes
• abstracción al más alto nivel
• ingeniería inversa
Modernización de caja negra o wrapping
• capa envolvente que aísla
• encapsulamiento
• interfaces bien definidas
• se modifica el acceso externo al software

Figura 5: Wrapper.

Técnicas de Wrapping
Capas
• mapeo del formulario de una interfaz a otra
• screen scaping (es el nombre en inglés de una técnica de programación que consiste en
tomar una presentación de una información (normalmente texto, aunque puede incluir
información gráfica) para, mediante ingeniería inversa, extraer los datos que dieron
lugar a esa presentación.)
Migración de datos
• mover datos a otro modelo
• acceso uniforme tanto sintáctico como semántico

Middleware
• procesamiento distribuido
• mediador

Encapsulamiento
• particionar y modularizar
• componentes reutilizables

Figura 6: Desarrollo de wrappers.

Experiencias en integración y evolución de sistemas legados

Las siguientes imágenes ilustran algunas experiencias realizadas por investigadores y

empresas alrededor del mundo entorno a este concepto.

Figura 7: Programación dinámica orientada a objetos (OO)

 Figura 8: Identificación de rasgos (features).

Figura 9: Framework de generación de wrappers en ambientes distribuidos.

 Figura 10: Wrapper para captura de E/S.

Figura 11: Integración de sistemas orientados a servicios.

Figura 12: Aplicación de patrones de diseño.

 Programación orientada a aspectos (POA)

• Los sistemas legados fueron analizados y diseñados en una sola dimensión

(funcional).
• No se consideraron las dimensiones no funcionales de los requerimientos.
• El resultado de este proceso es la contaminación del código mezclando elementos
funcionales y no funcionales.
• Separación de preocupaciones (concerns) mejora las tareas de desarrollo y
mantenimiento de software.
• Buscar aislar aquellas preocupaciones transversales (cross cutting concerns).
• Los concerns se implementan en unidades separadas
• Preocupaciones (concerns):
o son propiedades o áreas de interés
o requerimientos no funcionales
o requerimientos funcionales

Figura 13: Relación de la POA vs, POO.

• Modularizar el software del sistema legado separando los elementos funcionales de

aquellos que representan los requerimientos no funcionales (RNF).
• Los RNF son transversales al código y se repiten en diferentes lugares.
• Los requerimientos no funcionales se representan como preocupaciones o “concerns”.

Figura 14: Aplicación de técnicas basadas en POA.

• Un aspecto es una unidad funcional que permite expresar una estructura de código en
diferentes partes de un programa (cross-cutting).
• Un aspecto está formado por dos elementos:
• un punto de corte (pointcut) que indica las partes del código en que se va a introducir
un código definido.
• al código del aspecto típicamente se le llama un advice.

Conclusiones

• Incrementar el número de sistemas legados

* permanente evolución tecnológica

• Oportunidad para reutilizar y mantener estos sistemas

* integrabilidad
* interoperabilidad
* distribución

• No son viables las soluciones extremas

• Tendencia hacia la reingeniería

* extensión del ciclo de vida
* no hay un modelo único
* el uso de la técnica depende del dominio de aplicación

• Los modelos basados en componentes son una buena alternativa para evolucionar.

• En ambientes de integración de datos y acelerados cambios tecnológicos.

* programación dinámica con técnicas de reflexión (reflect)

• Niveles de documentación pobre y con funcionalidad de negocio aceptable.

* técnicas basadas en wrapping de encapsulamiento

• Integración empresarial
* técnicas basadas en SOA

• Extender funcionalidad de granularidad variada mediante composición.

* modelos basados en rasgos “features”

• Actualización y redefinición de requerimientos no funcionales

* programación orientada a aspectos