ATAM-AR: ATAM-Based Recovery Architecture

Method
ATAM-AR: Un método de
Recuperación de Arquitecturas basado en ATAM

Edwar Alejandro Giraldo Muñoz Yuli Andrea Ordoñez Guzman Julio Ariel Hurtado Alegria
IDIS Research Group, IDIS Research IDIS Research Group, IDIS Research IDIS Research Group, IDIS Research
Incubator in Software Incubator in Software Incubator in Software
Universidad Del Cauca Universidad Del Cauca Universidad Del Cauca
Colombia Colombia Colombia
egiraldo@unicauca.edu.co yuordonez@unicauca.edu.co ahurtado@unicauca.edu.co

Abstract—Software architectures are considered one of the
main assets within the software companies. However, within
organizations, do not usually have adequate descriptive solution.
With the aim of having that description has emerged an activity
of recovering a software architecture whose main approaches are
pointed out to a recovering model from the implemented
information and the spreading, particularly the source code, tacit
knowledge present in the development team. In this work it is
shown as a method of evaluating architectures allows recovery
from the tacit knowledge of equipment, allowing not only regain
his description but its intention. To evaluate the proposal, it has
developed a case study where the ATAM method is used to
evaluate and recover the architecture of a file synchronization
system in the context of different virtual learning platforms. The
case has allowed showing how manages to get the descriptive
architecture including its rationale.
Keywords—ATAM; Architecture Evaluation; Reverse
Engineering; Recovery Architecture
Resumen— Las arquitecturas de software son consideradas
uno de los principales activos dentro de las empresas de software.
Sin embargo, dentro de las organizaciones, no se cuenta
generalmente con una solución descriptiva adecuada. Con el
ánimo de contar con dicha descripción ha emergido la actividad
de recuperar una arquitectura de software, cuyos principales
enfoques se orientan a la recuperación de modelos a partir de la
información de implementación y de despliegue, particularmente
el código fuente y no en el conocimiento tácito presente en el
equipo de desarrollo. En este trabajo se muestra como, un
método de evaluación de arquitecturas permite su recuperación a
partir del conocimiento tácito del equipo, permitiendo no sólo
recuperar su descripción sino su intención. Para evaluar la
propuesta, se ha desarrollado un estudio de caso donde el método
ATAM es usado para evaluar y recuperar la arquitectura de un
sistema de sincronización de archivos en el contexto de diferentes
plataformas virtuales de aprendizaje. El caso ha permitido
mostrar cómo se logra recuperar la arquitectura descriptiva
incluyendo su rationale.
Índice de Términos— ATAM; Evaluación de Arquitecturas;
Ingeniería Inversa; Recuperación de Arquitecturas
I. INTRODUCCIÓN
La arquitectura software se ha convertido en un factor de
vital importancia para ayudar a las empresas de software a
desarrollar productos de software de ciclos de vida más largos
que les permitan posicionarse, mantenerse y expandirse en el
mercado. La arquitectura software de un sistema
computacional es definida como una estructura o un conjunto
de estructuras que describen e implementan ese sistema, las
cuales se expresan por medio de componentes de software, las
propiedades externamente visibles de estos componentes, y sus
relaciones [6]. El conocimiento sobre la arquitectura de un
sistema ayuda a los desarrolladores a identificar y localizar las
partes del sistema que deben ser modificadas durante su
evolución y mantención, así como las demás partes del sistema
que se verán afectadas por dichos cambios[1].
A medida que un sistema software evoluciona, su
arquitectura puede requerir ajustes, de manera que ésta se
degrada sino se considera su documentación, su coherencia con

978-1-4673-9461-1/15/$31.00 © 2015 IEEE

 1
su implementación y en especial su rationale [2]. Esta II. TRABAJOS RELACIONADOS
degradación puede conducir a la erosión de la arquitectura, la La evaluación de arquitecturas es una actividad que puede
que la hace propensa a errores en los siguientes incrementos de ser útil por diversas razones, por ejemplo para tomar mejores
desarrollo y mantenimiento, lo cual contribuye al rápido decisiones, es decir frente a una arquitectura que me está dando
envejecimiento del software[3]. Por lo anterior, se considera problemas, la evaluación me puede ayudar a decidir si
que la arquitectura software es parte fundamental en la conviene invertir en mejorarla o solucionar sus problemas o si
evolución de los sistemas software [4], por lo que su es mejor cambiarla y empezar de nuevo.
recuperación es una la necesidad de gran importancia cuando
esta no se encuentra definida en forma explícita o hay Koschke [15], define un framework llamado Symphony,
2
divergencia entre la arquitectura prescriptiva y la arquitectura para la reconstrucción de la arquitectura donde se realiza una
3 combinación de patrones comunes y hace uso de las mejores
descriptiva [5]. Recuperación de arquitecturas es un área de la prácticas reportadas en la literatura de la ingeniería inversa,
ingeniería inversa la cual se entiende como el proceso de generando vistas y puntos de vista, donde se describe la
analizar un sistema para crear representaciones del sistema en arquitectura según la perspectiva de los diferentes interesados.
un nivel de abstracción más alto [10]. Bellay y Gall [16] se presenta un enfoque para realizar la
La ingeniería inversa está empezando a ser valorada como recuperación y descripción de la arquitectura de un sistema por
un proceso importante en el ciclo de vida de los sistemas, pero medio de métodos y herramientas, donde involucra diferentes
todavía se presentan muchas problemáticas debido a que es un aspectos que son recuperados y luego descritos. Se centra en
área relativamente joven y debido a la gran variedad de diversas propiedades como la seguridad, la varianza y su
sistemas que podemos encontrar, causado por la gran cantidad descripción, pero no en la recuperación de la arquitectura de un
de lenguajes que hay. Muchas veces dentro del proceso de sistema completo. Estos trabajos son muy representativos por
ingeniería inversa se presentan dificultades para la extracción y capacidad del método y las herramientas para recuperar varias
visualización de la información que es necesaria en este vistas para los diferentes interesados, sin embargo la
proceso, como también saber elegir cual es la información participación de éstos no es aprovechada para recuperar las
relevante para realizar el proceso de ingeniera inversa de un decisiones tomadas y su ratinale.
sistema. A veces es necesario realizar un análisis dinámico del Existen diversos métodos que ayudan a evaluar una
sistema o en ciertas ocasiones nos encontramos con distintos arquitectura, entre ellos están: SAAM y ATAM[8]. El foco de
tipos de sistemas como los orientados a servicios de los cuales SAAM (Software Architecture Analysis Method) es la
no tenemos acceso a los códigos fuente por lo que debemos modificabilidad, para ello el método utiliza el agrupamiento de
hacer un análisis de caja negra. Uno de los grandes retos que se escenarios como criterio para evaluar la arquitectura. Sin
presentan en la ingeniería inversa es la representación de la embargo, existen otros métodos como ATAM (Architecture
información, por lo que se necesita de la creación de vistas que Trade-off Analysis Method) que exploran el balance entre
son extraídas de los datos recolectados. Y por último el reto diferentes aspectos que influencian el diseño arquitectónico
más grande de la ingeniería inversa es la automatización de los [8]. La Tabla 1 describe en forma diferencial los métodos
métodos, donde se incluya el conocimiento de expertos para SAAM de ATAM.
que los métodos puedan realizar evaluaciones y que puedan
producir resultados mejores. En esta propuesta se muestra
cómo los métodos de evaluación de arquitecturas pueden ser TABLA I. MODELO DE EVALUACIÓN DE ARQUITECTURA
SOFTWARE [9].
usados para lograr su recuperación.
Aspecto SAAM ATAM
Este artículo está organizado de la siguiente forma. La
sección II presenta los conceptos relacionados con métodos de Técnica de Escenarios Escenarios y técnicas de
Evaluación preguntas y medición
evaluación de arquitecturas y las diferentes experiencias de uso
Atributos de Modificabilidad Múltiples atributos de Calidad
en la recuperación de arquitecturas, en la sección III
Calidad
presentamos una propuesta de recuperación de arquitecturas
Fase del diseño En la En la verificación de la
usando ATAM, en la sección IV se realiza una evaluación de la de Arquitectura verificación de la Arquitectura de Software(En
propuesta en un estudio de caso donde la arquitectura de un de Software Arquitectura de forma iterativa)
sistema de sincronización por demanda de archivos asociados a Software
actividades de usuarios en plataformas de aprendizaje en línea Evaluación de Basado en Basado en Relaciones
es analizada y recuperada y la sección V presenta las Impacto de los Relaciones
conclusiones. escenarios
Reusabilidad del No considerado Un conjunto de pre paquetes de
conocimiento análisis y preguntas con
1
Rationale- la inclusión explícita de las decisiones tomadas durante el conocimientos de la solución
proceso de diseño y las razones por las cuales esas decisiones fueron tomadas.
2
Decisiones tomadas respecto a la arquitectura
3
Decisiones explícitamente descritas en el documento de la arquitectura

978-1-4673-9461-1/15/$31.00 © 2015 IEEE

 El método ATAM evalúa con más profundidad, en relación III. ATAM -BASED ARQUITECTURE RECOVERING –
con otros métodos, preguntas referentes a la arquitectura, ATAM-AR
correspondientes a varios atributos de calidad. ATAM está
Mientras que en SAAM la generación de escenarios está
conformado por un conjunto de pasos importantes como se
basada en la visión de los interesados, no provee una métrica
muestra en la Figura 1: presentación de ATAM, presentación
clara sobre la calidad de la arquitectura evaluada y se centra en
de los Objetivos de Negocio, Presentación de la Arquitectura,
el atributo de modificabilidad. ATAM obtiene su nombre no
Investigación y Análisis, identificación de las aproximaciones
solo porque nos dice que tanto una arquitectura particular
arquitecturales, la generación del árbol de atributos de utilidad,
satisface varias metas de calidad, sino que también provee
el análisis de las aproximaciones arquitecturales, Testing,
ideas de cómo esas metas de calidad interactúan entre ellas,
lluvia de ideas y priorización de escenarios, Presentación de
como realizan negociaciones mutuas (tradeoff) entre ellas,
Resultados [7].
permitiendo describir la forma en la que el sistema puede
El método llamado MAP (minería de arquitecturas para crecer, responder a cambios, satisfacer restricciones e
líneas de producto), tiene un enfoque que se basa en el mapeo integrarse con otros sistemas entre otros.
de estilos arquitectónicos y atributos que se relacionan con la
minería de la arquitectura, donde se combinan la
reconstrucción de la arquitectura y el análisis de técnicas de Esta propuesta explora la recuperación de un sistema
líneas de productos. El método se analiza teniendo en cuenta software basándose y adaptando el método de evaluación de
una descripción general del MAP, la preparación, Extracción, arquitecturas ATAM [6]. A continuación se describen las
la composición, calificación, y la finalización, si la vista tareas, los roles y los artefactos.
arquitectónica después de haber realizado la evolución no es
factible se procede a hacer un análisis con ATAM. También se A. Tareas: esta evaluación sigue las siguientes tareas:
muestra un caso de estudio donde se hace el análisis usando el
método MAP en varios sistemas en la industria automotriz,
1) Presentación: El objetivo de este paso es contextualizar
dando lugar a mejoras en la extracción donde se identifican
elementos y relaciones que ayudan a mejorar el MAP [11]. a los involucrados con el sistema al cual se le va a recuperar la
arquitectura, este paso tiene los siguientes pasos:

• Presentación del método: se realiza la presentación del

método ATAM-AR.
• Presentación de la arquitectura: se presenta la
arquitectura prescriptiva5 del sistema, y de los activos
que describen al sistema al cual se desea realizar la
recuperación de su arquitectura. Estos activos pueden
ser el código fuente del sistema, los diseños del sistema,
manuales técnicos, casos de prueba, entre otros.
2) Investigación y análisis: El objetivo de este paso es el
análisis del sistema, la identificación de escenarios, puntos de
negociación, puntos de riesgo y no riesgo. Este paso está
conformado por los siguientes pasos:
Fig. 1. Flujo conceptual del método ATAM adaptado [8]

• Generación de escenarios: En este paso el equipo que

Vasconcelos y Werner [12] presentan un enfoque de están participando en la de la recuperación generan
recuperación y evaluación de arquitectura para la reutilización diferentes escenarios en los que se pueden evaluar los
4 atributos relevantes del sistema.
soportado por la herramienta ArchMine , la cual permite
extraer el conocimiento basado en la inspección de sistemas • Generar árbol de utilidad de atributos de calidad: Se
existentes. Dicho conocimiento es expresado en un modelo genera el árbol de utilidad de los atributos de calidad
arquitectónico conceptual con información de trazabilidad que comprometen la utilidad del sistema de acuerdo a
hacia las funcionalidades implementadas, ayudando a generar los escenarios, este árbol es generado a partir de la lista
artefactos reutilizables. de escenarios, se asocian a un atributo de calidad y se

4 5
un enfoque de recuperación de la arquitectura basada en el análisis Decisiones tomadas respecto a la arquitectura
dinámico y la minería de dato

978-1-4673-9461-1/15/$31.00 © 2015 IEEE

 priorizan con respecto a dos criterios: la importancia y
la dificultad de implementación.
3) Refinamiento y análisis de escenarios: los escenarios
priorizados son analizados dependiendo, identificando y
analizando las propuestas arquitectónicas bajo el escenario de
análisis, donde se identificaran los riesgos arquitectónicos, los
no riesgos, los puntos sensitivos, puntos de negociación, el
rationale y las vistas relevantes.
4) Verificación: Este paso tiene como objetivo el validar
el análisis hecho en el paso anterior y completar el análisis del
sistema, esto se hace con los siguientes pasos:
• Lluvia de ideas: se generan nuevos escenarios con el
objetivo de completar el árbol de utilidad de atributos
de calidad.
• En caso que se identifiquen nuevos escenarios, estos
son analizados. Los pasos Generar árbol de utilidad de
atributos de calidad y Refinamiento y análisis de
escenarios pueden repetirse hasta que se considere que
no hay más escenarios nuevos que analizar.
5) Presentación de Resultados: Basados en la información
recogida (escenarios, árbol de utilidad, riesgos, no riesgos,
puntos sensitivos y puntos de negociación), se presenta los
resultados.
B. Roles
• Equipo de Recuperación: Son los encargados de llevar
y controlar la recuperación de la arquitectura del
sistema.
• Equipo de Desarrollo: Este rol puede ser tomado por
quienes desarrollaron el sistema bajo recuperación o
pueden ser el equipo encargado de realizar operaciones
mantención, evolución o integración.
• Equipo de Arquitectura: Son los encargados de
construir la arquitectura del sistema.
• Equipo de Interesados: Son los distintos roles
relevantes para la toma de decisiones arquitecturales.
Cada uno de los roles tiene unas actividades de las cuales
tiene que hacerse responsable de su ejecución, en la Tabla 2 se
puede ver los responsables de cada actividad.
C. Artefactos
• Arquitectura: Este corresponde a los activos que se
pueda tener que describa la arquitectura del sistema, los
cuales pueden ser: código fuente del sistema, los
978-1-4673-9461-1/15/$31.00 © 2015 IEEE
diseños del sistema, manuales técnico, casos de prueba,
entre otros:
• Lista de Escenarios: Este artefacto comprende una lista
de escenarios que describan el comportamiento que
debe tener el sistema frente a determinadas situaciones.
• Árbol de utilidad de atributos de calidad: Este permite
realizar una relación de los escenarios con los atributos
de calidad además que se realiza un priorización de
estos con respecto a dos criterios, la importancia del
escenario en el sistema y la dificultad de su
implementación.
TABLA II. RELACIÓN DE ACTIVIDADES Y ROLES
Actividad Roles
1 Presentar la ATAM Equipo de Recuperación
2 Presentar Arquitectura Equipo de Desarrollador o Equipo de
Actual Arquitecta
3 Generar Escenarios Equipo de Recuperación y Equipo de
Desarrollador o Equipo de Arquitecta
4 Generar Árbol de utilidad Equipo de Recuperación y Equipo de
de atributos de calidad Desarrollador o Equipo de Arquitecta
Análisis de árbol de Equipo de Recuperación Evaluación y
5
utilidad: Equipo de Desarrollador o Equipo de
Arquitecta
6 Lluvia de Ideas Equipo de Recuperación y Equipo de
Desarrollador o Equipo de Arquitecta
7 Presentación de Equipo de Recuperación
Resultados
• Descripción de Escenario: Cada escenario debe tener
una descripción detallada donde se especifica el
estímulo que generar el escenario, la respuesta que debe
tener el sistema, además de las diferentes decisiones
arquitecturales de se identifican para que el sistema
cumpla con el escenario, a cada una de estas decisiones
se debe identificar los puntos sensibles, los puntos de
negociación y los riesgos, y por último se incluye el
rationale y una vista donde se identifican los
componentes del sistema que atacan el escenario
planteado.
• Resultados: Los resultados comprenden todos los
artefactos anteriormente mencionados y un documento
donde el equipo de evaluación incluye todas las
apreciaciones que tiene sobre la arquitectura del
sistema.
IV. APLICACIÓN DE ATAM-AR: EL CASO DEL SISTEMA E-
LEARNINGSYNC
Esta es una propuesta de arquitectura con el objetivo de
soportar la sincronización por demanda de archivos asociados a
actividades de usuarios en plataformas de aprendizaje en línea,
como parte del trabajo de fin de carrera de Zambrano y
Chagüendo[13]. El método ATAM-AR fue aplicado a esta
propuesta arquitectónica para ver los resultados que se pueden
obtener, en la cual participaron los diseñadores de la
arquitectura quienes tomaron los roles del equipo de
arquitectura, equipo desarrollador y grupo de interesados,
Siguiendo la primera tarea se realizó la presentación del
método y la presentación de la arquitectura propuesta la cual se
puede ver en la figura 2.
Para este caso no se realizaron más refinamientos, por lo
que se procedió a analizar resultados y a su reporte, en la que
se determina que la arquitectura está preparada
significativamente para la interoperabilidad, pero que se
depende de las librerías de acceso a los servicios de cada
plataforma de aprendizaje en línea.

TABLA IV. ANALISIS ESCENARIO INTEGRACION

PLATAFORMAS DE E-LEARNING
Descripción del Mejorar la inter-operabilidad6 del mecanismo con
Escenario las plataformas de aprendizaje en línea de tal manera
que sea posible detectar la creación y actualización
de recursos dentro de un curso e informar al servidor
de sincronización para que este actualice los
cambios si es necesario hacia los usuarios.
Atributo Integrabilidad/Inter-Operabilidad

Estimulo Lograr que los recursos creados desde las

plataformas de aprendizaje puedan ser compartidos
hacia los usuarios del mecanismo
Respuesta Para lograr esto se requiere:
3.5 personas/ mes para realizar las implementaciones
Fig. 2. Arquitectura E-LearningSync, tomado de [13] propias para una nueva plataforma (El servidor de
sincronización no será modificado)
Decisiones Puntos Trade Off Riesgos
En la tarea Investigación y Análisis, se generaron los Arquitecturales Sensibles
escenarios y se priorizaron, en la Tabla 3 se puede ver el árbol
Abstraer Servidor Web Portabilidad Ninguno
de utilidad de atributos de calidad que fue generado a partir de Servicios Web ElearningSync relevante
estos dos pasos. En el paso Generar árbol de utilidad de con el protocolo
atributos de calidad de la tarea de Investigación y Análisis se Rest
analizó el escenario más relevante de los escenarios generados Abstraer Servidor Web Portabilidad Algunas
(importancia y complejidad de desarrollo), el cual corresponde Servicios para en la plataformas
con la integración de nuevas plataformas de E-Learning, cada plataforma pueden
plataforma de restringir por
debido que el principal compromiso del mecanismo fue la aprendizaje en seguridad la
integración con distintas plataformas de aprendizaje en línea. línea realización de
El resultado es presentado en la Tabla 4. algunas
acciones por
medio de
TABLA III. ARBOL DE UTILIDAD DE ATRIBUTOS DE CALIDAD servidores
web
Atributo de Escenario Prio-
Calidad ridad La Conexión Disponibilidad Posibles
comunicación pérdidas de
entre información
E- Escala- Almacenamiento (H, M)
componentes
Learning bilidad
Crecimiento de usuarios (H, L) está enfocada en
Sync
conexiones
Integrabi- Integración de nuevas (H, H) cliente /
lidad plataformas de E-Learning servidor ó P2P
Modifica- Evolución del Servidor de (H,H) Rationale Transparencia en el uso de las plataformas, dado que
bilidad aplicaciones si el docente usa el mecanismo, los recursos pueden
verse desde la plataforma como si hubiese sido
Tiempos de respuesta (H, L) creados desde ella misma.
Desempe- Fallos en el proceso de (H, H) Inter-operabilidad con distintas plataformas
ño resolución de conflictos Vista de
Confiabi- Fallos en el servidor de (H, L) componentes En la Figura 3 se presenta una vista de tipo
lidad aplicaciones del sistema componentes y conectores que incluye los servicios
Fallos en el servidor de (H, L) web, la plataforma de aprendizaje en línea y las
Almacenamiento conexiones que siguen el estilo arquitectónico
cliente servidor.

6
la habilidad de los sistemas para trabajar juntos, en general gracias a la
adopción de estándares.

978-1-4673-9461-1/15/$31.00 © 2015 IEEE

 El esfuerzo dedicado a la ejecución del estudio de caso con
ATAM-AR fue de 34 horas-persona con un equipo asesor de 3
personas, un experto y dos aprendices, y 2 personas de las
interesadas en la arquitectura (gerencia y desarrollo). El tiempo
invertido fue de 3 días incluyendo preparación (motivación y
presentación del método), ejecución (incluyendo el modelado
de la vista recuperada) y recolección de información del caso.
V. CONCLUSIONES, LIMITACIONES Y TRABAJOS
FUTUROS
A través de los resultados de la aplicación de ATAM-AR
en un caso de recuperación de un modelo arquitectónico se
puede concluir que las decisiones que se toman al momento de
definir una arquitectura de un sistema proveen información
relevante para su entendimiento y recuperación, por lo que
considerar los interesados que han participado en el desarrollo
de la arquitectura es clave. Por ello la inclusión de los
desarrolladores o arquitectos que estuvieron a cargo del
desarrollo del sistema, fue en este caso una decisión clave para
obtener el rationale de una arquitectura.
Fig. 3. Vista de Componentes del sistema
Es importante rescatar el valor de la definición de
escenarios como un mecanismo útil para la concentración de
esfuerzos de análisis al momento de recuperar una arquitectura,
de tal forma que el equipo pueda trabajar cohesivamente
alrededor de una parte del problema.
La principal limitante de la recuperación aquí presentada
está relacionada al no recuperar las vistas arquitecturales desde
los artefactos del sistema (por ejemplo el código) en forma
automatizada, aunque se quería presentar la recuperación de la
arquitectura desde el conocimiento de los arquitectos, no hubo
información concreta sobre la vista arquitectónica más allá de
un modelo de despliegue como el presentado en la Figura 2 y
el modelo relacional.
Como trabajo futuro y teniendo en cuenta este antecedente
que se prevee será recurrente, el método será complementado
978-1-4673-9461-1/15/$31.00 © 2015 IEEE
con un enfoque de recuperación basado en la visualización de
software [14]. Para ello actualmente estamos evaluando la
herramienta Softwarenaut, con la cual se espera que la
visualización exploratoria e interactiva que esta herramienta
provee [2][14] complemente el paso 2.c de nuestra propuesta
en la que se debe poner en contexto de un modelo los
escenarios priorizados, y para lo que se requiere presentar las
vistas arquitectónicas relevantes, los patrones usados y el
rationale.
AGRADECIMIENTOS
Este trabajo ha sido realizado en el marco del Proyecto
Colciencias Semillero de Investigación, CONVENIO
ESPECIAL DE COOPERACION NO. 708 DE 2013
SUSCRITO ENTRE LA FIDUCIARIA BOGOTA Y LA
UNIVERSIDAD DEL CAUCA. Para el desarrollo del estudio
de caso este trabajo agradece el apoyo recibido por los
ingenieros Iván Zambrano y Juan Manuel Chagüendo.
REFERENCIAS
[1] I. Hogganvik, E. Molstad, and S. Fordypningsemne, “INCO- Open
Source Architecture Recovery.” 2002.
[2] M. Lungu, M. Lanza, and O. Nierstrasz, "Evolutionary nd collaborative
software architecture recovery with Softwarenaut," Science of Computer
Programming, vol. 79, pp. 204-223, 2014.
[3] J. B. Tran, M. W. Godfrey, E. H. S. Lee, and R. C. Holt, “Architectural
repair of open source software,” in Program Comprehension, 2000.
Proceedings. IWPC 2000. 8th International Workshop on, 2000, pp. 48–
59.
[4] O. Maqbool and H. A. Babri, “Hierarchical Clustering for Software
Architecture Recovery,” Softw. Eng. IEEE Trans., vol. 33, no. 11, pp.
759–780, Nov. 2007
[5] C.-H. Lung, “Software Architecture Recovery and Restructuring
Through Clustering Techniques,” in Proceedings of the Third
International Workshop on Software Architecture, 1998, pp. 101–104.
[6] R. Kazman, M. Klein, M. Barbacci, T. Longstaff, H. Lipson, and J.
Carriere, “The architecture tradeoff analysis method,” in Engineering of
Complex Computer Systems, 1998. ICECCS ’98. Proceedings. Fourth
IEEE International Conference on, 1998, pp. 68–78.
[7] Kazman. Rick, Klein. Mark, and Clements. Paul, "ATAM: Method for
Architecture Evaluation," Software Engineering Institute, Carnegie
Mellon University, Pittsburgh, Pennsylvania, Technical Report
CMU/SEI-2000-TR-004, 2000.
http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=5177
[8] P. Clements, R. Kazman, and M. Klein, Evaluating Software
Architectures: Methods and Case Studies. Addison-Wesley
Professional, 2001.
[9] L. Dobrica and E. Niemela, “A survey on software architecture analysis
methods,” Softw. Eng. IEEE Trans., vol. 28, no. 7, pp. 638–653, Jul.
2002.
[10] E. J. Chikofsky and I. I. Cross J.H., “Reverse engineering and design
recovery: a taxonomy,” Software, IEEE, vol. 7, no. 1, pp. 13–17, 1990.
[11] C. Stoermer and L. O’Brien, “MAP - mining architectures for product
line evaluations,” in Software Architecture, 2001. Proceedings. Working
IEEE/IFIP Conference on, 2001, pp. 35–44.
[12] A. Vasconcelos and C. Werner, “Architecture Recovery and Evaluation
Aiming at Program Understanding and Reuse,” in Software
Architectures, Components, and Applications SE - 5, vol. 4880, S.
 Overhage, C. Szyperski, R. Reussner, and J. Stafford, Eds. Springer
Berlin Heidelberg, 2007, pp. 72–89.
[13] C. Zambrano and J. M. Chagüendo, “Sincronización Por Demanda De
Archivos Asociados A Actividades De Usuarios En Plataformas De
Aprendizaje En Línea. Caso De Estudio Moodle,” Universidad del
Cauca, 2015.
[14] M. Lanza and S. Ducasse, “Polymetric Views-A Lightweight Visual
Approach to Reverse Engineering,” IEEE Trans. Softw. Eng., vol. 29,
no. 9, pp. 782–795, 2003.
978-1-4673-9461-1/15/$31.00 © 2015 IEEE
[15] R. Koschke, “Architecture Reconstruction,” in Software Engineering
SE - 6, vol. 5413, A. De Lucia and F. Ferrucci, Eds. Springer Berlin
Heidelberg, 2009, pp. 140–173.
[16] B. Bellay and H. Gall, “Reverse Engineering to Recover and Describe a
System’s Architecture,” in Development and Evolution of Software
Architectures for Product Families SE - 17, vol. 1429, F. van der
Linden, Ed. Springer Berlin Heidelberg, 1998, pp. 115–122.
.