• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Evolución e integración de aplicaciones legadas: comenzar de nuevo o actualizar?
 

Evolución e integración de aplicaciones legadas: comenzar de nuevo o actualizar?

on

  • 5,796 views

Ponencia presentada en el 3er Congreso Colombiano de la Computación. Medellín, Abril 24 de 2008

Ponencia presentada en el 3er Congreso Colombiano de la Computación. Medellín, Abril 24 de 2008

Statistics

Views

Total Views
5,796
Views on SlideShare
5,772
Embed Views
24

Actions

Likes
2
Downloads
0
Comments
0

3 Embeds 24

http://www.slideshare.net 21
http://www.epnvirtual.net 2
http://cetys.blackboard.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Evolución e integración de aplicaciones legadas: comenzar de nuevo o actualizar? Evolución e integración de aplicaciones legadas: comenzar de nuevo o actualizar? Presentation Transcript

  • 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
  • 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
  • Agenda
    • Motivación
    • Concepto de sistema legado
    • Qué hacer con un sistema legado?
    • Experiencias en integración y evolución de sistemas legados
    • Conclusiones
  • 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)
  • 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
  • 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
  • Qué hacer con un sistema legado?
  • 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
  • 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 ]
  • Análisis del sistema legado Modernizar Reevaluar Reorientar Retirar y reemplazar Mantener Valor de negocio Valor Técnico Alto Alto Bajo Bajo
  • 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?
  • 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?
  • Análisis de las alternativas
  • 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.
  • Abandonar el sistema legado Proceso de simulación propuesto por Pinheiro [8]
  • 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
  • Mantenimiento (2) Proceso de mantenimiento de software [12].
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Experiencias en integración y evolución de sistemas legados
  • 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]
  • Identificación de rasgos “features” Metodología propuesta por Mehta
  • Framework de generación de wrappers Framework de generación de wrappers en ambientes distribuidos [4]
  • Wrapper para captura I/O Arquitectura de wrappers propuesta por Wohlstadter, Jackson y Devanbu [13]
  • Integración de sistemas orientados a servicios Wrapping de tres niveles propuesto por Zemlicka y Kral [14]
  • 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].
  • 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.
  • 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
  • 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
  • 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”
  • Aplicación de técnicas basadas en POA
  • 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
  • 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.
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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.
  • Muchas Gracias [email_address]