Leer Artículo - Inicio - Universidad de los Andes
Anuncio
Conviviendo con sistemas legados Nolberto Jaimes Rojas n-jaimes@uniandes.edu.co Universidad de los Andes, Bogotá, Colombia. Resumen. El continúo cambio tecnológico que han sufrido las organizaciones durante los últimos años, la masificación de Internet, los paradigmas de objetos, componentes y servicios, las nuevas necesidades que han surgido en las compañías para tener un contacto mas cercano con sus clientes, han generado, que toda la información que permanecía en sistemas heterogéneos, independientes y aislados, cobre importancia y se empiecen a evaluar estrategias para su aprovechamiento. En este documento se presenta un análisis de las alternativas existentes para tratar con la información de estos sistemas legados. Palabras clave. Sistemas legados, evolución 1 INTRODUCCION Hoy en día es frecuente encontrar dentro de las organizaciones aplicaciones que fueron desarrolladas desde los años 80 hasta esta época. A raíz de las restricciones que existían en aquel entonces, estas aplicaciones eran dependientes de los grandes fabricantes de hardware y software, generando una dependencia total por parte de las organizaciones. Estos sistemas frecuentemente no estaban bien documentados, lo que llevaba a una tarea de mantenimiento bastante compleja. Fueron construidos de forma rígida, con el objetivo específico de solucionar los requerimientos funcionales; dejando de lado aspectos importantes como la evolución, extensibilidad, portabilidad y compatibilidad entre otros [1]. Estas necesidades de evolución y de implementación de nuevos requerimientos, hacen necesario un mantenimiento que no es fácil de llevar a cabo, lo que termina desencadenando en el planteamiento de algunas alternativas como: Llevar a cabo un nuevo desarrollo que contemple la funcionalidad del sistema legado más los nuevos requerimientos, otra alternativa es evaluar un cambio al sistema legado que permita adicionar nuevos requerimientos de una forma sencilla, o la última opción es simplemente desechar el sistema y adquirir una herramienta del mercado que supla las necesidades actuales de la organización. Las alternativas existentes para dar un adecuado tratamiento a este tipo de sistemas serán revisadas a lo largo del documento, haciendo énfasis en las bondades y problemas que pueden llegar a traer cada una de ellas para la organización, pero antes se revisarán algunas características que indican si el sistema con el cual se va a tratar realmente puede PARADIGMA REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE 2 n-jaimes@uniandes.edu.co ser considerado un sistema legado y abordaremos una de las posibles clasificaciones que pueden recibir. Características que hacen de un sistema, realmente un legado [5] 1. Se trata de un sistema escrito en lenguajes de varios años atrás como: Cobol, RPG, PL, Assembler. 2. Normalmente estos sistemas son soportados por un DBMS (manejador de base de datos [13]) ya obsoleto. 3. La interface de cliente está basada en terminales (3270 [12] o 5250 [3]) las cuales no son gráficas. 4. Las aplicaciones que componen el sistema, son frecuentemente monolíticas, las cuales fueron desarrolladas para suplir una necesidad de la organización, separadas del resto del sistema, presentando una integración normalmente vertical. 5. Es un sistema fundamentalmente dirigido a la parte operativa de las organizaciones, normalmente de misión crítica para la organización que requiere estar operando todo el tiempo. 6. Suelen ser sistemas bastante complejos y grandes (millones de líneas de código y lógica de negocio). 7. Estos tipos de sistema suelen no tener ningún tipo de documentación, no es posible hacer trazabilidad de funcionalidad. Clasificación de sistemas legados En la figura 1 se ilustra la clasificación de un componente o aplicación desde el punto de vista del manejo de la información. Figure 1. Clasificación [5] Altamente Desacoplados, el componente de la aplicación se encuentra separado en lógica de presentación, lógica de negocio y acceso a datos. Este tipo de aplicaciones o componentes presenta mayor facilidad a la hora de ser mantenido. VOL. 1 PARADIGMA REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE Conviviendo con sistemas legados 3 Desacoplamiento de datos, son sistemas considerados semi-estructurados, el componente es normalmente descompuesto en dos niveles. Un nivel de acceso a datos y otro nivel que cubre la presentación y la lógica de negocio. En este tipo de sistemas es posible acceder directamente a los datos, mas no a la lógica de negocio. Desacoplamiento de programas, también considerado semi-estructurado, el componente es descompuesto al igual que el anterior en dos niveles, con la diferencia que el acceso a datos ahora es unido con la lógica de negocio, y en el otro nivel se encuentra únicamente la presentación. Monolítico, sistema no estructurado, en el cual el componente aplicativo es un solo bloque que contiene todos los niveles. Son accedidos generalmente a través de la invocación desde terminales. 2 TRATAMIENTO DE LOS SISTEMAS LEGADOS Hoy en día es una realidad para todas las personas involucradas en tecnología, encontrarse con cientos de sistemas legados dentro de las organizaciones. Tipos de tratamiento de los sistemas legados Las tareas de mantenimiento del sistema eran tareas operativas asociadas a la constante evolución del software. Últimamente estas labores de mantenimiento han adquirido una gran importancia que requiere de un profundo conocimiento del sistema, lo que es conocido en la reingeniería del software como reingeniería de tipo white-box, o limitarse a las interfaces externas del sistema conocidas como tipo black-box. El tipo white-box es parte de la ingeniería reversa y se enfatiza en una comprensión profunda del sistema. El tipo black-box se limita al estudio de las interfaces externas del sistema para la adición de encapsulamiento (wrapping). En la ingeniería reversa, el proceso de análisis del sistema, comprende la identificación de todos los módulos existentes, y la interrelación existente entre ellos, creando una representación de alto nivel de abstracción. A partir de esto, si es posible llegar a pensar en sustituir el sistema. El wrapping, evita la comprensión detallada de la estructura interna del sistema, limitándose a conocer las interfaces ofrecidas y que se encuentran funcionando correctamente. El wrapping se basa en el principio de encapsulamiento, idea original del paradigma de programación orientada a objetos, y el cual consiste en ocultar el detalle de la implementación de un objeto, mientras se provee una interfaz por medio de sus métodos permitidos. Una aproximación a las alternativas existentes para el tratamiento de los sistemas legados puede ser: PARADIGMA REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE VOL. 1 4 n-jaimes@uniandes.edu.co 1. 2. 3. 4. Retirar el sistema, excluir el sistema y reemplazarlo con un sistema comercial. Sustitución completa, reescribir el sistema en su totalidad. Migración gradual, realizar una transformación del sistema, de forma gradual. Integración, considerar el mantener el sistema, sin modificarlo exportando su funcionalidad efectuando wrapping con algún tipo de tecnología. Figure 2. Tratamiento de un legado [1][14] Analizando la Figura 2 se puede observar en la parte marcada con la letra A todo lo relacionado con el sistema legado, el cual puede estar compuesto por una o más aplicaciones acompañadas de una infraestructura, el objetivo es llegar a un sistema Moderno el cual está marcado con la letra C, para esto es necesario pasar por un análisis que está compuesto por varias alternativas contempladas dentro de lo que está marcado con la letra B lo cual detallaremos en el desarrollo del documento. Mantenimiento Por mantenimiento se entiende el proceso necesario para mantener la funcionalidad y eficiencia que ofrece el sistema a la organización. El mantenimiento de un componente estratégico hecho de manera ágil y eficaz, garantizará el mejoramiento del proceso productivo de la organización. Por el contrario, un mantenimiento no estructurado llevará al rápido degradamiento de un sistema, generando inestabilidad y de seguro una muerte lenta del sistema. En general el mantenimiento es la base para el correcto funcionamiento de un sistema, la velocidad con que éste se pueda efectuar, puede convertirse en una ventaja o desventaja para el sistema legado, y depende en gran parte de la calidad del proceso de mantenimiento del sistema. El mantenimiento se divide en mantenimiento Correctivo, el cual suele ser utilizado para medir la calidad del software dentro de la remoción de defectos, es de suma importancia ya que un defecto origina un comportamiento no esperado en el sistema, el cual debe ser corregido. Mantenimiento evolutivo, el cual es observado desde los requerimientos funcionales, pensando en el mejoramiento continuo del sistema. VOL. 1 PARADIGMA REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE Conviviendo con sistemas legados 5 Retirar el sistema y reemplazarlo Tomar la decisión de retirar un sistema no es una tarea sencilla de llevar a cabo. Esta tarea se debe realizar cuando el sistema ya no es capaz de ser mantenido al ritmo que el negocio lo exige o el costo de llegar a hacerlo es demasiado alto. Se hace necesario hacer un estudio detallado comprendiendo el núcleo del sistema, encontrando toda la funcionalidad ofrecida y datos utilizados para todo el proceso. Para esto hay que encontrar la estrategia más adecuada a la organización la cual depende de los recursos con los que se cuente como arquitectura del sistema, documentación del diseño, casos de prueba, especificaciones, documentación de código, documentación de procesos y restricciones. Actualmente están creciendo las casas de Software especializadas en el mantenimiento de este tipo de sistemas. En muchas ocasiones es necesario establecer fronteras en lo que desea revisar y el nivel de detalle al que se pretende llegar, detectar las relaciones que existe entre módulos o componentes. Lo más importante es tomar una buena estrategia para la obtención de toda esta información. Pensar en un nuevo desarrollo también presenta nuevas dificultades ya que normalmente las personas que conocen el negocio no conocen de nuevas tecnologías como J2EE [4] o .NET [6], se han quedado obsoletos prestando mantenimiento al software construido, tampoco se puede pensar en iniciar el nuevo proyecto sin tener en cuenta todo el conocimiento y la información que existe en el sistema legado. Aunque pensar en reescribir la aplicación puede traer beneficios a futuro como un ambiente ágil que puede adaptarse rápidamente a los cambios del modelo de negocio, tener una arquitectura flexible que permita extender fácilmente nuevas funcionalidades reduciendo los costos de mantenimiento, no se puede desechar todo el conocimiento y la experiencia existente, lo que hace necesario realizar todo un plan para hacer la migración de datos migración de reglas de negocio transferencia de experiencia y conocimiento. Migración Una migración puede considerarse como el paso de un sistema existente hacia un nuevo sistema. La migración suele ser un proceso altamente riesgoso, y el índice de proyectos fallidos es alto. Se podría pensar en una migración total o parcial, cada una de ellas puede ofrecer algunas ventajas y desventajas. Migración parcial, solo una parte del sistema es transformada, generalmente se hace con aquella que tiene mayores problemas, mayores costos de mantenimiento, menor flexibilidad etc. Esta suele ser una solución factible con un riesgo normal. Migración completa, el riego es bastante alto, se hace una migración total del sistema y es necesario redefinir arquitectura, diseño y todo lo que involucra crear un sistema. Migración de interfaz cliente, la gran mayoría de los sistemas legados, aun hoy en día son accedidos mediante terminales brutas, una típica son las terminales 3270 [11]. PARADIGMA REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE VOL. 1 6 n-jaimes@uniandes.edu.co El mercado actual ofrece algunas herramientas, que pueden ser usadas como instrumento, para generar interfaces GUI o una interacción vía Web. Esta tecnología es conocida como MiddleWare de Screen Scraping [11] basados en lenguajes de scripting. Migración de datos, la migración de datos consiste en la transformación de un dato en un formato específico, a un formato en otra plataforma. La solución de este problema presenta la siguiente caracterización: Conversión (por ejemplo de una base de datos no relacional a una relacional). Transformación, Localización (de un sistema centralizado, a un sistema distribuido). Integración Modificación directa sobre el código para corregir anomalías o posibles problemas, limpiar y hacer más claro el código para hacer la labor de mantenimiento de las aplicaciones más sencilla, esto también incluye modificaciones menores como extraer reglas que hagan más claro el código facilitando la labor posteriormente. Este concepto es normalmente usado sobre aplicaciones que serán ejecutadas nuevamente sobre un host. Esta optimización de código logra en tiempo de ejecución mejoras de eficiencia en la aplicación. Analizar, evaluar y limpiar el código asegura un mejor rendimiento y trazabilidad de los sistemas. Se obtienen beneficios como eliminación de código muerto estructuras no usadas, reestructurar funcionalidades y simplificar el esfuerzo de una nueva arquitectura. Normalmente estos sistemas no cuentan con documentación lo que hace más difícil la labor, no se tiene trazabilidad entre el código implementado y los requerimientos funcionales implementados. En esta reorganización de código podemos contemplar la posibilidad de hacer un wrapping de funcionalidad o de datos. A continuación detallaremos un poco más las posibilidades existentes y la tecnología que podría ser usada para llevarlo a cabo. a) Wrapping de datos [7]: Consiste en acceder a los datos del sistema legado usando una interfaz diferente a la contemplada inicialmente. Usar puentes hasta los nuevos lenguajes de implementación haciendo uso de Gateway de base de datos, el cual emplea interfases propietarias del motor de datos del sistema legado (as/400) [2] y en otros casos interfases estándares en el mercado como ODBC [9], JDBC [8]. Integración con tecnología XML aprovechando el intercambio de datos entre sistemas o negocios. Replicación de datos, esta es utilizada comúnmente para descentralizar el almacenamiento masivo de datos de los Mainframes, buscando que bases de datos locales repliquen parte de los datos centralizados. VOL. 1 PARADIGMA REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE Conviviendo con sistemas legados 7 Capa de persistencia, ésta es construida específicamente para cada sistema, buscando el acceso de aplicaciones desarrolladas con tecnología orientada a objetos. b) Wrapping funcional [7] Este encapsula datos y funcionalidades del sistema legado, se suelen utilizar alguna de las siguientes estrategias. Integración con CGI [10], permitiendo el acceso al sistema legado mediante un servidor Web o HTTP. Este es un método bastante interesante ya que está pensado para sustituir las pantallas de texto por una interfaz gráfica, que sigue ofreciendo al usuario la misma funcionalidad pero en una nueva interfaz, algo similar a la técnica de Screen Scraping. La tecnología de objetos distribuidos, es la combinación de objetos con la distribución, un ejemplo clásico es CORBA. Este modelo es bastante complejo y lo que busca es representar los aplicaciones, los datos del negocio y los servicios como objetos, aquí se encuentran muchos problemas como pasar la semántica monolítica de los legados a objetos ya que se debe conocer completamente el dominio de la aplicación, otro problema es la representación de los requerimientos no funcionales. c) Wrapping orientado a componentes [7] Este utiliza el modelo de componentes distribuidos, donde la idea es separar la interfase del sistema legado en módulos agrupados por unidades lógicas, buscando un punto de contacto único, a través del cual se establece la comunicación entre un EJB por ejemplo y una función concreta del sistema legado. La experiencia demuestra que a los sistemas legados les espera una larga vida, debido a la gestión que las organizaciones han usado para su evolucion. Las tendencias actuales de herramientas externas suelen adicionar ciertos riesgos a los proyectos, pero ofreciendo una forma fácil y atractiva de obtener resultados rápidos, muchas organizaciones terminan haciendo uso de ellos como un mecanismo de bajar costos y entregar resultados inmediatos para atender estrategias de mercado de sus negocios. No existe una receta a seguir, cada problema debe asumirse de forma independiente y de acuerdo a las variables involucradas en cada uno de estos, se toma la mejor decisión. Existen muchos casos de éxito donde se emplearon cada una de las alternativas expuestas de forma independiente con buenos resultados, así como otros tanto que terminaron en el fracaso. REFERENCES PARADIGMA REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE VOL. 1 8 n-jaimes@uniandes.edu.co [1] Eds. Application Modernization. http://www.eds.com Noviembre 2006. [2] IBM. As/400. http://www.recursos-as400.com Octubre 2006. [3] IBM. OS/400 V5R1. http://www.recursos-as400.com/v5r1.shtml Septiembre2006. [4] Java Technology. J2EE http://java.sun.com Noviembre 2006. [5] Massari A, Mecella. M IL TRATTAMENTO DEI LEGACY SYSTEM. http://www.dis.uniroma1.it/~mecella/publications/Miscellanea/legacy_system.pdf Noviembre 2006. [6] Microsoft. .Net Framework http://msdn2.microsoft.com/netframework/default.aspx Noviembre 2006. [7] Rodríguez A, Márquez A, Toro M. Evolución del http://lsi.ugr.es/~gedes/actividades/tallerEvolucion2001/docs/1DEF.pdf 2006. [8] Unam. Jdbc. http://www.mcc.unam.mx/~cursos/Algoritmos/javaDC99-1/jdbcexpo/expo.html Noviembre 2006. [9] Universidad de Valencia. ODBC. http://www.uv.es/~jac/guia/gestion/gestion3.htm Noviembre 2006. software. Agosto [10] Shklar, L. Web Access to Legacy Data. http://athos.rutgers.edu/~shklar/weblegacy/summary.html Mayo 2007. [11] Wikipedia. Screen scraping. http://en.wikipedia.org/wiki/Screen_scraping Noviembre 2006. [12] Wikipedia. Emulador de terminal. http://es.wikipedia.org/wiki/Emulador_de_terminal Agosto 2006. [13] Wikipedia. Sistema de gestión de base de datos. http://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_base_de_datos Octubre 2006. [14] Zoufaly F. Issues and Challenges Facing Legacy Systems. http://www.developer.com/mgmt/article.php/11085_1492531_1 Agosto 2006. VOL. 1 PARADIGMA REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE
