UAA MSI

Metodologa de Anlisis y Diseo de Sistemas de Informacin

UNIVERSIDAD AUTONOMA
DE ASUNCIN

Maestra en Sistemas Informticos

Mdulo: Metodologa de Anlisis y Diseo de Sistemas de
Informacin

Profesor: Gonzalo Martn Puertas

TEMA: Presentacin y Crtica del Artculo

Discovering Architectures from Running Systems: Lessons
Learned
Nombres y Apellidos: Hugo Atilio Correa Edwards

Junio 2.005

UAA MSI

Metodologa de Anlisis y Diseo de Sistemas de Informacin

Universidad Autnoma de Asuncin

Maestra en Sistemas Informticos
Mdulo: Metodologa de Anlisis y Diseo de Sistemas de Informacin
Profesor: Gonzalo Martn Puertas
Hugo Atilio Correa Edwards
Telfono lnea fija: 021-670445.
Telfono celular: 0981-946292
e-mail: hcorrea@datamex.com.py, hcorrea@uaa.edu.py.

Presentacin y Crtica de Artculo

Discovering Architectures from Running Systems: Lessons Learned
Yan, Hong; Aldrich, Jonathan; Garlan, David; Kazman, Rick; Schmerl, Bradley
http://www.sei.cmu.edu/publications/documents/04.reports/04tr016.html
Software Engineering Institute (SEI)
Carnegie Mellon University (CMU)
CMU/SEI-2004-TR-016
Diciembre/2004
Publicado en Mayo/2005

1. Introduccin
Los autores del artculo presentado (Yan, Aldrich, Garlan, Kazman, Schmerl, 2004)
describen una tcnica que construye una vista arquitectnica de sistemas,
automticamente generada, a partir de observaciones realizadas sobre el mismo en tiempo
de ejecucin. Un desafo importante de los desarrolladores de software consiste en
garantizar que un sistema est construdo consistentemente en base a su diseo
arquitectnico (Arquitectura del Software). Nos definen a la Arquitectura del Software de
la siguiente manera:
Para la mayora de los sistemas complejos, es crucial tener una arquitectura
bien definida. Tal definicin provee una vista de alto nivel del sistema en
trminos de sus componentes de ejecucin principales (clientes, servidores, bases
de datos), sus interacciones (llamada a procedimientos remotos), y sus
propiedades. Como representacin abstracta de un sistema, una arquitectura
permite muchas formas de inspeccin y anlisis de alto nivel (Yan y
colaboradores, 2004).
Otras definiciones interesantes sobre Arquitectura del Software son las siguientes:
La Arquitectura Software de un programa o un sistema computacional es la
estructura o estructuras del sistema, el cual abarca los elementos del software,

UAA MSI

Metodologa de Anlisis y Diseo de Sistemas de Informacin

las propiedades externamente visibles de dichos elementos, y las relaciones entre

ellos (Bass, Clements, Kazman, 2003).
La Arquitectura est definida por las prcticas recomendadas como la
organizacin fundamental de un sistema, incorporado en sus componentes, sus
relaciones con otros componentes y el entorno, y los principios que gobiernan su
diseo y evolucin (ANSI/IEEE Std 1471-2000, Recommended Practice for
Architectural Description of Software-Intensive Systems).
Con el incremento del tamao y la complejidad de las implementaciones de los
Sistemas de Informacin, es necesario usar constructores lgicos (arquitectura)
para la definicin y el control de las interfaces y la integracin de todos los
componentes del sistema (Zachman, 1987).
El trabajo analizado presenta la implementacin de una herramienta denominada
DiscoTect que permite construir una Arquitectura de Sistemas abstracta en base a
eventos de bajo nivel ejecutados por el sistema. Adems se presentan dos casos de
estudio en los que se analizan sistemas del mundo real, y se visualizan las diferencias e
inconsistencias entre las implementaciones y las arquitecturas tericas de las mismas. Un
problema persistente es la falta de consistencia entre la Arquitectura de alto nivel definida
para un sistema y sus implementaciones, invalidando el trabajo y el esfuerzo de los
diseadores de dicha Arquitectura.
En la actualidad se aplican tres tcnicas para relacionar las Arquitecturas de Sistemas
con sus implementaciones, a saber:
a. La primera consiste en asegurar la consistencia entre ambos modelos en base a la
construccin del software. Esta tcnica se aplica de dos maneras: encajando
definiciones arquitectnicas mediante un lenguaje de implementacin o
generando cdigo de implementacin a partir de una definicin arquitectnica
abstracta. Estas tcnicas son aplicables cuando las herramientas utilizadas son las
mismas que las desarrolladas por los autores, por lo que no pueden analizar
sistemas existentes, ni aquellos construdos con enfoques diferentes a los
propuestos.
b. La segunda se fundamenta en la extraccin y construccin de la arquitectura a
partir del cdigo esttico de los sistemas. Esta tcnica es interesante cuando se
siguen patrones de modularizacin y de codificacin estndares. Sin embargo no
involucran comportamientos que se pueden observar en tiempo de ejecucin del
sistema, que son la esencia de la mayora de las descripciones arquitectnicas.
c. La tercera tcnica, menos explorada que las anteriores, permite determinar la
arquitectura del sistema examinando su comportamiento en tiempo de ejecucin.
La idea dominante es que el sistema puede ser supervisado mientras est
funcionando y las observaciones obtenidas sobre su comportamiento, se utilizan
para deducir su arquitectura dinmica. Presenta ventajas interesantes, tales como:

UAA MSI

Metodologa de Anlisis y Diseo de Sistemas de Informacin

En principio puede aplicarse a cualquier sistema que pueda ser monitoreado.

Permite obtener una imagen bastante aproximada de lo que se est ejecutando
actualmente en el sistema.
Se puede acomodar a sistemas cuya arquitectura cambia dinmicamente.
No impone restricciones sobre implementacin de sistemas o estilos de
arquitectura.

DiscoTect est basada en esta tcnica.

En el artculo original, se citan, adems, numerosos artculos relacionados con esta
tcnica y que sirven de base para el trabajo analizado.

2. Desafos Tcnicos
Cualquier tcnica que descubra dinmicamente la arquitectura de un sistema, debe
sortear los siguientes desafos:
a. Observar el comportamiento del sistema en ejecucin.
b. Expresar el comportamiento antes sealado, en trminos de eventos
arquitectnicamente significativos.
c. Representar la arquitectura de software resultante.
El trabajo analizado se enfoca en el segundo punto tratando de construir un puente
entre las observaciones del comportamiento del sistema y las acciones arquitectnicas de
generadas a partir de dichos comportamientos.
Algunos aspectos que dificultan la implementacin de este modelo son los siguientes:
a. El mapeo entre las observaciones de bajo nivel del sistema y la traduccin de los
mismos a eventos arquitectnicos significativos, no siempre es uno-a-uno.
Muchos eventos de bajo nivel son irrelevantes. Un evento arquitectnico
importante puede estar compuesto de varias actividades de bajo nivel en tiempo
de ejecucin. Y a la inversa un comportamiento de bajo nivel puede tener que
traducirse en varios eventos arquitectnicos. Este desafo implica que la tcnica
en cuestin no debe perder informacin sobre comportamientos intermedios.
b. Ciertas acciones relevantes desde el punto de vista arquitectnico se interpolan al
momento de la ejecucin del sistema, por lo que la tcnica debe ser capaz de
reconocer estados intermedios concurrentes del sistema.
c. No existen patrones estndar para indicar qu modelos de implementaciones
representan eventos arquitectnicos especficos. Diferentes implementaciones
pueden seleccionar diferentes tcnicas para la creacin de los mismos elementos
abstractos de la arquitectura. Tampoco se pueden utilizar los mismos patrones o
estilos arquitectnicos para todos los sistemas. Por lo tanto se requiere de

UAA MSI

Metodologa de Anlisis y Diseo de Sistemas de Informacin

flexibilidad en la manera de asociar diferentes estilos de implementacin con los

estilos arquitectnicos.
Para solucionar estos problemas, los autores proponen un modelo ilustrado en la
figura 1. El mismo se basa en un Motor de Trazado (Trace Engine) que hace un
monitoreo de los eventos del sistema y los filtra para seleccionar un subconjunto de
observaciones del sistema. La cadena de eventos filtrada alimenta a un Motor de Estado
(State Engine) que acta como una Mquina de Estados (State Machine) diseado para
reconocer patrones de eventos interpolados, y generar una serie de operaciones
arquitectnicas como salida. Estas operaciones alimentan, a su vez, a un Constructor de la
Arquitectura (Architecture Builder) que crea incrementalmente la arquitectura del
sistema, que puede ser visualizada o procesada por herramientas de anlisis.

Figura 1: La Arquitectura de DiscoTect

En cuanto a la Mquina de Estados (State Machine) de DiscoTect, el mismo consiste
en un grafo de estados, disparadores, acciones y transiciones de los eventos, interpretados
por el State Engine. En la figura 2 se puede distinguir a los elementos de la mquina de
estados.
Los estados permiten hacer el seguimiento en el proceso de descubrimiento de la
arquitectura. Cada estado es un punto en el descubrimiento de alguna accin
arquitectnica y por ende puede representar un conocimiento parcial de dicha accin.
Ellos estn asociados a uno o ms disparadores (triggers) que a su vez definen los tipos
de eventos que pueden generar transiciones entre los estados y las condiciones bajo las
cuales se producen estas transiciones. Los triggers tienen dos partes: 1) la especificacin
del evento y 2) la definicin de las condiciones por las cuales los eventos generan
cambios o transiciones entre los estados. El modelo incorpora tres tipos de eventos
identificables por los disparadores: Init (instanciacin de objetos); Call (llamada a
mtodos) y Modify (cambios en atributos de los eventos). Cuando las transiciones
determinan el estado final del evento, el mismo se convierte en una accin arquitectnica,
pasando el mismo al Constructor de la Arquitectura (Architecture Builder).
5

UAA MSI

Metodologa de Anlisis y Diseo de Sistemas de Informacin

Figura 2. Elementos de la Mquina de Estados

3. Implementacin de DiscoTect
DiscoTect resuelve los tres problemas planteadas en la seccin de Desafos Tcnicos
de la siguiente manera:
a. Observar el comportamiento del sistema en ejecucin (Monitoreo o
Monitoring): El Trace Engine resuelve este problema. El mismo utiliza el JPDA
(Java Platform Debugger Architecture) que permite capturar eventos del sistema
en ejecucin. Esto lo puede hacer ya que el JPDA provee un canal de
comunicacin entre el depurador y el sistema objeto de estudio. El depurador
puede enviar requisitorias al sistema en ejecucin preguntando por ciertos tipos de
eventos. El Trace Engine acta en el rol del depurador enviando requisitorias al
sistema preguntando por tres tipos de eventos principales: instanciaciones de
objetos; llamadas a mtodos; y modificaciones de atributos de objetos. Cuando el
Trace Engine detecta y recibe un evento en tiempo de ejecucin lo clasifica como
eventos Init, Call o Modify y los pone en la pila para ser procesados por el State
Machine
b. Expresar el comportamiento antes sealado, en trminos de eventos
arquitectnicamente significativos (Mapeo o Mapping): este problema es
resuelto por el State Engine que primero inicializa el estado de los eventos
activndolos, luego controla y recibe los eventos enviados por el Trace Engine y
cuando detecta cambios en los estados de ejecucin de los mismos, se
desencadenan las acciones arquitectnicas asociadas a los eventos.
c. Representar la arquitectura de software resultante (Construccin de la
Arquitectura o Architecture Building). Se utiliza el lenguaje de descripcin de
arquitecturas ACME (Garlan, Monroe, Wile, 2000).

UAA MSI

Metodologa de Anlisis y Diseo de Sistemas de Informacin

4. Casos de Estudio
Se presentan dos casos de estudio para ilustrar como trabaja DiscoTect y como puede
ser aplicado a sistemas del mundo real.
a. Caso de Estudio de Adaptive Architectures for Mobile Systems (AAMS)
AAMS es un programa de simulacin para experimentar con decisiones de diseo
arquitectnico de sistemas mviles (Kazman, Asundi, Kim, Sethananda, 2003).
Permite definir recursos del sistema, tareas, estrategias de tiempo y simular la
ejecucin del sistema mvil. Se eligi esta herramienta por la cantidad de lneas
de cdigo del mismo (25 KLOC o miles de lneas de cdigo) y la arquitectura del
sistema est bien documentada. La arquitectura generada por DiscoTect tiene
varias discrepancias con el modelo original, tales como: aislados y extraos
componentes y conectores; conexiones adicionales entre componentes; un
esquema de I/O de archivos diferente; y componentes y conectores no
encontrados. Al analizar los resultados de DiscoTect, los autores de AAMS
afirmaron que este modelo era mejor que el original.
b. Caso de Estudio de EJB (Enterprise Java Beans)
Este caso de estudio permiti determinar la arquitectura de una aplicacin
denominada Dukes Bank Application, una aplicacin muy simple creada por Sun
Microsystems con Enterprise Java Beans (EJB) como demostracin de las
funcionalidades de este producto. Esta aplicacin permite a los clientes de un
banco, acceder a informacin de sus cuentas y hacer transferencias entre ellas.
Tiene adems una interface para administrar cuentas y clientes. Esta aplicacin
est convenientemente documentada en el tutorial de J2EE (Java2 Platform
Enterprise Edition) (Sun, 2004) que permite comparar la arquitectura
documentada con la descubierta por DiscoTect.

5. Conclusiones y Comentarios
Los autores proponen un modelo para descubrir la arquitectura de sistemas a partir de
la ejecucin del mismo que permite comparar las discrepancias entre el modelo
arquitectnico propuesto incialmente y el generado por DiscoTect. Al detectar las
discrepancias, se pueden realizar las modificaciones en los modelos de manera a lograr la
consistencia deseada entre ellos. En principio se puede evaluar cualquier sistema en
ejecucin. En el proyecto, los autores han hecho pruebas, utilizando Java, sobre sistemas
en ejecucin presentadas en los casos de estudio con resultados positivos, y han
agregado experiencias en lenguajes C y C++. Otro aspecto importante se refiere a que
haciendo cambios en el mapeo de los eventos en la Mquina de Estados se pueden ajustar
distintas convenciones o modelos de implementacin a diferentes modelos o estilos
arquitectnicos.

UAA MSI

Metodologa de Anlisis y Diseo de Sistemas de Informacin

Esta tcnica mejora otras perspectivas en las que se construye el modelo

arquitectnico a partir del cdigo esttico de la aplicacin, sin analizar el comportamiento
del sistema en tiempo de ejecucin, y de otras tcnicas basadas en la generacin de
cdigo a partir de la arquitectura abstracta del sistema con lo que eventuales cambios en
el cdigo generado no se reflejan en el modelo arquitectnico, generando discrepancias
entre ambos.
Los autores han detectado una serie de debilidades de la tcnica propuesta, tales
como: 1) la necesidad de que el sistema est codificado siguiendo estndares y
convenciones, es decir, no puede trabajar con aquellos sistemas construdos con cdigo
basado en la experiencia y sin estndares, 2) slo trabaja con estilos arquitectnicos
identificados, por lo que el mapeo construdo en el State Engine debe conocer el
vocabulario utilizado en el modelo arquitectnico de referencia; 3) al analizar
observaciones y comportamientos en tiempo de ejecucin slo se puede analizar lo que se
est ejecutando actualmente; y 4) hay una dependencia importante de la experiencia del
usuario que prepara los modelos y motores de reconocimiento de comportamientos.
A esto se debe agregar que para generar una arquitectura fiable, se debe ejecutar el
sistema en su totalidad y con todas sus funcionalidades. Adems el State Machine slo
puede procesar eventos que instancian objetos, ejecutan mtodos y modifican atributos de
objetos, faltando otros tipos de eventos como destruccin de objetos. Finalmente la
herramienta est muy orientada a aplicaciones basadas en Objetos, por lo que se ve difcil
de implementar en sistemas basados en otros paradigmas.

6. Referencias
Aldrich, J., Chambers, C., Notkin, D. (2002). ArchJava: Connecting Software
Architecture to Implementation, 187-197. Proceedings of the International
Conference on Software Engineering. Orlando, FL, May 19-25, 2002. New York,
NY: Association for Computing Machinery, 2002.
ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of
Software-Intensive Systems.
Bass, L., Clements, P., Kazman, R. (2003). Software Architecture in Practice 2/E.
Addison-Wesley Professional.
Garlan, D., Monroe, R. T., Wile, D. (2000). Acme: Architectural Description of
Component-Based Systems, 47-68. Foundations of Component-Based Systems
(Edited by Gary T. Leavens & Murali Sitaraman). New York, NY: Cambridge
University Press.
Kazman, R., Asundi, J., Kim, J. S., Sethananda, B. (2003). A Simulation Testbed for
Mobile Adaptive Architectures. Computer Standards and Interfaces 25, 3 (June
2003): 291-298.

UAA MSI

Sun

Metodologa de Anlisis y Diseo de Sistemas de Informacin

Microsystems, Inc. (2004). The J2EE Tutorial,

http://java.sun.com/docs/books/j2eetutorial/index.html

Second

Edition.

Yan, H., Aldrich, J., Garlan, D., Kazman, R., Schmerl, B. (2004). Discovering
Architectures from Running Systems: Lessons Learned. Descargado en Junio 15,
2005, de Carnegie Mellon University, Software Engineering Institute. Sitio Web:
http://www.sei.cmu.edu/publications/documents/04.reports/04tr016.html
Zachman, J.A. (1987). A framework for information systems architecture. IBM Systems
Journal, 26, 3, Reprint (1999), Vol.38, Nos.2-3, 454-454. Descargado en Junio 15,
2005, de http://www.research.ibm.com/journal/sj/382/zachman.pdf.