El documento discute las alternativas para evolucionar sistemas legados, incluyendo abandonarlos, mantenerlos o realizar reingeniería. Explica que la Programación Orientada a Aspectos es una opción para separar los requerimientos funcionales de los no funcionales en sistemas legados. Finalmente, concluye que no existe una solución única y que el enfoque depende del dominio, sugiriendo técnicas como wrapping, SOA y POA según cada caso.

1. Evolución e integración de aplicaciones legadas: comenzar de nuevo o actualizar? Gilberto Pedraza García [email_address] Universidad Piloto de Colombia Medellín, Abril 24 de 2008

2. Objetivos Poner en contexto la importancia de los sistemas legados en los procesos actuales de integración de aplicaciones y datos Presentar las alternativas para decidir qué hacer con un sistema legado Destacar la Programación Orientada a Aspectos como alternativa natural para su actualización

3. Agenda Motivación Concepto de sistema legado Qué hacer con un sistema legado? Experiencias en integración y evolución de sistemas legados Conclusiones

4. Motivación Evolución de tecnologías de información Complejidad en requerimientos de negocio Internet y nuevas formas de interacción social Visión unificada de procesos de negocio (Inteligencia de negocios)

5. Qué es un sistema legado? Una aplicación de software que posee un importante valor de negocio Debilitada por el constante cambio tecnológico Pobre soporte arquitectónico Alto costo de mantenimiento Documentación inexistente Se mantiene en producción

6. Características No necesariamente un sistema viejo es un sistema legado. Fue desarrollado con los principios de ingeniería de la época. Arquitectura poco flexible para absorber los cambios provocados por nuevos requerimientos

7. Qué hacer con un sistema legado?

8. Qué hacer con el sistema legado? Abandonarlo para dar paso a uno nuevo. Garantizar su mantenimiento. Reingeniería del sistema actual. Reorientar y reevaluar apoyo a procesos organizacionales

9. Para tener en cuenta … El 23% de los proyectos son cancelados antes de su finalización. Únicamente el 28% finaliza a tiempo, con el presupuesto asignado y con la funcionalidad esperada [ Standish ]

10. Análisis del sistema legado Modernizar Reevaluar Reorientar Retirar y reemplazar Mantener Valor de negocio Valor Técnico Alto Alto Bajo Bajo

11. Preguntas (1) ¿El hardware sobre el que funciona esta vigente? ¿Es acorde con las políticas institucionales de tecnologías de información? ¿El lenguaje de desarrollo ofrece posibilidades de actualización a entornos dinámicos y distribuidos? ¿El software de apoyo como sistemas operativos, librerías o herramientas tiene soporte del fabricante?

12. Preguntas (2) ¿La funcionalidad que ofrece el sistema es acorde con los procesos de negocio que maneja la organización? ¿Los datos que maneja el sistema de software son consistentes, poseen niveles de redundancia aceptados y tienen características de formato compatibles? ¿Las reglas de negocio que implementa el software se ajustan a la realidad? ¿En que proporción están documentados el código, el diseño y los requerimientos?

13. Análisis de las alternativas

14. Abandonar el sistema legado 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 planear la migración del sistema legado a un nuevo sistema.

15. Abandonar el sistema legado Proceso de simulación propuesto por Pinheiro [8]

16. Mantenimiento (1) 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

17. Mantenimiento (2) Proceso de mantenimiento de software [12].

18. Reingeniería del software (1) Enfoque más amplio y drástico para evolucionar un sistema. Mejoramiento de la eficiencia en el uso de recursos disponibles (hardware y software). Reestructuración amplia Nuevas funcionalidades Reducción drástica de los costos de mantenimiento. Mayor comprensibidad (comunicación) Se debe tener en cuenta el aporte al valor del negocio Es una forma de reutilizar código

19. Reingeniería del software Mejora de la Estructura del programa Programa original Documentación Del programa Programa Modularizado Datos originales Modularización Del programa Programa Estructurado Datos con reingeniería Proceso de reingeniería propuesto por Sommerville [12] Traducción del Código fuente Ingeniería inversa Reingeniería De datos

20. Aspectos de reingeniería Problema delimitado Cambio de estado del sistema actual a un sistema deseado Sistema Un modelo guía el proceso. Actividades. Administrativo Objetivos Activos del sistema legado Plan para recuperar activos y cumplir objetivos Software Reutilización Mantenibilidad

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

22. Wrapper API Sistemas legados S 1 S 5 S 4 S 3 S 2 Software sistema legado Componente de negocio Componente de negocio Componente de negocio Wrapper

23. Desarrollo de wrappers Fase 2: Extractar componentes Fase 3: Diseño y desarrollo del wrapper Opción 1 Wrapper delgado Opción 2 Wrapper grueso Fase 1: Identificación del componente

24. Técnicas de Wrapping Capas Mapeo del formulario de una interfaz a otra Screen Scaping 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

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

26. Programación dinámica OO A B Aplicaciones legadas y bases de datos Nuevas aplicaciones y repositorio de datos de soporte C Bomba de datos convertidor de datos Mapeo de datos Browser Catalogo Arquitectura de la solución propuesta por Robertson [9]

27. Identificación de rasgos “features” Metodología propuesta por Mehta

28. Framework de generación de wrappers Framework de generación de wrappers en ambientes distribuidos [4]

29. Wrapper para captura I/O Arquitectura de wrappers propuesta por Wohlstadter, Jackson y Devanbu [13]

30. Integración de sistemas orientados a servicios Wrapping de tres niveles propuesto por Zemlicka y Kral [14]

31. Aplicación de patrones de diseño Interfaz de usuario (FrontEnd) Cliente Nueva GUI y portales Cliente Interface capa interface Sistema legado Servidor Base de datos Adaptador legado Nueva GUI y portales Servidor: capa negocio Adaptador middleware Interface lógica negocio Servidor de aplicaciones Remote Communication protocol Local Communication protocol Comunicación cliente - sistema legado Patrón estructural Dublo [16].

32. Programación Orientada a Aspectos (1) 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.

33. Programación Orientada a Aspectos (2) Separación de preocupaciones ( concerns ) mejora las tareas de desarrollo y mantenimiento de software Busca aislar aquellas preocupaciones transversales ( cross cutting concerns ) Los concerns se implementan en unidades separadas Preocupaciones (Concerns): Son propiedades o áreas de interés Requerimientos no funcionales Requerimientos funcionales back

34. Relación POA vs POO POO: conceptos comunes POA: conceptos entrecruzados Clase A Clase A1 Attb1 Attb2 Método 1 Clase A2 Attb 3 Método 1 Método 2

35. Programación Orientada a Aspectos (3) Modularizar el software del sistema legado separarando 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”

36. Aplicación de técnicas basadas en POA

37. Programación Orientada a Aspectos (4) 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. El código del aspecto típicamente se le llama un advice

38. Conclusiones (1) Incremento del número de sistemas legados. Permanente evolución tecnológica Oportunidad para reutilizar y mantener estos sistemas Integrabilidad Interoperabilidad Distribución No son viables 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 Modelos basados en componentes son una buena alternativa para evolucionar.

39. Conclusiones (2) En ambientes de Integración de datos, acelerados cambios tecnológicos Programación dinámica con técnicas de reflexión (reflect) Niveles de documentación pobres 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

40. Trabajo futuro Aplicar POA al modelamiento y simulación de nuevos sistemas basados la evaluación de carga sintética del sistema legado. Mediante aspectos hacer monitoreo del uso de recursos en las aplicaciones Gestión de memoria Clases y métodos Filtros a datos no deseados Registro de duración, timestamp Trafico de red Entrada salida

41. Bibliografía (1) [1] J. C. Álvarez, M. Mateos, M. N. Moreno. Metodología de reingeniería del software para la remodelación de aplicaciones científicas heredadas . Informe técnico DPTOIA-IT-2004-003. Universidad de Salamanca. Salamanca .2004. [2] A. D. Lloyd, R. Dewar, R. Pooley. “Legacy information systems and business process change: a patterns perspective,” in Communications of the association for information systems Volume 2, Article 24 December 1999 [3] J. Greenfield, K. Short et al. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools . Indianapolis: Wiley, 2004, ch 1. [4] M. Juric, I. Rozman, M. Hericko, T. Domajnko. “Integrating legacy systems in distributed object architecture,” in ACM SIGSOFT Software Engineering Notes. Vol. 25, Issue 2. ACM Press, New York (2000) 35 - 39

42. Bibliografía (2) [5] G. Kaiser, P. Gross, G. Kc, J. Parekh, G. Valetto. An Approach to Autonomizing Legacy Systems. Columbia University, New York. Available: http://www.psl.cs.columbia.edu/ftp/psl/CUCS-020-02.pdf [6] A. Mehta, G. Heineman. “Evolving legacy systems features using regression test cases and components,” in Proceedings of the 4th International Workshop on Principles of Software Evolution. ACM Press, New York, 2001, p.p. 190 - 193 [7] A. O’Callaghan. “Focus issue on legacy information systems and business process change: migrating large scale legacy systems to component- based and object technology: The Evolution of a Pattern Language,” in Communications of the association for information systems Volume 2, Article 3 July 1999

43. Bibliografía (3) [8] P. Pinheiro, A. Laender, P. Golgher. A Simulation Model for the Performance Evaluation for Migrating a Legacy System. Availa ble: http://www.ksl.stanford.edu/people/pp/papers/PinheirodaSilva_CSMR_2001.pdf [9] P. Robertson. “Integrating Legacy Systems with Modern Corporate Applications,” in Communications of the ACM Volume 40, Number 5 May 1997 [10] A. Rodriguez,, A. Márquez, M. Toro. Gestión de la evolución del software. El eterno problema de los legacy systems. [11] Software En gineering Institute: Perspectives on Legacy System Reengineering. Reengineering Center, Carnegie Mellon University. Pittsburgh (1995). Available: http://www.sei.cmu.edu/reengineering/lsysree.pdf

44. Bibliografía (4) [12] I. Sommerville. Ingeniería de software. Addison Wesley. Sexta edición. 2002 [13] E. Wohlstadter, S. Jackson, P. Devanbu. “Generating wrappers for command line programs: the Cal-Aggie Wrap-O-Matic project,” in Proceedings of the 23rd International Conference on Software Engineering. IEEE Computer Society, Washington, 2001, p.p. 243 - 252 [14] M. Zemlicka, J. Kral,. Legacy systems and web services. Praga. [15] F. Asteasuain, B. Contreras, E. Estévez, P. R. Fillottrani . Programación Orientada a Aspectos: Metodología y Evaluación”, publicado en Proceedings IX CACIC 2003 del Congreso Argentino de Ciencias de la Computación . La Plata, 2003. pp 1160-1171

45. Bibliografía (5) [16] W. Hasselbring, R. Reussner. The Dublo Architecture Pattern for Smooth Migration of Business Information Systems: An Experience Report. En IEEE Proceedings of the 26th International Conference on Software Engineering (ICSE’04). 2004 [17]H. Soo Kim, J. M. Bieman. Migrating legacy systems to CORBA based distributed environments through an automatic wrapper generation technique. Computer. Colorado State University, Colorado.

46. Muchas Gracias [email_address]