Sistemas heredados (legados)

Transcripción

1 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. Algunas preguntas al respecto? Figura 1: Análisis del sistema heredado 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?

2 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? Abandonar el sistema heredado Análisis de las alternativas 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. Mantenimiento Se consideran cuatro tipos de mantenimiento: Figura 2: Abandonar el sistema heredado 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.

3 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. Aspectos de reingeniería Figura 4: Proceso de reingeniería propuesto por Sommerville. Problema delimitado cambio de estado del sistema actual a un sistema deseado Sistema un modelo guía del proceso actividades

4 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.)

5 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)

6 Figura 8: Identificación de rasgos (features). Figura 9: Framework de generación de wrappers en ambientes distribuidos.

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

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

9 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