Método para Generar una Arquitectura de Referencia para

Integrar Sistemas Heredados y Bases de Datos Heterogéneas

Jaime Muñoz Arteaga Juan Muñoz López
Univ. Autónoma de Aguascalientes Univ. Autónoma de Aguascalientes
Av.Universidad #940, Ags. Mexico. Av.Universidad #940, Ags. Mexico.
jmunozar@correo.uaa.mx jmunoz@correo.uaa.mx

RESUMEN componentes y conectores de un programa o

En este documento se propone un método para
desarrollar modelos arquitectónicos y la creación
de una arquitectura de referencia para construir
nuevos sistemas a partir de la integración de
sistemas autónomos preexistentes y bases de
datos heterogéneas. Esta arquitectura además
podría ser utilizada para agregar funcionalidad a
sistemas heredados sin modificarlos.
I. INTRODUCCIÓN
Las organizaciones generalmente crean sistemas
para resolver problemas puntuales de
procesamiento de información que se presentan en
un área de la empresa. Los sistemas que son
implantados correctamente y satisfacen las
necesidades por las que fueron creados se integran
a los procesos de la organización. Si estas
aplicaciones continúan funcionando y recibiendo
mantenimiento, eventualmente se convertirán en
sistemas heredados [6].
Al ir agregando nuevo software, el ambiente
computacional de la organización se convierte en
una mezcla de sistemas distribuidos, heterogéneos
y autónomos [7].
Al madurar en el uso de las tecnologías los
usuarios solicitan programas más complejos para
solucionar problemas más grandes y más difíciles.
Es necesario aplicar los principios de la
arquitectura de software para comprender mejor
como se resolverán los problemas y en que forma
deberán coordinarse los esfuerzos de quienes
intervienen en su desarrollo.
sistema, la forma en que interactúan y se
configuran dichos componentes y conectores y los
principios y guías que norman su diseño y
evolución en el tiempo. La abstracción que
proporciona la arquitectura de software es crítica
para el sistema ya que lo vuelve intelectualmente
tratable y permite explotar patrones recurrentes en
su organización [4].
Un patrón o estilo arquitectónico provee un
conjunto de subsistemas predefinidos, especifica
sus responsabilidades e incluye reglas y guías para
organizar las relaciones entre ellos. El patrón
permite conceptualizar el diseño del sistema a un
alto nivel antes de comenzar a implementarlo [1].
La selección estilos arquitectónicos por medio de
un sistema de clasificación que además establezca
como deben interconectarse es una decisión de
diseño fundamental al desarrollar sistemas de
software pues define un conjunto de arquitecturas
que son viables [2].
Un modelo arquitectónico de referencia se utiliza
para crear arquitecturas de software. Como puede
observarse en la figura 1, este modelo es una
meta-arquitectura que influye fuertemente en la
integridad y estructura del sistema. La arquitectura
de referencia se genera a partir de un sistema de
patrones arquitectónicos y de un modelo de
referencia proyectado en elementos de software y
los flujos de datos que existen entre ellos [1]. Las
características no funcionales y los requerimientos
funcionales son elementos básicos para el diseño
de la arquitectura de software [5].

Figura 1.- Elementos para generar una
arquitectura de software
Un modelo arquitectónico (conocido también
como arquitectura de software) describe los
II. PROBLEMÁTICA
Este documento aborda la necesidad de crear un
modelo de referencia para comenzar a resolver dos
problemas relacionados con los sistemas que
conforman el ambiente computacional de las
organizaciones: ampliar la funcionalidad de los
sistemas heredados; y segundo, integrar la
información de dichos sistemas.
El primer problema aparece conforme evolucionan
las empresas y las expectativas de los usuarios
crecen, ya que los sistemas con que cuentan
pueden llegar a ser insuficientes para satisfacer las
nuevas necesidades de información que demanda
la organización. Es difícil sustituir los sistemas
heredados por otros nuevos ya que se deben
considerar aspectos como: la cantidad de recursos
invertidos; la criticidad y el conocimiento de los
procesos que soportan; las habilidades técnicas
con que cuenta la organización; la cantidad de
recursos que se deben invertir para crear el nuevo
sistema; etc. Si se establece que no es posible
desechar ni modificar al sistema con que se cuenta
y es necesario satisfacer nuevas necesidades de
información, entonces: ¿Cómo agregar nueva
funcionalidad a los sistemas heredados?
Ya que los sistemas heredados están íntimamente
ligados a los procesos de la organización es
importante adaptarlos a las nuevas necesidades
para mantener a la empresa competitiva. Un
conjunto de sistemas que no se adapta al entorno
organizacional cambiante, le inhibe en lugar de
facilitar su labor. Adaptar en vez de desarrollar
nuevamente implica un considerable ahorro de
recursos.
El segundo problema se presenta por la necesidad
de integrar y enriquecer la información de los
sistemas del medio ambiente computacional de la
organización que se encuentra contenida en
diferentes bases autónomas y posiblemente
heterogéneas. Integrar estos sistemas es un
problema tan difícil y común que numerosas
empresas crean diversas soluciones complejas
para lograr este objetivo.
La creación de aplicaciones cooperativas
distribuidas que trabajen a través de Internet para
ofrecer servicios en línea también requiere de la
integración de sistemas heterogéneos.
Solucionar los problemas planteados puede
derivar en beneficios como:
1. Dotar a las organizaciones de un marco de
trabajo para modernizar y gradualmente
reemplazar sus sistemas heredados.
2. Utilizar la información de diferentes sistemas
de manera integral, aprovechando el efecto de
sinergia que se genera.
3. Reutilizar sistemas como partes de un sistema
mayor.
4. Reducir el retrabajo necesario para transportar
información entre sistemas autónomos.
5. Disminuir los costos de mantenimiento de los
sistemas actuales.
Para llegar a desarrollar este tipo de soluciones
Bass et al. [3] y Malveau [8] proponen la
aplicación de modelos arquitectónicos de
referencia que pueden utilizar los diferentes
participantes en un proyecto como punto de
partida para crear arquitecturas que integren
sistemas autónomos preexistentes y bases de datos
heterogéneas y que además permitan agregar
nuevo valor a la información que se encuentra en
dichos sistemas. Desafortunadamente en los
trabajos de ingeniería de software, tales como el
de Malveau [8], no se indica explícitamente como
se puede mejorar un modelo de referencia con el
fin de adaptarlos a los continuos cambios que
requiere un sistema heredado.
IV METODO
Con el fin de dar una solución a la problemática
planteada en la sección anterior, este trabajo
propone un método que permite generar y adaptar
el modelo arquitectónico de referencia en base a
un proceso iterativo e incremental. Consideramos
que dentro del proceso la retroalimentación que se
obtiene en cada iteración puede utilizarse para ir
perfeccionando al propio modelo de referencia, lo
que extiende los beneficios de la retroalimentación
a las arquitecturas de otros sistemas (ver figura 2).
Figura 2.- Método para generar un modelo de
arquitectura de software
La figura 2 muestra nuestro método compuesto
por una serie de pasos secuenciales, sin embargo,
en muchas ocasiones es posible comenzar a
ejecutar alguna tarea sin haber concluido
completamente a su predecesora.
Un modelo arquitectónico se desarrolla en forma
iterativa mediante un proceso que comienza en
una fase de conceptualización. Durante esta fase
se establecen los requerimientos funcionales y las
características no funcionales que deberá contener
el sistema, se evalúa su pertinencia y se establecen
prioridades para las características no funcionales.
Las decisiones iniciales que se toman en el diseño
de la arquitectura incorporarán o excluirán casi
todos los atributos de calidad del sistema [3].
Posteriormente se identifican los elementos
arquitectónicos básicos y se adopta o se crea un
modelo arquitectónico de referencia para crear la
arquitectura de software.
El modelo arquitectónico de referencia se crea
inicialmente a partir de un modelo de referencia y
de la aplicación de patrones arquitectónicos
organizados en un sistema. La arquitectura de
software se ajustará conforme al modelo de
referencia y será evaluada para validar que
contemple todos los requerimientos funcionales.
Durante la creación de un sistema intervienen
diferentes participantes como: el administrador
del proyecto, el encargado de la línea de
producción de la aplicación, los analistas, los
programadores, el equipo de pruebas, los
integradores, el personal de soporte, los
encargados de mantenimiento, los usuarios, los
clientes, los arquitectos de software y los nuevos
interesados. Las vistas son mecanismos que
permiten representar las perspectivas de los
diferentes roles en un modelo arquitectónico [3].
La arquitectura se documenta y se presenta a los
participantes en la construcción del sistema para
que la evalúen. El modelo debe ser técnicamente
lógico, muy simple pero completo y mostrar a
cada uno de los involucrados las partes que le son
interesantes y necesarias.
La arquitectura de software simplifica la
complejidad de la construcción de los sistemas,
asegura la incorporación de los atributos
funcionales y no funcionales requeridos y
proporciona los elementos necesarios para su
diseño.
El modelo arquitectónico de referencia después de
ser aplicado en un sistema a través de una
arquitectura de software puede perfeccionarse
mediante un proceso de evaluación y ajustes, lo
que permitirá contar con un modelo que
evolucionará en forma continua, cada vez que se
aplica para la construcción de un nuevo sistema.
V. CASO DE ESTUDIO
Para ejemplificar la aplicación del método
propuesto, se mostrará como se pueden aplicar sus
pasos iniciales para conceptualizar la arquitectura
de referencia de modelos arquitectónicos que
resuelvan los dos problemas que se han planteado
en este documento.
Se requiere que un sistema que base su modelo
arquitectónico en la arquitectura de referencia que
se pretende crear transforme continuamente la
información producida por los sistemas
autónomos que integra. El nuevo sistema deberá
ser lo suficientemente modular y flexible para
permanecer funcionando mientras se realizan los
ajustes necesarios para añadir, sustituir o eliminar
los elementos funcionales que fallen o requieran
ser reemplazados.
Un sistema con las características descritas deberá
contemplar otros factores como por ejemplo:
• La información que proporcione el sistema
integral deberá ser congruente con la
proporcionada individualmente por las partes
funcionales que lo conforman, o al menos,
tener mecanismos de explicación que ayuden a
entender las diferencias que se encuentren.
• Coordinar coherentemente los mecanismos de
seguridad originales de cada uno de los
sistemas autónomos que integre.
No se cuenta con un modelo arquitectónico de
referencia eficiente para integrar sistemas
autónomos y bases de datos distribuidas que
cuenten con estructuras heterogéneas. Como
primera aproximación para generar esta
arquitectura de referencia se propone un modelo
que utiliza tres patrones arquitectónicos: corredor
(broker), capas (layers), y todo-partes (whole-part)
[2]. Estos patrones facilitan la estructuración de
los procesos mentales necesarios para
conceptualizar una solución a los problemas
propuestos anteriormente.
La integración de los sistemas es posible realizarla
aplicando el patrón de broker. El sistema
resultante contaría con una capa de servicios que
proporcionaría los mecanismos de integración
como intermediario entre los sistemas
preexistentes y el sistema integrado. Este patrón
proporciona una alta flexibilidad que permite
agregar o eliminar componentes con facilidad.
Figura 3.- Modelo arquitectural basado en un
patrón para la integración de software
Al aplicar el patrón broker se pueden ubicar varios
puntos de enlace que son críticos para realizar la
integración del sistema. En la figura 3 se señalan
con cuadros punteados diferentes tipos de
interfaces que resultan de interés: la de lectura
entre las bases de datos de los sistemas autónomos
y los mecanismos de integración; las de entrada y
las de salida entre los mecanismos de integración
y los sistemas autónomos; las que existen entre los
mecanismos de integración y entre los
mecanismos de integración y el sistema integrado.
Un punto de atención muy especial será el
mecanismo de interfase que permitirá que todos
los mecanismos de integración se unan y sean
percibidos como un solo sistema (el sistema
corredor).
El mecanismo que se utiliza para integrar varios
sistemas puede aplicarse a un sistema para
agregarle funcionalidad sin modificarlo,
resolviendo también el primer problema
planteado.
Adicionalmente, los requerimientos funcionales y
las características no funcionales de la arquitectura
se representarán mediante una estructura de capas;
el uso de este patrón permitirá que la arquitectura
sea modular, flexible y de sencilla comprensión.
En las capas inferiores del modelo prevalecerán
los aspectos relacionados con las características no
funcionales del sistema, conforme se avance hacia
capas superiores, los requerimientos funcionales
cobrarán mayor relevancia.
[2] Buschmann, F., Meunier, R., Rohnert, H.,
Sommerlad, P. y Stal M., “Pattern-Oriented Software
Architecture, A system of Patterns, Volume I”, Willey,
U.SA., 1996
[3] Clements, P., Kazman, R. y Klein, M., “Evaluating
Software Architectures, Methods and Case Studies,
Adison Wesley, U.S.A., 2002
[4] Garlan, D., Allen, R., Ockerbloom, J., “Exploiting
Style in Architectural Design Environments”, SIGSOF
94, ACM, 1994, pp. 175-188
[5] Liao, L., “From Requirements to Architecture: The
State of the Art in Software Architecture Design”,
Department of Computer Science and Engineering,
University of Washington, 2002, pp. 1-13
[6] O’Callaghan, A., “Migrating Large-Scale Legacy
Systems to Component-Based and Object Technology”,
Communications of AIS, Volume 2, Article 3, Julio
1999, pp. 1-40
[7] Pitoura, E., Bukhres, O., Elmagarmid, A., “Object
Orientation in Multidatabase Systems”, ACM
Computing Surveys, Vol. 27, No. 2, Junio 1995, pp.
141-195
[8] Malveau, R., Mowbray, T., “Software Architecture
Bootcamp, Second Edition”, Prentice Hall, U.S.A.,
2004

VI. CONCLUSIONES
En este documento se han tratado algunos
aspectos relativos a la creación de arquitecturas de
software y se ha propuesto un método para su
diseño. Así mismo, se ha propuesto la creación de
una arquitectura de referencia para crear nuevos
sistemas a partir de la integración de sistemas
autónomos preexistentes y bases de datos
heterogéneas. Esta arquitectura también podrá ser
utilizada para agregar funcionalidad a sistemas
heredados sin modificarlos.
Se vislumbra que la labor necesaria para crear la
arquitectura propuesta comprende aún una gran
cantidad de trabajo donde se destacan cuatro
grandes tareas, a saber:
• Afinar y validar el proceso propuesto para la
creación de modelos arquitectónicos.
• Definir las características funcionales
relevantes para los problemas que se han
planteado.
• Establecer un esquema con los mecanismos
para la evaluación de las características no
funcionales en la arquitectura de referencia.
• Concretar la propuesta del modelo de
arquitectura planteada y documentarlo.

VII. REFERENCIAS
[1] Bass L., Clements, P. y Kazman R., “Software
Architecture in Practice, Second Edition”, Adison
Wesley, U.S.A., 2003