ATAM-AR: Un mtodo de

Recuperacin de Arquitecturas basado en ATAM

Authors Name/s per 1st Affiliation (Author)

Authors Name/s per 2nd Affiliation (Author)

line 1 (of Affiliation): dept. name of organization

line 2-name of organization, acronyms acceptable
line 3-City, Country
line 4-e-mail address if desired

line 1 (of Affiliation): dept. name of organization

line 2-name of organization, acronyms acceptable
line 3-City, Country
line 4-e-mail address if desired

AbstractThis electronic document is a live template and

already defines the components of your paper [title, text, heads,
etc.] in its style sheet. *CRITICAL: Do Not Use Symbols, Special
Characters, or Math in Paper Title or Abstract. (Abstract)

sistema ayuda a los desarrolladores a identificar y localizar las

partes del sistema que deben ser modificadas durante su
evolucin y mantencin, as como las dems partes del sistema
que se vern afectadas por dichos cambios[1].

Keywordscomponent; formatting; style; styling; insert (key

words)

A medida que un sistema software evoluciona, su

arquitectura puede requerir ajustes, de manera que sta se
degrada sino se considera su documentacin, su coherencia con
su implementacin y en especial su rationale1[2]. Esta
degradacin puede conducir a la erosin de la arquitectura, la
que la hace propensa a errores en los siguientes incrementos de
desarrollo y mantenimiento, lo cual contribuye al rpido
envejecimiento del software[3]. Por lo anterior, se considera
que la arquitectura software es parte fundamental en la
evolucin de los sistemas software [4], por lo que su
recuperacin es una la necesidad de gran importancia cuando
esta no se encuentra definida en forma explcita o hay
divergencia entre la arquitectura prescriptiva 2 y la arquitectura
descriptiva3[5]. Recuperacin de arquitecturas es un rea de la
ingeniera inversa la cual se entiende como el proceso de
analizar un sistema para crear representaciones del sistema en
un nivel de abstraccin ms alto [10].

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 solucin descriptiva
adecuada. Con el nimo de contar con dicha descripcin ha
emergido la actividad de recuperar una arquitectura de software,
cuyos principales enfoques se orientan a la recuperacin de
modelos a partir de la informacin de implementacin y de
despliegue, particularmente el cdigo fuente
y no en el
conocimiento tcito presente en el equipo de desarrollo. En este
trabajo se muestra como, un mtodo de evaluacin de
arquitecturas permite su recuperacin a partir del conocimiento
tcito del equipo, permitiendo no slo recuperar su descripcin
sino su intencin. Para evaluar la propuesta, se ha desarrollado
un estudio de caso donde el mtodo ATAM es usado para evaluar
y recuperar la arquitectura de un sistema de sincronizacin de
archivos en el contexto de diferentes plataformas virtuales de
aprendizaje. El caso ha permitido mostrar cmo se logra
recuperar la arquitectura descriptiva incluyendo su rationale.
ndice de Trminos ATAM, Evaluacin de
Arquitecturas, Ingeniera Inversa, Recuperacin de Arquitecturas.

I. INTRODUCCIN
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 ms 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

La ingeniera inversa est empezando a ser valorada como

un proceso importante en el ciclo de vida de los sistemas, pero
todava se presentan muchas problemticas debido a que es un
rea relativamente joven y debido a la gran variedad de
sistemas que podemos encontrar, causado por la gran cantidad
de lenguajes que hay. Muchas veces dentro del proceso de
ingeniera inversa se presentan dificultades para la extraccin y
visualizacin de la informacin que es necesaria en este
proceso, como tambin saber elegir cual es la informacin
relevante para realizar el proceso de ingeniera inversa de un
sistema. A veces es necesario realizar un anlisis dinmico del
sistema o en ciertas ocasiones nos encontramos con distintos
tipos de sistemas como los orientados a servicios de los cuales
no tenemos acceso a los cdigos fuente por lo que debemos
hacer un anlisis de caja negra. Uno de los grandes retos que se
presentan en la ingeniera inversa es la representacin de la
informacin, por lo que se necesita de la creacin de vistas que
1

Rationale- la inclusin explcita de las decisiones tomadas durante el

proceso de diseo y las razones por las cuales esas decisiones fueron tomadas.
2
Decisiones tomadas respecto a la arquitectura
3
Decisiones explcitamente descritas en el documento de la arquitectura

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

son extradas de los datos recolectados. Y por ltimo el reto

ms grande de la ingeniera inversa es la automatizacin de los
mtodos, donde se incluya el conocimiento de expertos para
que los mtodos puedan realizar evaluaciones y que puedan
producir resultados mejores. En esta propuesta se muestra
cmo los mtodos de evaluacin de arquitecturas pueden ser
usados para lograr su recuperacin.

Tcnica de
Evaluacin
Atributos de Calidad
Fase del diseo de
Arquitectura de
Software

En
la
verificacin de
la Arquitectura
de Software

En la verificacin de la
Arquitectura de Software(En
forma iterativa)

Este artculo est organizado de la siguiente forma. La

seccin II presenta los conceptos relacionados con mtodos de
evaluacin de arquitecturas y las diferentes experiencias de uso
en la recuperacin de arquitecturas, en la seccin III
presentamos una propuesta de recuperacin de arquitecturas
usando ATAM, en la seccin IV se realiza una evaluacin de la
propuesta en un estudio de caso donde la arquitectura de un
sistema de sincronizacin por demanda de archivos asociados a
actividades de usuarios en plataformas de aprendizaje en lnea
es analizada y recuperada y la seccin V presenta las
conclusiones.

Evaluacin de
Impacto de los
escenarios
Reusabilidad del
conocimiento

Basado
Relaciones

Basado en Relaciones

II.

TRABAJOS RELACIONADOS

La evaluacin de arquitecturas es una actividad que puede

ser til por diversas razones, por ejemplo para tomar mejores
decisiones, es decir frente a una arquitectura que me est dando
problemas, la evaluacin me puede ayudar a decidir si
conviene invertir en mejorarla o solucionar sus problemas o si
es mejor cambiarla y empezar de nuevo.
Koschke [15], define un framework llamado Symphony,
para la reconstruccin de la arquitectura donde se realiza una
combinacin de patrones comunes y hace uso de las mejores
prcticas reportadas en la literatura de la ingeniera inversa,
generando vistas y puntos de vista, donde se describe la
arquitectura segn la perspectiva de los diferentes interesados.
Bellay y Gall [16] se presenta un enfoque para realizar la
recuperacin y descripcin de la arquitectura de un sistema por
medio de mtodos y herramientas, donde involucra diferentes
aspectos que son recuperados y luego descritos. Se centra en
diversas propiedades como la seguridad, la varianza y su
descripcin, pero no en la recuperacin de la arquitectura de un
sistema completo. Estos trabajos son muy representativos por
capacidad del mtodo y las herramientas para recuperar varias
vistas para los diferentes interesados, sin embargo la
participacin de stos no es aprovechada para recuperar las
decisiones tomadas y su ratinale.

Escenarios
Modificabilidad

en

No considerado

Escenarios y tcnicas de
preguntas y medicin
Mltiples atributos de Calidad

Un conjunto de pre paquetes de

anlisis y preguntas con
conocimientos de la solucin

El mtodo ATAM evala con ms profundidad, en relacin

con otros mtodos, preguntas referentes a la arquitectura,
correspondientes a varios atributos de calidad. ATAM est
conformado por un conjunto de pasos importantes como se
muestra en la Figura 1: presentacin de ATAM, presentacin de
los Objetivos de Negocio, Presentacin de la Arquitectura,
Investigacin y Anlisis, identificacin de las aproximaciones
arquitecturales, la generacin del rbol de atributos de utilidad,
el anlisis de las aproximaciones arquitecturales, Testing, lluvia
de ideas y priorizacin de escenarios, Presentacin de
Resultados [7].
El mtodo llamado MAP (minera de arquitecturas para
lneas de producto), tiene un enfoque que se basa en el mapeo
de estilos arquitectnicos y atributos que se relacionan con la
minera de la arquitectura, donde se combinan la
reconstruccin de la arquitectura y el anlisis de tcnicas de
lneas de productos. El mtodo se analiza teniendo en cuenta
una descripcin general del MAP, la preparacin, Extraccin,
la composicin, calificacin, y la finalizacin, si la vista
arquitectnica despus de haber realizado la evolucin no es
factible se procede a hacer un anlisis con ATAM. Tambin se
muestra un caso de estudio donde se hace el anlisis usando el
mtodo MAP en varios sistemas en la industria automotriz,
dando lugar a mejoras en la extraccin donde se identifican
elementos y relaciones que ayudan a mejorar el MAP [11].

Existen diversos mtodos que ayudan a evaluar una

arquitectura, entre ellos estn: SAAM y ATAM[8]. El foco de
SAAM (Software Architecture Analysis Method) es la
modificabilidad, para ello el mtodo utiliza el agrupamiento de
escenarios como criterio para evaluar la arquitectura. Sin
embargo, existen otros mtodos como ATAM (Architecture
Trade-off Analysis Method) que exploran el balance entre
diferentes aspectos que influencian el diseo arquitectnico [8].
La Tabla 1 describe en forma diferencial los mtodos SAAM
de ATAM.
Fig. 1. Flujo conceptual del mtodo ATAM adaptado [8]
TABLE I.
Aspecto

TABLA 1
MODELO DE EVALUACIN DE
ARQUITECTURA SOFTWARE [9].
SAAM

ATAM

Vasconcelos y Werner [12] presentan un enfoque de

recuperacin y evaluacin de arquitectura para la reutilizacin

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

soportado por la herramienta ArchMine4, la cual permite

extraer el conocimiento basado en la inspeccin de sistemas
existentes. Dicho conocimiento es expresado en un modelo
arquitectnico conceptual con informacin de trazabilidad
hacia las funcionalidades implementadas, ayudando a generar
artefactos reutilizables.
III. ATAM -BASED ARQUITECTURE RECOVERING
ATAM-AR
Mientras que en SAAM la generacin de escenarios est
basada en la visin de los interesados, no provee una mtrica
clara sobre la calidad de la arquitectura evaluada y se centra en
el atributo de modificabilidad. ATAM obtiene su nombre no
solo porque nos dice que tanto una arquitectura particular
satisface varias metas de calidad, sino que tambin provee
ideas de cmo esas metas de calidad interactan entre ellas,
como realizan negociaciones mutuas (tradeoff) entre ellas,
permitiendo describir la forma en la que el sistema puede
crecer, responder a cambios, satisfacer restricciones e
integrarse con otros sistemas entre otros.

Esta propuesta explora la recuperacin de un

sistema software basndose y adaptando el mtodo
de evaluacin de arquitecturas ATAM [6]. A
continuacin se describen las tareas, los roles y los
artefactos.

3) Refinamiento y anlisis de escenarios: los escenarios

priorizados son analizados dependiendo, identificando y
analizando las propuestas arquitectnicas bajo el escenario
de anlisis, donde se identificaran los riesgos arquitectnicos,
los no riesgos, los puntos sensitivos, puntos de negociacin, el
rationale y las vistas relevantes.
4) Verificacin: Este paso tiene como objetivo el validar
el anlisis hecho en el paso anterior y completar el anlisis
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 con el paso 2.b del mtodo. Los pasos
2.b y 3.a pueden repetirse hasta que se considere que no
hay ms escenarios nuevos que analizar.

A. Tareas: esta evaluacin sigue las siguientes tareas:

1) Presentacin: El objetivo de este paso es contextualizar
a los involucrados con el sistema al cual se le va a recuperar
la arquitectura, este paso tiene los siguientes pasos:

Presentacin del mtodo: se realiza la presentacin del

mtodo ATAM-AR.
Presentacin de la arquitectura: se presenta la
arquitectura prescriptiva5 del sistema, y de los activos
que describen al sistema al cual se desea realizar la
recuperacin de su arquitectura. Estos activos pueden
ser el cdigo fuente del sistema, los diseos del sistema,
manuales tcnicos, casos de prueba, entre otros.

2) Investigacin y anlisis: El objetivo de este paso es el

anlisis del sistema, la identificacin de escenarios, puntos de
negociacin, puntos de riesgo y no riesgo. Este paso est
conformado por los siguientes pasos:

Generacin de escenarios: En este paso el equipo que

estn participando en la de la recuperacin generan
diferentes escenarios en los que se pueden evaluar los
atributos relevantes del sistema.

un enfoque de recuperacin de la arquitectura basada en el anlisis

dinmico y la minera de dato
5
Decisiones tomadas respecto a la arquitectura

Generar rbol de utilidad de atributos de calidad: Se

genera el rbol de utilidad de los atributos de calidad
que comprometen la utilidad del sistema de acuerdo a
los escenarios, este rbol es generado a partir de la lista
de escenarios, se asocian a un atributo de calidad y se
priorizan con respecto a dos criterios: la importancia y
la dificultad de implementacin.

5) Presentacin de Resultados: Basados en la

informacin recogida (escenarios, rbol de utilidad, riesgos,
no riesgos, puntos sensitivos y puntos de negociacin), se
presenta los resultados.
B. Roles

Equipo de Recuperacin: Son los encargados de

llevar y controlar la recuperacin de la arquitectura del
sistema.

Equipo de Desarrollo: Este rol puede ser tomado por

quienes desarrollaron el sistema bajo recuperacin o
pueden ser el equipo encargado de realizar operaciones
mantencin, evolucin o integracin.

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 ejecucin, en la Tabla 2 se
puede ver los responsables de cada actividad.

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

C. Artefactos

Arquitectura: Este corresponde a los activos que se

pueda tener que describa la arquitectura del sistema, los
cuales pueden ser: cdigo fuente del sistema, los
diseos del sistema, manuales tcnico, 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 relacin de los escenarios con los atributos
de calidad adems que se realiza un priorizacin de
estos con respecto a dos criterios, la importancia del
escenario en el sistema y la dificultad de su
implementacin.
TABLE II.

1
2
3
4

RELACIN DE ACTIVIDADES Y ROLES

Actividad
Presentar la ATAM
Presentar
Arquitectura
Actual
Generar
Escenarios
Generar rbol de
utilidad
de
atributos
de
calidad
Anlisis de rbol
de utilidad:

Lluvia de Ideas

Presentacin
Resultados

Chagendo[13]. El mtodo ATAM-AR fue aplicado a esta

propuesta arquitectnica para ver los resultados que se pueden
obtener, en la cual participaron los diseadores de la
arquitectura quienes tomaron los roles del equipo de
arquitectura, equipo desarrollador y grupo de interesados,
Siguiendo la primera tarea se realiz la presentacin del
mtodo y la presentacin de la arquitectura propuesta la cual se
puede ver en la figura 2.

de

Roles
Equipo de Recuperacin
Equipo de Desarrollador o Equipo de
Arquitecta
Equipo de Recuperacin y Equipo de
Desarrollador o Equipo de Arquitecta
Equipo de Recuperacin y Equipo de
Desarrollador o Equipo de Arquitecta
Equipo de Recuperacin Evaluacin y
Equipo de Desarrollador o Equipo de
Arquitecta
Equipo de Recuperacin y Equipo de
Desarrollador o Equipo de Arquitecta
Equipo de Recuperacin

Descripcin de Escenario: Cada escenario debe tener

una descripcin detallada donde se especifica el
estmulo que generar el escenario, la respuesta que debe
tener el sistema, adems 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
negociacin 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 evaluacin incluye todas las
apreciaciones que tiene sobre la arquitectura del
sistema.

IV. APLICACIN DE ATAM-AR: EL CASO DEL SISTEMA ELEARNINGSYNC

Esta es una propuesta de arquitectura con el objetivo de
soportar la sincronizacin por demanda de archivos asociados a
actividades de usuarios en plataformas de aprendizaje en lnea,
como parte del trabajo de fin de carrera de Zambrano y

Fig. 2. Arquitectura E-LearningSync, tomado de [13]

En la tarea Investigacin y Anlisis, se generaron los

escenarios y se priorizaron, en la Tabla 3 se puede ver el rbol
de utilidad de atributos de calidad que fue generado a partir de
estos dos pasos. En el paso Generar rbol de utilidad de
atributos de calidad de la tarea de Investigacin y Anlisis se
analiz el escenario ms relevante de los escenarios generados
(importancia y complejidad de desarrollo), el cual corresponde
con la integracin de nuevas plataformas de E-Learning,
debido que el principal compromiso del mecanismo fue la
integracin con distintas plataformas de aprendizaje en lnea.
El resultado es presentado en la Tabla 4.

TABLE III.

ARBOL DE UTILIDAD DE ATRIBUTOS DE CALIDAD

Atributo
de Calidad

ELearningS
ync

Escenario

Prioridad

Escalabilidad

Almacenamiento

(H, M)

Crecimiento de usuarios

(H, L)

Integrabilidad
Modificabilidad

Integracin
de
nuevas
plataformas de E-Learning
Evolucin del Servidor de
aplicaciones

(H, H)

Tiempos de respuesta
Fallos en el proceso
resolucin de conflictos
Fallos en el servidor
aplicaciones
Fallos en el servidor
Almacenamiento

de

(H, L)
(H, H)

de

(H, L)

de

(H, L)

Desempeo
Confiabilidad

(H,H)

Para este caso no se realizaron ms refinamientos, por lo

que se procedi a analizar resultados y a su reporte, en la que

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

se determina que la arquitectura est preparada

significativamente para la interoperabilidad, pero que se
depende de las libreras de acceso a los servicios de cada
plataforma de aprendizaje en lnea.
TABLE IV.
ANALISIS ESCENARIO INTEGRACION
PLATAFORMAS DE E-LEARNING
Descripcin del
Escenario

Mejorar la inter-operabilidad6 del mecanismo con las

plataformas de aprendizaje en lnea de tal manera que
sea posible detectar la creacin y actualizacin de
recursos dentro de un curso e informar al servidor de
sincronizacin 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
Para lograr esto se requiere:
3.5 personas/ mes para realizar las implementaciones
propias para una nueva plataforma (El servidor de
sincronizacin no ser modificado)
Puntos
Trade Off
Riesgos
Sensibles
Servidor Web Portabilidad
Ninguno
ElearningSync
relevante

Respuesta

Decisiones
Arquitecturales
Abstraer
Servicios Web
con el protocolo
Rest
Abstraer
Servicios para
cada plataforma
de aprendizaje en
lnea

La comunicacin
entre
componentes est
enfocada en
conexiones cliente
/ servidor P2P
Rationale

Vista de
componentes del
sistema

Servidor Web
en
la
plataforma

Conexin

Portabilidad

Disponibilidad

Algunas
plataformas
pueden restringir
por seguridad la
realizacin
de
algunas acciones
por medio de
servidores web
Posibles prdidas
de informacin

Transparencia en el uso de las plataformas, dado que si

el docente usa el mecanismo, los recursos pueden verse
desde la plataforma como si hubiese sido creados desde
ella misma.
Inter-operabilidad con distintas plataformas
En la Figura 3 se presenta una vista de tipo
componentes y conectores que incluye los servicios
web, la plataforma de aprendizaje en lnea y las
conexiones que siguen el estilo arquitectnico cliente
servidor.

El esfuerzo dedicado a la ejecucin 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 das incluyendo preparacin (motivacin y
presentacin del mtodo), ejecucin (incluyendo el modelado
de la vista recuperada) y recoleccin de informacin del caso.
6
la habilidad de los sistemas para trabajar juntos, en general gracias a la
adopcin de estndares.

V. CONCLUSIONES, LIMITACIONES Y TRABAJOS

FUTUROS
A travs de los resultados de la aplicacin de ATAM-AR en
un caso de recuperacin de un modelo arquitectnico se puede
concluir que las decisiones que se toman al momento de definir
una arquitectura de un sistema proveen informacin relevante
para su entendimiento y recuperacin, por lo que considerar los
interesados que han participado en el desarrollo de la
arquitectura es clave. Por ello la inclusin de los
desarrolladores o arquitectos que estuvieron a cargo del
desarrollo del sistema, fue en este caso una decisin clave para
obtener el rationale de una arquitectura.

Fig. 3. Vista de Componentes del sistema

Es importante rescatar el valor de la definicin de

escenarios como un mecanismo til para la concentracin de
esfuerzos de anlisis 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 recuperacin aqu presentada
est relacionada al no recuperar las vistas arquitecturales desde
los artefactos del sistema (por ejemplo el cdigo) en forma
automatizada, aunque se quera presentar la recuperacin de la
arquitectura desde el conocimiento de los arquitectos, no hubo
informacin concreta sobre la vista arquitectnica ms 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 mtodo ser complementado
con un enfoque de recuperacin basado en la visualizacin de
software [14]. Para ello actualmente estamos evaluando la
herramienta Softwarenaut, con la cual se espera que la
visualizacin 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 arquitectnicas relevantes, los patrones usados y el
rationale.

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

AGRADECIMIENTOS

Este trabajo ha sido realizado en el marco del Proyecto

Colciencias Semillero de Investigacin, 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 Ivn Zambrano y Juan Manuel Chagendo.
REFERENCIAS
[1]
[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]
[11]

I. Hogganvik, E. Molstad, and S. Fordypningsemne, INCO- Open

Source Architecture Recovery. 2002.
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.
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.
O. Maqbool and H. A. Babri, Hierarchical Clustering for Software
Architecture Recovery, Softw. Eng. IEEE Trans., vol. 33, no. 11, pp.
759780, Nov. 2007
C.-H. Lung, Software Architecture Recovery and Restructuring
Through Clustering Techniques, in Proceedings of the Third
International Workshop on Software Architecture, 1998, pp. 101104.
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. 6878.
Kazman. Rick, Klein. Mark, and Clements. Paul, "ATAM: Method for
Architecture Evaluation," Software Engineering Institute, Carnegie

[12]

[13]

[14]

[15]

[16]

Mellon University, Pittsburgh, Pennsylvania, Technical Report

CMU/SEI-2000-TR-004,
2000.
http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=5177
P. Clements, R. Kazman, and M. Klein, Evaluating Software
Architectures: Methods and Case Studies. Addison-Wesley Professional,
2001.
L. Dobrica and E. Niemela, A survey on software architecture analysis
methods, Softw. Eng. IEEE Trans., vol. 28, no. 7, pp. 638653, Jul.
2002.
E. J. Chikofsky and I. I. Cross J.H., Reverse engineering and design
recovery: a taxonomy, Software, IEEE, vol. 7, no. 1, pp. 1317, 1990.
C. Stoermer and L. OBrien, MAP - mining architectures for product
line evaluations, in Software Architecture, 2001. Proceedings. Working
IEEE/IFIP Conference on, 2001, pp. 3544.
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. 7289.
C. Zambrano and J. M. Chagendo, Sincronizacin Por Demanda De
Archivos Asociados A Actividades De Usuarios En Plataformas De
Aprendizaje En Lnea. Caso De Estudio Moodle, Universidad del
Cauca, 2015.
M. Lanza and S. Ducasse, Polymetric Views-A Lightweight Visual
Approach to Reverse Engineering, IEEE Trans. Softw. Eng., vol. 29,
no. 9, pp. 782795, 2003.
R. Koschke, Architecture Reconstruction, in Software Engineering SE
- 6, vol. 5413, A. De Lucia and F. Ferrucci, Eds. Springer Berlin
Heidelberg, 2009, pp. 140173.
B. Bellay and H. Gall, Reverse Engineering to Recover and Describe a
Systems 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. 115122.

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