SciELO - Scientific Electronic Library Online

 
vol.27 número5Sistema Embebido para Validar el Funcionamiento de la Tarjeta de Adquisición de Datos USB-6009 de National InstrumentsEstrategia Metaheurística para Redes Ópticas sin Conversión de Longitud de Onda con Tráfico Dinámico (WDM) índice de autoresíndice de materiabúsqueda de artículos
Home Pagelista alfabética de revistas  

Servicios Personalizados

Revista

Articulo

Indicadores

Links relacionados

  • En proceso de indezaciónCitado por Google
  • No hay articulos similaresSimilares en SciELO
  • En proceso de indezaciónSimilares en Google

Compartir


Información tecnológica

versión On-line ISSN 0718-0764

Inf. tecnol. vol.27 no.5 La Serena  2016

http://dx.doi.org/10.4067/S0718-07642016000500022 

Recuperación de Arquitecturas de Software: Un Mapeo Sistemático de la Literatura

 

Software Architecture Recovery: A Systematic Mapping Study

 

Martín E. Monroy(1), José L. Arciniegas(2) y Julio C. Rodríguez(1)

(1)    UniversiCaC Ce Cartagena, FacultaC Ce Ingeniería, Programa Ce Ingeniería Ce Sistemas, PieCra Ce Bolívar, Bolívar - Colombia (e-mail: mmonroyr@unicartagena.eCu.co, jroCriguezr@unicartagena.eCu.co)

(2)    UniversiCaC Cel Cauca, Departamento Ce Telemática, Sector Tulcán, Cauca - Colombia (e-mail: jlarci@unicauca.eCu.co)


Resumen

En este artículo se presentan los resultados de un mapeo sistemático de la literatura sobre el tema de recuperación de vistas arquitectónicas de sistemas software, el cual se llevó a cabo aplicando una propuesta metodológica establecida en la literatura. Se identificaron los estudios existentes sobre el tema, especificando el tipo de estudio realizado, su propósito, las técnicas de recuperación que utilizan, los aspectos y elementos de la arquitectura que recuperan y los mecanismos que utilizan para representar las vistas arquitectónicas recuperadas, entre otros aspectos. Se concluye que sería útil contar con un mecanismo unificado y consistente para representar los resultados obtenidos por las técnicas de recuperación de arquitecturas, que facilite su interpretación, análisis y reutilización.

Palabras clave: recuperación de arquitectura; ingeniería inversa; mapeo sistemático; arquitectura de software.


Abstract

This paper presents the results of a systematic mapping review about the recovery of architectural views from a software system, which was carried out using a methodological proposal found in the literature. Existing studies on the subject were identified, specifying the type of research, its purpose, the used recovery techniques, the aspects and architectural elements that is recovered, and the models used to represent the recovered architectural views, among others. It is concluded that it would be useful to have a unified and consistent mechanism for representing the results obtained by architectural recovery techniques, which facilitates their interpretation, analysis and reuse.

Keywords: architecture recovery; reverse engineering; systematic review; software architecture.


 

INTRODUCCIÓN

La evolución del software se logra a través del mantenimiento del producto, sin embargo, esta actividad representa altos costos para el proceso de desarrollo (Koskinen, 2010). Por otra parte, Cuadrado et al. (2008) afirman que aproximadamente el 50% del tiempo de mantenimiento se utiliza para el entendimiento del sistema. Esta situación se presenta porque el conocimiento sobre el sistema se encuentra registrado en forma explícita en la documentación o de manera implícita en la mente de los expertos que lo desarrollaron. Desafortunadamente, con frecuencia no se dispone de dicho conocimiento, sobre todo cuando se trata de sistemas heredados que carecen de documentación o se encuentra desactualizada y no se cuenta con el equipo de expertos que lo crearon (Demeyer et al., 2009; Cuenca et al., 2008).

Por otra parte, debido al cambio continuo que genera el círculo virtuoso entre los avances científicos y tecnológicos, cada día se hace más imperante para un producto software tener capacidad de mantenimiento: capacidad del producto software para ser modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas o perfectivas (ISO/IEC 25000, 2005). Esto se logra si el producto es modular y tiene capacidad para ser: analizado, probado, modificado y reutilizado. Adicionalmente, para efectos de control de calidad se requiere garantizar la coherencia entre el código fuente y los modelos arquitectónicos y de diseño propuestos (Müller et al., 2000).

Ante esta situación, la ingeniería inversa se ha convertido en la principal solución, porque permite recuperar el conocimiento de un producto software para facilitar su comprensión (Tonella et al., 2007; Rugaber y Stirewalt, 2004). También facilita la reutilización de código, el control de clonación no autorizado, el análisis y entendimiento del código malicioso (Treude et al., 2011). Además, hace posible la coexistencia sincronizada del sistema y los modelos que lo representan . Esto la ha convertido en uno de los mayores retos actuales de la ingeniería de software (Favre et al., 2009).

La recuperación de arquitectura es un enfoque de la ingeniería inversa cuyo principal objetivo es reconstruir las vistas arquitectónicas de un producto software (Ducasse y Pollet, 2009). Según el estándar ISO/IEC/IEEE 42010:2011, la arquitectura comprende los conceptos o propiedades fundamentales de un sistema en su entorno plasmados en sus elementos, relaciones, y en los principios que rigen su diseño y evolución. La descripción de la arquitectura es un producto de trabajo utilizado para expresar la arquitectura. Un punto de vista arquitectónico es un producto de trabajo en el que se establecen los convenios para la construcción, interpretación y uso las vistas arquitectónicas para enmarcar los intereses específicos sobre el sistema. Una vista arquitectónica es un producto de trabajo que expresa la arquitectura de un sistema desde la perspectiva de un conjunto de intereses específicos del sistema, para lo cual utiliza un tipo de modelo como forma de representación (grafos, diagramas, redes de Petri, etc).

Existen varias propuestas que definen los puntos de vista y las vistas que describen la arquitectura de un sistema software (Hofmeister et al., 1999; Kruchten, 1995; Smolander, 2002; ISO/IEC/IEEE, 2011), lo que obliga a seleccionar un enfoque para representar la arquitectura, el cual depende del contexto y la situación (Smolander, 2002). Esta circunstancia incrementa la complejidad del proceso de recuperación de la arquitectura, porque exige para cada enfoque tareas adicionales, que se podrían obviar si existiera unidad de criterios para identificar y representar los elementos de la arquitectura.

Con el propósito de afrontar dicha complejidad Koschke hace una revisión de la situación sobre el tema en el año 2005, el cual actualizó en el 2009, en la que concluye que sería útil un catálogo sobre las técnicas de recuperación de arquitectura detallando cuándo y cómo deben ser utilizadas. De igual forma, Ducasse y Pollet hacen un estudio sobre el tema en el año 2007, el cual actualizaron en el 2009, obteniendo como resultado una clasificación de los enfoques de recuperación de arquitectura, estructurada en los siguientes ejes: el propósito, el proceso, las entradas, las técnicas y las salidas. A pesar de la profundidad de estos estudios y de la rigurosidad científica con que se hicieron, no se detallan los aspectos relacionados con los elementos de la arquitectura que se recuperan ni los mecanismos que utilizan para representarlos.

Conocer los elementos de la arquitectura que se recuperan y los mecanismos que utilizan las técnicas de recuperación de arquitectura para representarlos (Ducasse y Pollet, 2009), es importante porque facilita la interpretación de los resultados obtenidos en el proceso de recuperación, reflejando las vistas arquitectónicas recuperadas. Además, hace más eficiente el trabajo de investigación en este campo, porque brinda la oportunidad de integrar las propuestas existentes; al mismo tiempo que facilita la definición de lineamientos y criterios que hagan posible la unificación de los mecanismos de representación de los elementos recuperados por cada técnica (Favre, 2004). Esto también contribuye a la definición de técnicas de análisis arquitectónico sobre los resultados obtenidos en los procesos de recuperación de arquitecturas (Zhang et al., 2009; Peake et al., 2013).

Por lo anterior, se planteó como objetivo de la presente investigación identificar los elementos de la arquitectura que recuperan las técnicas de recuperación de arquitectura y los mecanismos que utilizan para representarlos. Para lograr dicho objetivo se aplicó la metodología que se explica a continuación, logrando los resultados descritos posteriormente. Finalmente se hace un análisis de los resultados y se presentan las conclusiones.

METODOLOGÍA

Se hizo un mapeo sistemático de la literatura aplicando la propuesta metodológica establecida por Kitchenham et al. (2011) y Petersen et al. (2008), que consistió en la realización de los siguientes pasos: 1) definición de las preguntas de investigación, 2) búsqueda de los estudios primarios, 3) selección de los estudios aplicando los criterios de inclusión y exclusión establecidos, 4) clasificación de los artículos y 5) extracción y agregación de datos. El propósito del estudio consistió en identificar las técnicas de recuperación de arquitectura existentes hasta el momento, los elementos de la arquitectura que recuperan y los tipos de modelos que utilizan para representarlos, con el ánimo de establecer los desafíos existentes al respecto. Para orientar el mapeo sistemático se definieron las siguientes preguntas de investigación:

1) ¿Cuáles son los estudios existentes acerca de la recuperación de vistas arquitectónicas?. Esto permite establecer un inventario sobre los trabajos realizados en el campo de la recuperación de arquitecturas, a partir del cual se fundamentan los resultados de esta investigación; 2) ¿Qué tipos de estudio se han realizado?; 3) ¿Cuál es el propósito de cada estudio?, al responder las dos últimas preguntas se pueden clasificar los trabajos realizados según su tipo y propósito, identificando con claridad aquellos que corresponden a propuestas conceptuales, para hacer un análisis focalizado sobre las técnicas de recuperación que utilizan, los elementos de la arquitectura que recuperan y los tipos de modelos que aplican como forma de representación, para lo cual se plantean las preguntas; 4) ¿Qué técnicas de recuperación utilizan aquellos estudios que plantean propuestas conceptuales para recuperar arquitecturas?; 5) ¿Qué aspectos de la arquitectura recupera cada estudio?; 6) ¿Qué mecanismos utilizan para representar las vistas arquitectónicas recuperadas?; 7 ¿Cuáles son los principales investigadores en el tema?; y 8) ¿Cuáles son principales medios donde se publican estudios sobre el tema?, con la intención de identificar los expertos en el tema y los medios que más han publicado al respecto, facilitando el trabajo a futuras investigaciones.

La búsqueda de los estudios primarios se realizó en las siguientes bases de datos bibliográficas: IEEExplore ACM Digital Library, SpringerLink, ScienceDirect, Scopus, Wiley online Library y Citeseer. En cada una de ellas se aplicaron las expresiones de búsquedas obtenidas a partir de la formulación: [(cadena1 AND cadena3) OR (cadena4 AND cadena1) OR (cadena4 AND cadena2)], donde: cadena1= "architecture", cadena2 = "archi tectural views", cadena3 = [("retrieval" OR "recovery" " OR "reconstruction" OR "discovery")] y cadena4 = [("Reconstructing" OR "reverse" OR "reversing" OR "retrieving" OR "recovering" OR "capturing" OR "discovering" OR "runtime" OR "extract" OR "extracting" OR "mining")].

Esto implicó realizar 26 búsquedas en cada base de datos, para un total de 182 búsquedas que se realizaron en los campos: título, resumen y palabras clave, obteniendo un total de 4050 documentos encontrados. Se seleccionaron inicialmente los documentos que cumplieron con los siguientes criterios de inclusión: Capítulos de libros, reportes técnicos, literatura gris y artículos de revistas que presenten resultados de estudios empíricos, sin restricción de fecha de publicación. Para depurar el listado obtenido se aplicaron los siguientes criterios de exclusión: Documentos duplicados, aquellos cuyo tema principal no es la recuperación de arquitecturas de software, los que hayan sido publicados en revistas o actas de conferencias no arbitradas y los documentos de opinión. En la Tabla 1 se relaciona la cantidad de artículos seleccionados por cada base de datos consultada.

Tabla 1: Cantidad de artículos seleccionados por base de datos bibliográfica

Para evaluar la fiabilidad de la aplicación de los criterios de inclusión/exclusión, se seleccionó una muestra de 70 documentos encontrados en la búsqueda de IEEExplore, correspondiente al 36% del total de documentos encontrados en esta base de datos y al 75% de los documentos seleccionados en la misma. Esta muestra fue analizada independientemente por dos revisores para determinar la fiabilidad interevaluador mediante el estadístico Kappa Cohen (Carletta, 1996). Se obtuvieron los resultados presentados en la Tabla 2, dando un grado de fiabilidad satisfactorios (Kappa = 0,821). Esto indica la existencia de criterios claros que no denotan divergencias representativas entre los revisores (Fleiss et al., 2013).

Tabla 2: Fiabilidad de los criterios de inclusión/exclusión

La clasificación de los artículos se realizó tomando como referente las preguntas de investigación establecidas, lo que permitió llegar a las siguientes categorías: Tipos de estudio, técnicas de recuperación utilizadas, aspecto de la arquitectura recuperado, mecanismos utilizados para representar las vistas arquitectónicas recuperadas, principales investigadores en el tema y principales medios de publicación. La extracción de los datos fue realizada por cada uno de los autores en forma independiente a partir de la lectura de cada uno de los documentos, llenando los datos correspondientes a las categorías mencionadas previamente. Posteriormente se hizo la validación mediante la confrontación de los datos obtenidos, identificando y resolviendo las diferencias encontradas.

RESULTADOS

Los resultados que responden a las seis primeras preguntas establecidas se encuentran detallados en la Tabla 3, que constituye un inventario sobre los trabajos realizados en el campo de la recuperación de arquitecturas, desde comienzos de la década de los noventa hasta la realización de esta investigación. En la primera columna aparecen los autores con un número consecutivo, que sirve para ubicar en la Tabla 4 el documento que se ha analizado. De esta manera se da respuesta a la primera pregunta de investigación. En la segunda columna se presenta el año de publicación para organizar cronológicamente en forma ascendente los documentos encontrados. En la tercera columna está el tipo de estudio, tomando como posibles valores los establecidos por Tonella et al., (2007): No experimento (NE), reporte de experiencia (RE), estudio de caso (EC), cuasi-experimento (QE), estudio a partir de la observación (EO), revisión sistemática (RS) y experimento aleatorio (EA), lo que da respuesta a la segunda pregunta.

La cuarta columna muestra el propósito del estudio (Tonella et al., 2007): Propuesta conceptual (PC), prueba de conceptos (PbC), comparación (C) y revisión de literatura (RL), dando respuesta a la tercera pregunta. Las preguntas cuatro, cinco y seis sólo aplican para aquellos estudios cuyo propósito principal es plantear una propuesta conceptual con respecto a la recuperación de arquitecturas. La quinta columna indica la técnica de recuperación utilizada. En la realización del mapeo se encontraron la siguientes técnicas: Análisis dinámico (AD), análisis estático (AE), anotaciones en el código (AC), atributos de calidad (AtC), clustering (C), coincidencia de patrones (CP), concept location (CL), heurística (H), inteligencia artificial (IA), minería de datos (MD), reconocimiento de patrones (RP), reflexión (R), teoría de grafos (TG). Con esto se responde a la cuarta pregunta de investigación. Para aquellos estudios que no hacen claridad sobre la técnica aplicada se utiliza la notación NI que significa no indica. La sexta columna presenta el aspecto de la arquitectura que se recupera: Estructura (E), comportamiento (C) o ambas (A) (Canfora et al., 2011), mientras que la séptima columna dice el mecanismo que utilizan para representar las vistas arquitectónicas recuperadas, quedando resueltas la quinta y sexta pregunta.

Tabla 3: Relación de estudios seleccionados




Tabla 4: Referencia a estudios seleccionados







Para responder la séptima pregunta se tomó como criterio la cantidad de artículos publicados por cada investigador, siendo el mínimo valor cinco. Los resultados obtenidos se presentan en la Tabla 5, donde se discrimina la cantidad de artículos en los que cada autor aparece como principal o en calidad de coautor, además del año de la última publicación. Finalmente, al responder la última pregunta de investigación se evidencia que el 45% de los trabajos han sido publicados en siete conferencias y tres revistas relacionadas en la Tabla 6, a partir de la cual se puede inferir que el principal medio de publicación sobre recuperación de arquitecturas de software son las conferencias.

Tabla 5: Principales investigadores en el tema.

Tabla 6: Principales medios de publicación sobre el tema.

ANÁLISIS DE LOS RESULTADOS

En coherencia con las preguntas establecidas para el mapeo literario, se hace un análisis fundamentado en los resultados estadísticos y en función de las siguientes variables y sus posibles relaciones: Propósito del estudio, aspecto de la arquitectura que se recupera, técnica de recuperación utilizada, elementos de la arquitectura recuperados y mecanismos utilizados para representar las vistas arquitectónicas recuperadas. A partir de los resultados obtenidos se observa que durante la última década se tiene una producción promedio de 17 artículos por año, lo cual indica la vigencia y relevancia del tema en el contexto de la ingeniería de software. Por otra parte, con respecto al tipo de estudio realizado se reporta una tendencia a presentar estudios de caso (EC 42.4%), siendo menos frecuentes los reportes de experiencia (RE 30.5%) y los experimentos (EX 25.4%), mientras que sólo se identificaros 4 revisiones sistemáticas (RS) que corresponden al 1.7% de los documentos encontrados.

En relación con el propósito del estudio, los resultados revelan que la gran mayoría presentan propuestas conceptuales (77.1%), casi una quinta parte (18.2%) se centran en probar conceptos, mientras que sólo el 3% son comparaciones y el 1.7% hacen revisión literaria, como se observa en la Tabla 7. Se encontraron distintos tipos de propuestas conceptuales: Propuesta de métodos, propuesta de métodos y desarrollo de herramientas, definición de marcos de referencia, definición de algoritmos, mejora de algoritmos, presentación de patrones, entre otras; de las cuales la mayoría de estudios corresponde a la definición de un marco de referencia (Ver Tabla 7). Los primeros cinco tipos de propuestas conceptuales enunciadas se centran directamente en la recuperación de arquitecturas, por eso, más adelante se hace un análisis particular para este grupo conformado por 174 documentos. También se determinó que los estudios orientados a probar conceptos lo hacen a través del desarrollo de una herramienta, la aplicación de un método o la evaluación a nivel de comparación entre varios métodos.

Tabla 7: Detalle del propósito de los estudios encontrados por tipo de estudio realizado

En cuanto al aspecto de la arquitectura que se recupera, se determinó que la mitad (51,7%) de los estudios se centran en la recuperación de la estructura y una tercera parte (32.2%) recupera tanto la estructura como el comportamiento, mientras que sólo una sexta parte (16.1%) se centra en la recuperación del comportamiento, como se observa en la Tabla 8. Este bajo porcentaje de investigaciones orientadas exclusivamente a recuperar el comportamiento podría tener su origen en los retos establecidos por Canfora et al. (2011) al momento de recuperar el comportamiento de un sistema software: Habilidad para compilar y ejecutar programas, habilidad para seleccionar entradas representativas, habilidad para buscar información relevante en las trazas de ejecución y habilidad para realizar análisis de caja negra.

Tabla 8: Detalle propuestas conceptuales por aspecto recuperado

También se determinó que las técnicas de recuperación más utilizadas son Clustering y la Heurística (ver Tabla 9), entendiendo a esta última como la combinación de varias técnicas o la presentación de propuestas originales como: "morder abajo" (Zhang et al., 2009), procesos ligeros (Svetinovic y Godfrey, 2001), conjunto de activos arquitectónicos de dominio (Ivkovic y Godfrey, 2003), recuperación basada en evidencias (Ros y Sangwan, 2011), recuperación incremental (Roy y Graham, 2008), recuperación a partir de trazas de eventos (Cook y Wolf, 1998), recuperación basada en reglas de abstracción (Qiao et al., 2003), recuperación basada en componentes (Anquetil et al., 2009; Sun et al., 2005), recuperación basada en metamodelos (Ran y Lencevicius, 2003), análisis a partir de la interfaz gráfica de usuario (Staiger, 2007) y análisis a partir de XML (Riva y Yang, 2002). Para el caso concreto de la recuperación del comportamiento las técnicas más utilizadas son la heurística y la reflexión.

Tabla 9: Técnicas de recuperación utilizadas según aspecto recuperado

Otro aspecto importante en la recuperación de la arquitectura corresponde a los elementos recuperados. A partir del mapeo sistemático se determinó que una tercera parte de los estudios concentran su atención en la recuperación de módulos (ver Tabla 10), otro porcentaje igual, además de recuperar los componentes establecen las relaciones de comunicación entre ellos (sus conectores). En menor porcentaje se recupera subsistemas (8%), conceptos (6.9%), capas (5.2%), trazas de ejecución (3.4%), decisiones arquitectónicas (2.9%), patrones de diseño (2.3%), concurrencia y rendimiento (1.1) y sólo en un 0.6% se recupera: servicios, procesos y comunicación entre ellos, antipatrones en java y problemas de conformidad entre el diseño y la implementación.

Tabla 10: Elementos recuperados según aspecto recuperado

Al establecer la relación entre los elementos recuperados y la técnica de recuperación utilizada (ver Tabla 11), se observa qué sólo la técnica de reconocimiento de patrones (Schmerl et al., 2006; Guo et al., 1999) se ha utilizado exclusivamente para recuperar componentes y conectores, mientras que en los demás casos se puede recuperar más de un elemento de la arquitectura, evidenciándose la tendencia de recuperar módulos para representar la estructura aplicando diversas técnicas de recuperación, siendo la más utilizada Clustering. Por otra parte, para representar el comportamiento la mayoría de las propuestas se limitan a recuperar componentes y conectores, que no describen en forma completa este aspecto de la arquitectura, lo que dificulta un análisis más detallado sobre los elementos recuperados.

Tabla 11: Elementos recuperados según técnica de recuperación

Por otra parte, los elementos recuperados se representan utilizando distintos mecanismos para mostrar las vistas arquitectónicas. El mapeo realizado permitió identificar que la forma de representación más usada es el grafo (59,8%), seguida por un grupo de trabajos que utilizan lenguajes de descripción de arquitectura como UML (20.7%), ACME (4,0%), ABC/ADL (0,6%), ASDL (Architecture Structure Description Language) (0,6%), mientras que otros utilizan lenguajes de marcado como XML (0,6%) o lenguajes propuestos por los autores como es el caso de IML (Intermediate Language) (Staiger, 2007). También se encontró una propuesta (0,6%) bajo el enfoque de desarrollo dirigido por modelos que utiliza el meta-metamodelo MOF (Meta Object Facility) y el lenguaje QVT (Query/View/Transformation).

Adicionalmente se identificaron propuestas que utilizan registro de tiempos (Lencevicius y Ran, 2004; Ran y Lencevicius, 2003) , redes de Petri (Grone et al., 2002; Cook y Wolf, 1998), Calling Context Tree (Rothlisberger et al., 2012), Concept-Requirement-Decision (CRD) Tree (Ros y Sangwan, 2011), Diagrama de eventos (Jerding y Rugaber, 1998), Feature model (Acher et al., 2013), Matriz de la estructura de diseño (Cai et al., 2013), Metamodelos (Favre, 2004) y texto con identificadores (Merlo et al., 2003).

Teniendo en cuenta que la forma de representar un elemento arquitectónico determina su precisión semántica, se estableció la relación entre los elementos recuperados y su forma de representación para cada uno de los estudios encontrados en el mapeo, observando que los estudios que utilizan UML se limitan a mostrar los elementos que representan el comportamiento del sistema sólo por medio de componentes y conectores, que si bien, es un modelo que muestra aspectos relacionados con la comunicación, omite información relevante para entender los detalles, tales como la secuencia, la concurrencia y los tiempos, entre otros, a partir de los cuales se puede hacer un análisis más completo. Otro aspecto que se infiere es la tendencia a representar los distintos elementos recuperados a través de grafos, que si bien son fáciles de construir e interpretar, tienen una capacidad semántica limitada para representar los aspectos estructurales y de comportamiento.

CONCLUSIONES

Los resultados presentados permiten concluir lo siguiente:

1)    Sería útil contar con un mecanismo unificado y consistente para representar los resultados obtenidos por las técnicas de recuperación de arquitecturas, que facilite su interpretación, análisis y reutilización (Gorton y Zhu, 2005).

2)    Existe una amplia gama de propuestas conceptuales para recuperar la arquitectura, no obstante, las vistas arquitectónicas de comportamiento recuperadas hasta el momento aún no proporcionan la semántica suficiente, que permita realizar análisis más detallados sobre la arquitectura.

3)    Hay una tendencia a recuperar componentes como elementos representativos de la arquitectura, lo cual, si bien es válido, conlleva a una sobrecarga del término que dificulta su interpretación (Ducasse y Pollet, 2009).

4)    Se identificaron trece (13) técnicas de recuperación de arquitecturas, siendo la más usada Clustering, seis (6) tipos de lenguaje para describir la arquitectura y diez (10) formas para representar los elementos arquitectónicos, siendo los grafos los utilizados con mayor frecuencia.

5)    Se corrobora el planteamiento de Koschke (2009) sobre la necesidad un catálogo de las técnicas de recuperación de arquitectura detallando cuándo y cómo deben ser utilizadas.

6)    La recuperación de la arquitectura es un tema vigente que interesa a la comunidad desarrolladora de software.

AGRADECIMIENTOS

Este trabajo es parte de los resultados parciales de la tesis doctoral titulada Marco de referencia para la recuperación y análisis de vistas arquitectónicas de comportamiento, desarrollada por Martín Monroy Ríos en el programa de Doctorado de la Universidad del Cauca. Agradecemos a la Red Latinoamericana de Coordinación y Cooperación para unificar buenas prácticas de desarrollo de Software - Proyecto SPU CoCoNet-LA por su apoyo.

REFERENCIAS

Acher, M.; Cleve, A.; Collet, P.; Merle, P.; Duchien, L. y P. Lahire, Extraction and evolution of architectural variability models in plugin-based systems, Software and Systems Modeling: 13(4), 1367-1394 (2014)        [ Links ]

Anquetil, N.; Royer, J.; André, P.; Ardourel, G.; Hnétynka, P.; Poch, T. y V. Petraçcu, JavaCompExt: Extracting architectural elements from java source code, Proceedings - Working Conference on Reverse Engineering, WCRE, 317-318 (2009)        [ Links ]

Cai, Y.; Wang, H.; Wong, S. y L. Wang, Leveraging design rules to improve software architecture recovery, QoSA 2013 - Proceedings of the 9th International ACM Sigsoft Conference on the Quality of Software Architectures, 133-142 (2013)        [ Links ]

Carletta, J., Assessing agreement on classification tasks: the kappa statistic, Computational linguistics: 22(2), 249-254 (1996)        [ Links ]

Cook, J. E. y A. L. Wolf, Event-based detection of concurrency, Proceedings of the ACM SIGSOFT Symposium on the Foundations of Software Engineering, 35-45 (1998)        [ Links ]

Cuadrado F.; García B.; Dueñas J. y H. A. Parada, A Case Study on Software Evolution towards Service-Oriented Architecture, IEEE Computer Society, 22nd International Conference on Advanced Information Networking and Applications, Gino-wan City, Okinawa, Japan, 25 al 28 de marzo (2008)        [ Links ]

Cuenca, Ll.; Ortiz A. y A. Boza, Desarrollo de una Herramienta Software para la Vista de Información de la Arquitectura CIMOSA, doi: 10.4067/S0718-07642008000300014, Información Tecnológica: 19(3), 97-106 (2008)        [ Links ]

Demeyer, S.; Ducasse S. y O. Nierstrasz, Object-Oriented Reengineering Patterns. 342, Square Bracket Associates, Berna, Suiza (2009)        [ Links ]

Ducasse, S. y D. Pollet, Software architecture reconstruction: A process-oriented taxonomy, IEEE Transactions on Software Engineering: 35(4), 573-591 (2009)        [ Links ]

Favre, J., CacOphoNy: Metamodel-driven software architecture reconstruction, Proceedings - Working Conference on Reverse Engineering, WCRE, 204-213 (2004)        [ Links ]

Favre L.; Martinez L y C. Pereira, MDA-Based Reverse Engineering of Object Oriented Code, Enterprise, Business-Process and Information Systems Modeling, 29, Springer, 251-263 (2009)        [ Links ]

Fleiss, J. L;, Levin, B. y M. C. Paik, Statistical methods for rates and proportions, John Wiley & Sons (2013)        [ Links ]

Gorton, I. y L. Zhu, Tool support for just-in-time architecture reconstruction and evaluation: An experience report, Proceedings - 27th International Conference on Software Engineering, ICSE05, 514-523 (2005)        [ Links ]

Grone, B; Knopfel A. y R. Kugel, Architecture recovery of Apache 1.3--A case study, International Conference on Software Engineering Research and Practice (2002)        [ Links ]

Guo, G. Y.; Atlee, J. M. y R. Kazman, A software architecture reconstruction method, Springer US, 15-33 (1999)        [ Links ]

Hofmeister, C.; Nord, R, y D. Soni, Applied Software Architecture, Reading, MA: Addison-Wesley (1999)        [ Links ]

ISO/IEC/IEEE 42010. Systems and software engineering — Architecture description, International Organization for Standardization, Ginebra, Suiza (2011)        [ Links ]

ISO/IEC 25000. Software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, International Organization for Standardization, Ginebra, Suiza (2005)        [ Links ]

Ivkovic, I. y M. Godfrey, Enhancing domain-specific software architecture recovery, 11th IEEE International Workshop on Program Comprehension IEEE, 266-273 mayo (2003)        [ Links ]

Jerding, D. y Rugaber, S., Extraction of architectural connections from event traces, In Proceedings of the ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering (1998)        [ Links ]

Kitchenham, B.A.; D. Budgen, y O.P. Brereton, Using mapping studies as the basis for further research. A participant-observer case study, Information and Software Technology: 53(6), 638-651 (2011)        [ Links ]

Koschke, R. Architecture reconstruction: Tutorial on reverse engineering to the architectural level (2009)        [ Links ]

Koschke, R., Reconstruction of software architectures: A literature and methods overview on the state of the science. [Rekonstruktion von Software-Architekturen: Ein Literatur- und Methoden-Überblick zum Stand der Wissenschaft] Informatik - Forschung Und Entwicklung: 19(3), 127-140 (2005)        [ Links ]

Koskinen, J., Software maintenance costs, University of Jyvãskylã (2010)        [ Links ]

Kruchten, P.B., The ‘4+1’ View Model of Architecture", IEEE Software, 12(6), 45-50 (1995)

Lencevicius, R. y A. Ran, Applying fixed priority scheduling in practice, Proceedings of the Fourth International Workshop on Software and Performance, WOSP'04, 156-160 (2004)        [ Links ]

Merlo, E.; McAdam, I. y R. De Mori, Feed-forward and recurrent neural networks for source code informal information analysis. Journal of Software Maintenance and Evolution, 15(4), 205-244 (2003)        [ Links ]

Müller H. A.; Jahnke J. H.; Smith D. B.; Storey M.; Tilley S. R. y K. Wong, Reverse Engineering: A Roadmap. Conference on The Future of Software Engineering, Limerick, Ireland, 47 - 60 (2000)        [ Links ]

Peake, I.; Blech, J. O. y L. Fernando, Towards Reconstructing Architectural Models of Software Tools by Runtime Analysis. In EESSMOD@ MoDELS, 43-48 (2013)        [ Links ]

Petersen, K.; Feldt R.; Mujtaba S. y M. Mattsson, Systematic Mapping Studies in Software Engineering, 12th International Conference on Evaluation and Assessment in Software Engineering (EASE), 1-10, Bari, Italy junio (2008)        [ Links ]

Pollet, D.; Ducasse, S.; Poyet, L.; Alloui, I.; CTmpan, S. y H. Verjus, Towards a process-oriented software architecture reconstruction taxonomy, in Proceedings of the European Conference on Software Maintenance and Reengineering, CSMR, 137-148 (2007)        [ Links ]

Qiao, B.; Yang, H.; Chu, W. C. y B. Xu, Bridging legacy systems to model driven architecture, Proceedings -IEEE Computer Society's International Computer Software and Applications Conference, 304-309 (2003)        [ Links ]

Ran, A. y R. Lencevicius, Making sense of runtime architecture for mobile phone software, Proceedings of the Joint European Software Engineering Conference (ESEC) and SIGSOFT Symposium on the Foundations of Software Engineering (FSE-11), 367-370 (2003)        [ Links ]

Riva, C.y Y. Yang, Generation of architectural documentation using XML, In Ninth Working Conference Reverse Engineering, 161-169 (2002)        [ Links ]

Ros, J. P. y R. S. Sangwan, A method for evidence-based architecture discovery, Proceedings - 9th Working IEEE/IFIP Conference on Software Architecture, WICSA, 342-345 (2011)        [ Links ]

Rothlisberger, D.; Harry, M.; Binder, W.; Moret, P.; Ansaloni, D.; Villazón, A. y O. Nierstrasz, Exploiting dynamic information in IDEs improves speed and correctness of software maintenance tasks, IEEE Transactions on Software Engineering: 38(3), 579-591 (2012)        [ Links ]

Roy, B. y T. Graham, An iterative framework for software architecture recovery: An experience report (2008)        [ Links ]

Rugaber S. y K. Stirewalt, Model-Driven Reverse Engineering, IEEE Software: 21(4), 45-53 (2004)        [ Links ]

Schmerl, B.; Aldrich, J.; Garlan, D.; Kazman, R. y H. Yan, Discovering architectures from running systems, IEEE Transactions on Software Engineering: 32(7), 454-466 (2006)        [ Links ]

Smolander, K., Four metaphors of architecture in software organizations: finding out the meaning of architecture in practice, In Empirical Software Engineering, International Symposium 211-221 (2002)        [ Links ]

Song, H.; Huang, G.; Wu, Y.; Chauvel, F.; Sun, Y. ; Shao, W.; y H. Mei, Modeling and maintaining runtime software architectures, Ruan Jian Xue Bao/Journal of Software: 24(8), 1731-1745 (2013)        [ Links ]

Staiger, S., Static analysis of programs with graphical user interface, Proceedings of the European Conference on Software Maintenance and Reengineering, CSMR, 252-261 (2007)        [ Links ]

Sun, C.; Cao, J.; Zhou, J.; Jin, M.; Liu, C. y Y. Shen, ReArchJBs: A tool for automated software architecture recovery of JavaBeans-based applications, Proceedings of the Australian Software Engineering Conference, ASWEC, 270-280 (2005)        [ Links ]

Svetinovic, D. y M. Godfrey, A lightweight architecture recovery process, Software Architecture Recovery and Modelling, Stuttgart, Germany (2001)        [ Links ]

Tonella, P.; Torchiano, M.; Du Bois, B. y Systa, T., Empirical studies in reverse engineering: state of the art and future trends, Empirical Software Engineering: 12(5), 551-571 (2007)        [ Links ]

Treude C.; Figueira F. y M. Storey, An Exploratory Study of Software Reverse Engineering in a Security Context, 18th Working Conference on Reverse Engineering, Limerick, Ireland, 184-188 (2011)        [ Links ]

Zhang, L.; Luo, J.; Li, H.; Sun, J. y H. Mei, A biting-down approach to hierarchical decomposition of object-oriented systems based on structure analysis, Journal of Software Maintenance and Evolution: 22(8), 567596 (2009)        [ Links ]

Recibido Dic. 15, 2015; Aceptado Feb. 17, 2016; Versión final Mar. 3, 2016, Publicado Oct. 2016

Creative Commons License Todo el contenido de esta revista, excepto dónde está identificado, está bajo una Licencia Creative Commons