Hacia_una_Arquitectura_de_Software_que_Facilite_el

Vista previa del material en texto

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/255656384
Hacia una Arquitectura de Software que Facilite el Mantenimiento y Evolución de
los Sistemas Heredados
Article
CITATIONS
0
READS
494
3 authors:
Juan Muñoz López
Instituto Nacional de Estadística y Geografía
11 PUBLICATIONS   6 CITATIONS   
SEE PROFILE
Jaime Muñoz-Arteaga
Autonomous University of Aguascalientes
291 PUBLICATIONS   1,146 CITATIONS   
SEE PROFILE
Francisco Alvarez Rodriguez
Autonomous University of Aguascalientes
288 PUBLICATIONS   916 CITATIONS   
SEE PROFILE
All content following this page was uploaded by Francisco Alvarez Rodriguez on 28 May 2014.
The user has requested enhancement of the downloaded file.
https://www.researchgate.net/publication/255656384_Hacia_una_Arquitectura_de_Software_que_Facilite_el_Mantenimiento_y_Evolucion_de_los_Sistemas_Heredados?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_2&_esc=publicationCoverPdf
https://www.researchgate.net/publication/255656384_Hacia_una_Arquitectura_de_Software_que_Facilite_el_Mantenimiento_y_Evolucion_de_los_Sistemas_Heredados?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_3&_esc=publicationCoverPdf
https://www.researchgate.net/?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_1&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Juan-Munoz-Lopez?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_4&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Juan-Munoz-Lopez?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_5&_esc=publicationCoverPdf
https://www.researchgate.net/institution/Instituto_Nacional_de_Estadistica_y_Geografia?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_6&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Juan-Munoz-Lopez?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_7&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Jaime-Munoz-Arteaga?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_4&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Jaime-Munoz-Arteaga?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_5&_esc=publicationCoverPdf
https://www.researchgate.net/institution/Autonomous_University_of_Aguascalientes?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_6&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Jaime-Munoz-Arteaga?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_7&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Francisco-Rodriguez-41?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_4&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Francisco-Rodriguez-41?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_5&_esc=publicationCoverPdf
https://www.researchgate.net/institution/Autonomous_University_of_Aguascalientes?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_6&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Francisco-Rodriguez-41?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_7&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Francisco-Rodriguez-41?enrichId=rgreq-57c9ad35106fdf855e860a224fb7ea31-XXX&enrichSource=Y292ZXJQYWdlOzI1NTY1NjM4NDtBUzoxMDY0NTMyMDU1MjAzODhAMTQwMjM5MTgzMDM1Ng%3D%3D&el=1_x_10&_esc=publicationCoverPdf
Hacia una Arquitectura de Software que Facilite el 
Mantenimiento y Evolución de los Sistemas Heredados 
Juan Muñoz López 1, Jaime Muñoz Arteaga 2 Francisco Javier Álvarez Rodríguez3 
1 Universidad Autónoma de Aguascalientes- Centro de Ciencias Básicas, Av. 
Universidad #940, Fracc. Campestre, Aguascalientes, Ags., 20100. México 
jmunoz@correo.uaa.mx 
2 Universidad Autónoma de Aguascalientes- Centro de Ciencias Básicas, Av. 
Universidad #940, Fracc. Campestre, Aguascalientes, Ags., 20100. México 
jmunozar@correo.uaa.mx 
3 Universidad Autónoma de Aguascalientes- Centro de Ciencias Básicas, Av. 
Universidad #940, Fracc. Campestre, Aguascalientes, Ags., 20100. México 
fjalvar@correo.uaa.mx 
 
 
Resumen. Este trabajo aborda la problemática que representa para las empresas 
evolucionar los sistemas heredados que inhiben su desarrollo y dificultan sus 
estrategias de competitividad. Así mismo, se hace una revisión de las 
estrategias más comunes de mantenimiento y sus principales limitaciones. 
Se propone una solución de arquitectura de software que parte de la aplicación 
de patrones arquitectónicos conocidos y que proporciona las bases para 
establecer un proceso de evolución de software que simplifica las tareas a 
desarrollar y reduce sus costos. 
 
Palabras clave: Arquitectura de Software, Sistemas Heredados, Evolución de 
Software, Mantenimiento de Software. 
1 Introducción 
Las empresas invierten una gran cantidad de recursos para mantener funcionando los 
sistemas que soportan sus áreas de negocio. De acuerdo con las leyes de Lehman [4], 
los sistemas que resuelven un problema del mundo real deben adaptarse continuamente 
ya que en caso de no hacerlo la solución que aportan será cada vez menos satisfactoria. 
Al añadir código al sistema, las tareas de mantenimiento se encarecen y complican. 
Los cambios en el entorno agravan este problema. Se debe decidir si se siguen 
utilizando tecnologías que salen del mercado o se migra hacia otras nuevas. 
No es recomendable continuar utilizando una tecnología que se ha vuelto obsoleta; 
las partes de hardware se vuelven escasas y es costoso conseguirlas; el software de base 
de los sistemas deja de ser soportado por sus fabricantes y la gente con habilidades para 
realizar ajustes y corregir problemas en él también comienza a escasear. 
 Los sistemas están sujetos a una dinámica de mantenimiento constante, adaptándose 
para satisfacer nuevas necesidades y soportar nuevas tecnologías. Más de la mitad del 
esfuerzo de desarrollo de una organización se destina al mantenimiento [3]. 
El mantenimiento de muchos sistemas heredados llega a ser incosteable y por tanto, 
la organización decide reemplazarlos. En algunas ocasiones el reemplazo de un sistema 
es una labor que no requiere demasiado esfuerzo, ni recursos y la empresa considera 
que tomó una decisión que se había postergado de manera innecesaria. Sin embargo, en 
la mayoría de los casos, no es fácil sustituir un sistema heredado. 
Muchos sistemas heredados son críticos para soportar los procesos de la 
organización y constituyen la única fuente de conocimiento que se tiene de ellos. Es 
posible que ya no se cuente con el personal que desarrolló un sistema que ha estado 
trabajando durante varios años con lenguajes y tecnologíasque resultan desconocidas 
para los nuevos equipos de desarrollo. 
La reingeniería de software puede ayudar a incrementar mantenibilidad y 
funcionalidad de un sistema. Sin embargo, los beneficios de la reingeniería serán 
limitados si no se modifica su arquitectura [1,3]. 
Como se mencionó anteriormente, la evolución arquitectónica permite incrementar 
la capacidad de adaptación del sistema, pero es un proceso complejo y costoso que 
implica riesgos difíciles de afrontar. 
2 Estado del Arte 
Las organizaciones deben evolucionar y adaptarse a la dinámica de su entorno para 
asegurar su permanencia; así mismo, sus sistemas deben evolucionar para satisfacer las 
nuevas necesidades de información y procesamiento que se presentan. 
Si un programa de software no puede adaptarse a un entorno cambiante, entonces 
inhibirá el desarrollo de la organización en lugar de facilitar su labor. Existen diferentes 
estrategias que permiten evolucionar el software, entre las que podemos mencionar el 
mantenimiento de software, la evolución arquitectónica y la reingeniería de software. 
El mantenimiento de software de acuerdo con el Glosario Estándar de Terminología 
de Ingeniería de Software de la IEEE [2] es “la modificación de un producto de 
software después de su entrega al cliente o usuario para corregir defectos, mejorar el 
rendimiento u otras propiedades deseables, o para adaptarlo a un cambio de entorno”. 
Las diferentes razones que originan el mantenimiento permiten establecer una 
clasificación: el mantenimiento correctivo se orienta a eliminar los defectos del sistema 
que se manifiestan en forma de fallas; la finalidad del mantenimiento perfectivo es 
realizar mejoras y adiciones a las características funcionales y a la eficiencia del 
sistema; por último, el mantenimiento adaptativo consiste en modificar el sistema para 
responder a los cambios tecnológicos del medio en el que se ejecuta. 
Normalmente, el mantenimiento estará presente durante toda la vida útil de un 
sistema; la mayor parte de las veces, por la necesidad de agregar funcionalidad a los 
programas, o para adaptarlos a los cambios producidos en el entorno. 
La repetida aplicación de mantenimiento a un sistema introduce cambios que hacen 
que el software evolucione. La evolución tiene un costo, cada vez que se agrega 
funcionalidad al sistema o se le prepara para trabajar con una nueva tecnología, el 
sistema se vuelve más complejo y es más difícil darle mantenimiento. 
La evolución arquitectónica consiste en realizar una serie de cambios que modifican 
la concepción misma del sistema. El cambio de la arquitectura de un sistema 
centralizado a un modelo cliente/Servidor ejemplifica dicha transformación. 
El cambio de arquitectura de un sistema representa un fuerte y costoso reto [1]. El 
equipo de trabajo se encontrará con problemas como: estructuras complejas, 
componentes funcionales entremezclados, falta de documentación y desconocimiento 
de cómo trabaja en su totalidad el sistema. 
La reingeniería de software busca reimplementar los sistemas para aumentar su 
mantenibilidad. Esta estrategia comprende la redocumentación; la organización y 
reestructura; la traducción a un lenguaje de programación más moderno y la 
modificación y actualización de la estructura y los valores de los datos del sistema. No 
cambia ni la funcionalidad del software, ni la arquitectura del sistema [1]. Esta 
estrategia se asocia con alguna forma de mantenimiento preventivo e implica la 
reconstrucción del sistema, es costosa y puede tomar una gran cantidad de tiempo [3]. 
Cada una de las estrategias descritas tiene diferentes propósitos y son 
complementarias entre sí. 
3 Metodología utilizada 
La solución que se propone al problema planteado consiste en crear una arquitectura de 
referencia que permita establecer las bases de diseño para integrar los programas 
heredados a un ambiente de sistemas soportado por nuevas tecnologías. 
Una arquitectura que combine los patrones arquitectónicos de broker y de capas 
podría permitir el reemplazo gradual de los elementos funcionales de los sistemas 
heredados. Sommerville [1] menciona que esta combinación puede servir para 
transformar un sistema centralizado en uno descentralizado. Consideramos que este 
patrón también puede utilizarse para integrar sistemas autónomos, lo que genera una 
sinergia que amplía su alcance individual. 
 
 Fig. 1. Integración de Sistemas Heredados Utilizando el Patrón de Broker 
 
El patrón arquitectónico de broker introduce una capa de servicios de software que 
realiza las operaciones de conversión y acoplamiento necesarias para simplificar el 
intercambio de información entre los sistemas (ver Figura 1). Se estima que gracias a 
las facilidades suministradas por este patrón y utilizando los mecanismos apropiados es 
posible reemplazar gradualmente la funcionalidad del sistema al mismo tiempo que se 
integran los datos que contiene, sin esperar a que esto suceda en una etapa avanzada. 
El nuevo sistema adoptará una arquitectura cliente/servidor en la que el cliente 
terminará sustituyendo al sistema heredado. La arquitectura del nuevo sistema será más 
modular y flexible que la de los sistemas heredados que sustituye. Esta será una 
característica que nacerá con el sistema y formará parte de él conforme evoluciona. 
Al integrarse los sistemas heredados dan lugar a un nuevo sistema separado de los 
mecanismos de integración. Esto trae como ventaja contar con un sistema lógicamente 
centralizado sin que importe si físicamente está distribuido o concentrado. La 
independencia de los mecanismos de integración permitirá que estos sean eliminados 
cuando ya no se requieran y que puedan integrarse nuevos sistemas si es necesario. 
Existen varios puntos de enlace que son críticos para realizar la integración del 
sistema. En la figura 1 se destacan con cuadros punteados las interfaces de entrada y de 
salida hacia los sistemas autónomos y hacia sus estructuras de almacenamiento. Cada 
una de estas interfases debe ser tratada por un mecanismo de integración diferente; sin 
embargo habrá un elemento de integración principal que hará que cada uno de los 
mecanismos individuales se una y en conjunto sean percibidos como uno solo. 
Adicionalmente, el modelo de distribución de capas ayuda a organizar y agrupar las 
tareas de un sistema [5] de forma que son percibidas más claramente y pueden atacarse 
utilizando estrategias especializadas acordes a diferentes niveles de abstracción. 
En el trabajo de Sommerville [1] se presenta una posible configuración de las capas 
arquitectónicas que deberían tomarse en cuenta para visualizar un sistema heredado. En 
ella se describen cinco capas que describen los elementos técnicos del software, desde 
la capa de Base de Datos hasta la de presentación.; sin embargo, es necesario 
considerar también capas más bajas que tomen en cuenta aspectos físicos relacionados 
con el hardware y su distribución. Además, se deben añadir capas superiores que 
consideren las características no funcionales y las reglas de negocio que forman parte 
de los elementos conceptuales del sistema. 
Al principio, ciertas partes del nuevo sistema deberán servir para proporcionar una 
nueva interfase para comunicarse con los programas heredados que se encuentran en 
proceso de reemplazo, pero con el tiempo deberán realizar estas solicitudes a los 
nuevos módulos del sistema que hayan sido implementados. El uso de patrones 
adicionales como el de todo-partes, posiblemente permitirá realizar el encapsulamiento 
e integración de los componentes que compartirán una interfase común hacia su 
funcionalidad. 
4 Resultados Experimentales 
Como caso de estudio del empleo de arquitecturas de referencia para soportar la 
evolución de los sistemas heredados se plantea la integración de sistemas que son 
comunes en las organizaciones, por ejemplo: contabilidad, ventas e inventarios. Estos 
sistemas trabajan autónomamente en áreas separadas, sin embargo, lainformación 
producida por algunos de ellos, es insumo de otros; por ejemplo, la información que 
produce los sistemas de ventas y de inventarios es insumo del sistema de contabilidad. 
Compartir la información entre los sistemas requiere de la aplicación de mucho 
esfuerzo manual para transportar y convertir la información de un sistema al otro. Así 
mismo, es común que a cada sistema se deban agregar nuevos reportes y consultas para 
satisfacer nuevas necesidades. Si se requiere un reporte que integre la información de 
dos o más de estos sistemas, probablemente se deba hacer un trabajo artesanal 
utilizando herramientas como hojas de cálculo y procesadores de texto. 
Si se realiza una transformación arquitectónica bajo la metodología propuesta en 
este documento, se establece un marco de trabajo que facilita la integración de la 
información de los diferentes sistemas en uno solo. Esta integración permite que se 
puedan utilizar los datos de diferentes sistemas para producir los nuevos reportes que 
son requeridos. 
 
Fig. 2. Mecanismo de Reemplazo de Módulos en el Sistema Integrado 
 
Los mecanismos de integración permiten reemplazar gradualmente los módulos 
provenientes de los sistemas autónomos. Un modulo de procesamiento podrá utilizar 
los datos y la funcionalidad del sistema heredado y podrá reemplazarlo posteriormente 
con una nueva versión de dicho sistema de manera progresiva (ver figura 2). 
De esta forma el mecanismo propuesto permite hacer una migración gradual de 
datos y funcionalidad en la que los beneficios de una nueva interfase integrada y una 
arquitectura modular se pueden percibir desde el principio. 
5 Conclusiones y Trabajos Futuros de Investigación 
El modelo arquitectónico que se plantea podría proporcionar un alto nivel de 
flexibilidad que podría servir para establecer un proceso que integre diferentes 
estrategias de mantenimiento. 
La dificultad de realizar una evolución arquitectónica del sistema se podría 
simplificar utilizando la combinación de patrones que se plantea, al mismo tiempo que 
se establece un marco de trabajo que permite la evolución gradual de los sistemas 
heredados, con lo que es posible distribuir los costos de manera que puedan ser 
afrontados más fácilmente por la organización. 
Los nuevos módulos del sistema al irse migrando llevarían implícito un trabajo de 
reingeniería que podría continuarse en el futuro gracias a la flexibilidad de la 
arquitectura del sistema resultante. 
Además, gracias a los trabajos de rediseño arquitectónico y de reingeniería que se 
apliquen al sistema, el mantenimiento al sistema se podrá ver beneficiado por una 
simplificación que permitirá integrar nuevas funciones al sistema existente. 
La propuesta que se plantea presenta una arquitectura de software que proporcionará 
las bases para generar un proceso más simple para evolucionar el software. Es 
necesario desarrollar un método que describa en forma concreta la serie ordenada de 
actividades que deberán realizarse. 
Este documento plantea los esbozos iniciales de una arquitectura de referencia, es 
necesario documentarla a partir de modelos estandarizados, como por ejemplo UML, a 
los que habrá que hacer las adaptaciones necesarias para que puedan presentar las 
características funcionales y no funcionales de un sistema. 
 
Reconocimientos. Los autores agradecemos a los revisores sus comentarios que 
resultaran de gran utilidad para enriquecer este trabajo. Así mismo, agradecemos a la 
UAA y al INEGI por su apoyo en la realización de esta investigación. 
Referencias 
[1] I. Sommerville, Ingeniería de Software, Pearson Education, México, 2002 
[2] ANSI/IEEE, Standard 610: IEEE Standard Glosary of Software Engineering Terminology, 
New York: Institute of Electrical and Electronics Engineers, Inc., 1990 
[3] R. S. Pressman, Software Engineering; A Practitioner’s Approach, Fifth Edition, McGraw 
Hill, USA, 2001 
[4] M. M. Lehman, Laws of Software Evolution Revisited, Department of Computing Imperial 
College, Londres, Inglaterra, 1997, pp 1-11 
[5] F. Buschman, R. Meunier, H. Ronhert, P., Sommerland, M. Stal, Pattern-Oriented Software 
Architecture; A System of Patterns, Willey, USA, 1996 
[6] H. Li, C. Reinke, S. Thompson, Tool Support for Refactoring Functional Programs, 
Haskell’03, ACM, Suecia, Agosto 2003, pp 27-38 
[7] M. O’ Cinnéide, Automated Application of Dessign Patterns: A Reffactoring Approach, 
Doctoral Thesis, University of Dublín, Trinity College, Irlanda, Octubre 2000 
View publication stats
https://www.researchgate.net/publication/255656384