P. 1
sistemas_legados

sistemas_legados

|Views: 24|Likes:
Publicado porshlomovln

More info:

Published by: shlomovln on Apr 02, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

04/02/2011

pdf

text

original

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?

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. Las reglas de negocio que implementa el software se ajustan a la realidad? 8. Costo de hacer reingeniería resulta muy alto. • • • • 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. Preventivo: mejorar calidad y mantenibilidad. Los datos que maneja el sistema de software son consistentes. En qué proporción están documentados el código.6. Perfectivo: actividades para mejorar y adicionar funcionalidades. 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. • Un aspecto esencial de esta perspectiva es plañera la migración del sistema heredado a un nuevo sistema. Más razonable invertir en nuevas tecnologías de hardware o software. . poseen niveles de redundancia aceptados y tiene características de formato compatibles? 7.

Figura 4: Proceso de reingeniería propuesto por Sommerville. o Es una forma de reutilizar código. • Enfoque más amplio y drástico para evolucionar un sistema.Figura 3: Proceso de mantenimiento del software. 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. Aspectos de reingeniería Problema delimitado • cambio de estado del sistema actual a un sistema deseado Sistema • un modelo guía del proceso • actividades .

mediante ingeniería inversa. extraer los datos que dieron lugar a esa presentación.) .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.

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.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. 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 12: Aplicación de patrones de diseño. Figura 11: Integración de sistemas orientados a servicios. .Figura 10: Wrapper para captura de E/S.

Separación de preocupaciones (concerns) mejora las tareas de desarrollo y mantenimiento de software. Los RNF son transversales al código y se repiten en diferentes lugares. El resultado de este proceso es la contaminación del código mezclando elementos funcionales y no funcionales. . No se consideraron las dimensiones no funcionales de los requerimientos. Los requerimientos no funcionales se representan como preocupaciones o “concerns”. • • • Modularizar el software del sistema legado separando los elementos funcionales de aquellos que representan los requerimientos no funcionales (RNF). 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.Programación orientada a aspectos (POA) • • • • • • • Los sistemas legados fueron analizados y diseñados en una sola dimensión (funcional). Buscar aislar aquellas preocupaciones transversales (cross cutting 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). En ambientes de integración de datos y acelerados cambios tecnológicos. 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. * técnicas basadas en wrapping de encapsulamiento Integración empresarial * técnicas basadas en SOA Extender funcionalidad de granularidad variada mediante composición. 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. * modelos basados en rasgos “features” Actualización y redefinición de requerimientos no funcionales * programación orientada a aspectos • • • • • • • • . * programación dinámica con técnicas de reflexión (reflect) Niveles de documentación pobre y con funcionalidad de negocio aceptable.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->