ArchSync -...

ArchSync

Asistencia en la Sincronizacion deDocumentacion de Diseno con Implementacion

por

Martın Blech y Juan Pablo Carlino

Trabajo final de la carrera de grado de

Ingeniero de Sistemas

de la

Universidad Nacional del Centro de la Provincia de Buenos Aires

Director: Dr. J. Andres Diaz Pace

Co-Director: Ing. Alvaro Soria

Tandil, Argentina. Octubre de 2006

Resumen

Las arquitecturas de software son modelos de sistemas que, al poseer un altonivel de abstraccion, permiten manejar correctamente la distancia entre requerimien-tos e implementacion. La adopcion cada vez mayor del desarrollo centrado en laarquitectura se debe a que estas exponen las principales decisiones de diseno y susconsecuencias en una etapa temprana del desarrollo de software, y al hacerlo permitenun mejor entendimiento tanto del sistema como de sus requerimientos por parte detodas las personas involucradas. Por estas razones, un buen diseno arquitectonicotiene un impacto positivo en la calidad final de los productos.

Normalmente, los desarrolladores toman la descripcion arquitectonica del sistemay progresivamente la refinan hasta derivar una implementacion concreta. Durante es-ta actividad, tambien especifican las relaciones entre el modelo arquitectonico comofue documentado y el modelo arquitectonico como fue implementado, para asegu-rar cierto grado de consistencia entre los modelos. Desafortunadamente, debido a laevolucion natural del sistema, es probable que la arquitectura e implementacion pier-dan consistencia. Una vez que el diseno arquitectonico esta listo, comunmente todoslos esfuerzos se enfocan en la implementacion, y esto desactualiza progresivamente ladocumentacion de diseno. Este fenomeno es conocido como corrimiento arquitectura-implementacion o erosion arquitectonica, y si no es manejado apropiadamente, puedeperjudicar los beneficios del desarrollo centrado en la arquitectura.

Actualmente, el problema ha sido tratado por medio de algunos enfoques basadosen ingenierıa reversa, con resultados dispares. La falta de una herramienta de soportemas adecuada para relacionar especificaciones arquitectonicas con codigo sigue siendoun problema para muchos proyectos de software.

En este trabajo, proponemos un enfoque materializado en una herramienta desoporte llamada ArchSync, para asistir a los desarrolladores a conciliar la docu-mentacion arquitectonica con su implementacion a medida que la segunda cambiacon el tiempo. En particular, asumimos que existe alguna documentacion arquitec-tonica previa a la codificacion del sistema. Los modelos arquitectonicos son repre-sentados con use case maps (UCMs), una notacion practica para especificar tantocomponentes como flujos de responsabilidades. Estas responsabilidades son materia-lizadas por clases y metodos en el codigo. Cuando algo cambia en el codigo y violalo que fue prescripto por la arquitectura, ArchSync es capaz de trazar esos cambioshacia la especificacion arquitectonica original. Para hacerlo, debemos instrumentar elcodigo de la aplicacion y registrar informacion acerca de su ejecucion. Para su anali-sis, ArchSync compara estos registros con la especificacion arquitectonica, usando unconjunto de“filtros de reconstruccion”, y luego detecta que UCMs no son consistentescon el codigo. Ademas, ArchSync puede proveer una lista de posibles reparacionespara los UCMs, que el desarrollador puede ejecutar para actualizar la arquitectura sies necesario.

iii

Agradecimientos

A nuestros padres y demas familiares que nos brindaron su afecto y colaboraciondurante estos anos de estudio.

Un especial agradecimiento a nuestro director Andres Dıaz Pace y a nuestro co-director Alvaro Soria, por su colaboracion, disposicion y confianza brindados duranteel desarrollo de este trabajo.

A nuestros amigos y companeros, los cuales supieron estar a nuestro lado en formaincondicional durante todo este tiempo, y de los cuales nos sentimos muy contentosy orgullosos.

¡Gracias!

v

Indice general

Resumen III

Agradecimientos V

Indice de figuras IX

Indice de cuadros XI

Indice de algoritmos XIII

1. Introduccion 11.1. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Objetivos y restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Organizacion del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Contexto 52.1. Arquitecturas de software . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1. Documentacion . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2. ADLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3. Use-Case Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1. Notacion basica e interpretacion . . . . . . . . . . . . . . . . . 112.3.2. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.3. Rol en la documentacion de arquitecturas . . . . . . . . . . . . 12

2.4. Erosion arquitectonica . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3. Trabajos relacionados 173.1. Aportes relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1. Estrategias basadas en ingenierıa reversa . . . . . . . . . . . . 183.1.2. Estrategias basadas en ADLs . . . . . . . . . . . . . . . . . . . 223.1.3. Estrategias basadas en SCM . . . . . . . . . . . . . . . . . . . 24

3.2. Resumen de caracterısticas principales . . . . . . . . . . . . . . . . . . 263.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4. El enfoque ArchSync 314.1. Analisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2. Ejemplo: MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3. Modelo conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.1. Path-Log Matcher . . . . . . . . . . . . . . . . . . . . . . . . . 394.4. Resolucion del ejemplo MVC . . . . . . . . . . . . . . . . . . . . . . . 414.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

vii

viii INDICE GENERAL

5. Diseno e implementacion 475.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2. Diff Mapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2.1. Source code ∆ . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2.2. IDiffMapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.3. Execution Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.4. Log Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.5. Path-Log Matcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6. Casos de estudio 596.1. G2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1.1. Caso 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.1.2. Caso 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.2. FLABot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.3. Analisis de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.3.1. Estado de los proyectos ante cambios en la implementacion . . 706.3.2. Propuesta de solucion de ArchSync . . . . . . . . . . . . . . . 71

7. Conclusiones y trabajos futuros 757.1. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.1.1. Integracion con aspectos estructurales . . . . . . . . . . . . . . 767.1.2. Trazabilidad en metodos de diseno . . . . . . . . . . . . . . . . 777.1.3. Mapeo de paths con casos de test . . . . . . . . . . . . . . . . . 777.1.4. Especializacion del enfoque . . . . . . . . . . . . . . . . . . . . 77

A. Eclipse y FLABot 79A.1. Plataforma Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

A.1.1. Arquitectura de Plug-ins . . . . . . . . . . . . . . . . . . . . . . 79A.2. FLABot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Bibliografıa 85

Indice de figuras

2.1. AcmeStudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2. Framework de clasificacion y comparacion para ADLs. Caracterısticas

esenciales de modelado se resaltan en negrita. . . . . . . . . . . . . . . 92.3. Ejemplo de UCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4. UCM de un problema de contencion de recursos . . . . . . . . . . . . . 132.5. UCM de una posible situacion de deadlock . . . . . . . . . . . . . . . . 132.6. Cambio en la documentacion arquitectonica no reflejado en el codigo. 142.7. Cambio en el codigo no reflejado en la documentacion arquitectonica. 14

3.1. Matriz de dependencia entre componentes de una arquitectura de ca-pas. Los numeros indican la “intensidad” de la dependencia, calculadaen funcion del numero de referencias encontradas mediante el analisisestatico de clases en cada paquete Java. . . . . . . . . . . . . . . . . . 19

3.2. Arquitectura de la herramienta DiscoTect . . . . . . . . . . . . . . . . 213.3. Actividades principales del proceso de recuperacion de arquitecturas

de Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4. Comparacion de estructuras jerarquicas de componentes ACME (ar-

quitectura) y ArchJava (implementacion) . . . . . . . . . . . . . . . . 233.5. Componentes principales del sistema ArchEvol . . . . . . . . . . . . . 253.6. Ejemplo de un escenario de actualizacion arquitectura-implementacion

asistido por ArchEvol . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1. Diagrama de componentes para el ejemplo Model-View-Controller deGEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2. Diagrama UCM para el ejemplo Model-View-Controller de GEF . . . 344.3. Mapeos clase - componente . . . . . . . . . . . . . . . . . . . . . . . . 344.4. Mapeos metodo - responsabilidad . . . . . . . . . . . . . . . . . . . . . 344.5. Vista general de ArchSync . . . . . . . . . . . . . . . . . . . . . . . . . 364.6. UCM representando el comportamiento de ArchSync. . . . . . . . . . . 374.7. Identificacion de responsabilidades afectadas por cambios en el codigo

fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.8. Log de ejecucion transformado en una secuencia de activacion de re-

sponsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.9. Path-Log Matcher (paso #1). Ambos cursores coinciden. . . . . . . . . 424.10. Path-Log Matcher (paso #2). Ambos cursores coinciden. . . . . . . . . 424.11. Path-Log Matcher (paso #3). Ambos cursores coinciden. . . . . . . . . 424.12. Path-Log Matcher (paso #4). Los cursores no coinciden. . . . . . . . . 434.13. Path-Log Matcher (paso #5). Ambos cursores coinciden. . . . . . . . . 434.14. Path-Log Matcher (paso #6). Ambos cursores coinciden. . . . . . . . . 434.15. Path-Log Matcher (paso #7). Ambos cursores coinciden. . . . . . . . . 434.16. Alternativas de Actualizacion del UCM . . . . . . . . . . . . . . . . . 44

ix

x INDICE DE FIGURAS

5.1. Estilo data-centered para ArchSync en Eclipse . . . . . . . . . . . . . 485.2. Diagrama de paquetes de ArchSync . . . . . . . . . . . . . . . . . . . . 495.3. Diagrama de clase de source code ∆ . . . . . . . . . . . . . . . . . . . 505.4. Diagrama de secuencia para la deteccion de source code ∆ . . . . . . . 515.5. Diagrama de secuencia para la deteccion de paths posiblemente cam-

biados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.6. Diagrama de clases del componente Diff Mapper . . . . . . . . . . . . 525.7. Configuracion de ejecucion en Eclipse . . . . . . . . . . . . . . . . . . 535.8. Relacion entre ArchSync y FLABot mediante puntos de extension . . 535.9. Interaccion entre ArchSync y FLABot previa a la instrumentacion . . 535.10. Diagrama de clases de Log Analyzer . . . . . . . . . . . . . . . . . . . 545.11. Diagrama de clases de Path-Log Matcher . . . . . . . . . . . . . . . . 565.12. Representacion de paths en Prolog . . . . . . . . . . . . . . . . . . . . 565.13. Diagrama de secuencia de Path-Log Matcher . . . . . . . . . . . . . . 57

6.1. Arquitectura de G2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.2. UCM para la accion “eliminar usuario” . . . . . . . . . . . . . . . . . . 616.3. Analisis estatico de codigo fuente durante la deteccion de paths poten-

cialmente modificados . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.4. Paths potencialmente cambiados segun el analisis estatico de codigo

fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.5. Instrumentacion de la aplicacion G2 durante el caso de uso “eliminar

usuario” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.6. Seleccion de traza de ejecucion para analizar . . . . . . . . . . . . . . 626.7. Dialogo “Path-Log Matcher Result” . . . . . . . . . . . . . . . . . . . . 636.8. Primer sugerencia de insercion de la responsabilidad candidata ’ge-

tUserAgents(int):java.util.Vector’. En este caso, no se considera rele-vante arquitectonicamente. . . . . . . . . . . . . . . . . . . . . . . . . 64

6.9. Script de actualizacion para el path “eliminar usuario” . . . . . . . . . 646.10. UCM actualizado para la accion “eliminar usuario” . . . . . . . . . . . 646.11. UCM para la accion “salir del sistema” . . . . . . . . . . . . . . . . . . 656.12. Script de actualizacion alternativo para el UCM “salir del sistema” . . 666.13. UCM actualizado para la accion “salir del sistema” . . . . . . . . . . . 666.14. UCMs para la acciones “insertar fork”, “rotar fork” e “insertar respon-

sabilidad”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.15. Vista de ArchSync en Eclipse, mostrando el conjunto de paths de

FLABot identificados como posiblemente cambiados. . . . . . . . . . . 676.16. Script de actualizacion para el path “insertar fork” . . . . . . . . . . . 686.17. UCM actualizado para la accion “insertar fork” . . . . . . . . . . . . . 686.18. Dialogo “Path-Log Matcher Result”. . . . . . . . . . . . . . . . . . . . 696.19. Script de actualizacion para el path “rotar fork” . . . . . . . . . . . . . 696.20. UCM actualizado para la accion “rotar fork” . . . . . . . . . . . . . . . 696.21. Script de actualizacion para el path “insertar responsabilidad” . . . . . 696.22. UCM actualizado para la accion “insertar responsabilidad” . . . . . . . 696.23. Clases con mapeo cambiadas vs. paths afectados . . . . . . . . . . . . 716.24. Complejidad del path vs. alternativas de conciliacion . . . . . . . . . . 72

A.1. Arquitectura de Plug-ins de Eclipse . . . . . . . . . . . . . . . . . . . . 80A.2. Comunicacion entre Plug-ins de Eclipse . . . . . . . . . . . . . . . . . 80A.3. Esquema de funcionamiento de FLABot . . . . . . . . . . . . . . . . . 81A.4. Editor de componentes UML de FLABot . . . . . . . . . . . . . . . . 82A.5. Editor de UCM de FLABot . . . . . . . . . . . . . . . . . . . . . . . . 83

Indice de cuadros

2.1. Espectro de aplicacion de ADLs . . . . . . . . . . . . . . . . . . . . . . 10

3.1. Caracterısticas principales de los distintos enfoques . . . . . . . . . . . 27

4.1. Operaciones atomicas de actualizacion de UCMs . . . . . . . . . . . . 38

5.1. Ejemplo de log de ejecucion . . . . . . . . . . . . . . . . . . . . . . . . 55

6.1. Estado del proyecto ante cambios en la implementacion . . . . . . . . 716.2. Complejidad de los paths existentes y de las soluciones propuestas . . 72

xi

xii INDICE DE CUADROS

Indice de algoritmos

1. Violacion al estilo Model-View-Controller a nivel de codigo. La diver-gencia introducida por el desarrollador se subraya. . . . . . . . . . . . 35

2. Algoritmo Path-Log Matcher. . . . . . . . . . . . . . . . . . . . . . . . 393. Algoritmo Log Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . 54

xiii

xiv INDICE DE ALGORITMOS

Capıtulo 1

Introduccion

El desarrollo centrado en la arquitectura esta siendo ampliamente aceptado co-mo una practica de ingenierıa de software. Cada vez mas, tanto investigadores comoequipos de desarrollo reconocen que las arquitecturas de software son modelos muyconvenientes para hacer diseno de software [6], ya que estos modelos permiten a losdesarrolladores manejar la distancia entre requerimientos e implementacion en un altonivel de abstraccion. El valor de tener un modelo arquitectonico reside en que docu-menta los motivos principales del diseno en una etapa temprana del proceso de desa-rrollo, describe las estructuras principales del sistema en construccion y, por lo tanto,impacta la calidad final de los productos. Siguiendo esta lınea, los desarrolladoresnormalmente toman la descripcion arquitectonica del sistema y progresivamente larefinan hasta derivar una implementacion concreta. Durante esta actividad, tambienespecifican las relaciones entre el modelo arquitectonico como fue documentado y elmodelo arquitectonico como fue implementado [6, 16], para asegurar cierto grado deconsistencia entre los modelos. Actualmente existen varias notaciones y perfiles paraeste proposito [16].

1.1. Motivacion

Desafortunadamente, debido a la evolucion natural del sistema, es probable quela arquitectura e implementacion pierdan consistencia. Una vez que el diseno arqui-tectonico esta listo, comunmente todos los esfuerzos se enfocan en la implementacion,y esto desactualiza progresivamente la documentacion de diseno. Por ejemplo, nuevosrequerimientos pueden causar un rediseno de la arquitectura, con consecuentes cam-bios en algunas partes de la implementacion; y viceversa, tareas de mantenimientopueden producir cambios en el codigo que deberıan ser actualizados en la arquitec-tura. En estos casos, las relaciones de componentes (en el nivel arquitectonico) conclases y metodos (en el nivel de implementacion) no siempre se mantienen, y los desa-rrolladores deben restaurar manualmente la consistencia. Este fenomeno es conocidocomo corrimiento arquitectura-implementacion [32] o erosion arquitectonica, y si noes manejado apropiadamente, puede realmente perjudicar los beneficios del desarrollocentrado en la arquitectura.

Actualmente, el problema ha sido tratado por medio de algunos enfoques basadosen ingenierıa reversa, con resultados dispares. La falta de una herramienta de soportemas adecuada para relacionar especificaciones arquitectonicas con codigo sigue siendoun problema para muchos proyectos de software.

En este trabajo, proponemos un enfoque materializado en una herramienta desoporte llamada ArchSync, para asistir a los desarrolladores a conciliar la docu-mentacion arquitectonica con su implementacion a medida que la segunda cambia

1

2 CAPITULO 1. INTRODUCCION

con el tiempo. El enfoque ArchSync ha sido desarrollado en el contexto del proyectoFLABot, una herramienta de debugging que se basa en informacion arquitectonicapara aproximar las regiones de codigo donde es mas probable que se hayan origina-do las fallas (ver Apendice A.2). En particular, asumimos que existe alguna docu-mentacion arquitectonica previa a la codificacion del sistema. Los modelos arquitec-tonicos son representados con use case maps (UCMs)[11], una notacion practica paraespecificar tanto componentes como flujos de responsabilidades. Estas responsabili-dades son materializadas por clases y metodos en el codigo. Cuando algo cambia enel codigo y viola lo que fue prescripto por la arquitectura, ArchSync es capaz de lo-calizar esos cambios en la especificacion arquitectonica original. Para hacerlo, se debeinstrumentar el codigo de la aplicacion y registrar informacion acerca de su ejecucion.Para su analisis, ArchSync compara estos registros con la especificacion arquitectoni-ca, usando un conjunto de “filtros de reconstruccion”, y luego detecta que UCMs noson consistentes con el codigo. Ademas, ArchSync puede proveer una lista de posiblesreparaciones para los UCMs, que el desarrollador puede ejecutar para actualizar laarquitectura si es necesario. De esta manera, el desarrollador esta siempre conscientedel “estado de trazabilidad” entre la especificacion arquitectonica y el codigo.

1.2. Objetivos y restricciones

Como objetivo principal del trabajo se propuso encontrar diferencias entre unadescripcion realizada en UCMs y el codigo fuente de su implementacion. El analisisautomatizado de estas diferencias, ademas, se debe usar para asistir al usuario en lageneracion de una nueva version de los UCMs afectados donde esas diferencias hansido resueltas.

Por otro lado, el analisis de algunos trabajos similares puso a la luz ciertas ca-racterısticas que pueden dificultar la aplicacion de un enfoque de esta naturalezaen un proceso de desarrollo de software. Por esta razon se impusieron las siguientesrestricciones:

Limitar la informacion requerida del usuario a UCMs, codigo fuente e infor-macion que relacione elementos individuales de la arquitectura con porcionesde codigo. Toda informacion adicional debera ser derivable a partir del analisisautomatico de estos tres elementos dados como entrada.

No se debera imponer el uso de un lenguaje de programacion de propositoespecıfico, ni un estilo o un conjunto de convenciones de implementacion enparticular. De esta forma sera posible la aplicacion del enfoque a sistemas ex-istentes.

Tampoco se debera imponer un proceso demasiado estricto para la modificaciontanto de la arquitectura como del codigo. Ası, el desarrollador tendra el controlde cuando y como sincronizar los UCMs con la implementacion.

1.3. Organizacion del trabajo

El resto de este trabajo se encuentra organizado de la siguiente manera. En elcapıtulo 2 se presentan los conceptos de Arquitecturas de Software, Lenguajes de Des-cripcion de Arquitecturas (ADLs), Use Case Maps y Erosion Arquitectonica, que sonlas nociones principales en las que esta basado nuestro enfoque. Una vez introducidoel contexto, en el capıtulo 3 se analizan y comparan algunos trabajos relacionados que,de diferentes maneras, apuntan a solucionar el problema de erosion arquitectonica.

1.3. ORGANIZACION DEL TRABAJO 3

Luego de este analisis, en el capıtulo 4 se explica el enfoque ArchSync, detallandocada uno de los pasos que propone para la actualizacion de use case maps. Dado queel enfoque requirio la construccion de una herramienta de soporte, en el capıtulo 5 sepresentan su diseno y los aspectos mas importantes de su implementacion. A modode casos de estudio, se ejercito la herramienta implementada con el historial de desa-rrollo de G2 – una aplicacion comercial desarrollada en un proyecto de transferenciacon la empresa Delsat, S.A. – y de FLABot – una herramienta realizada dentro de unproyecto de investigacion. Mas adelante, en el capıtulo 6, se presentan los resultadosde estos casos de estudio. Finalmente, en el capıtulo 7 se presentan las conclusionesdel trabajo, junto con algunas propuestas para posibles trabajos futuros.

4 CAPITULO 1. INTRODUCCION

Capıtulo 2

Contexto

En este capıtulo se ofrecera una introduccion a los conceptos centrales sobre losque se ha realizado este trabajo. En primer lugar se define la nocion de Arquitecturade Software en la seccion 2.1, enfatizando la importancia de su documentacion den-tro de la organizacion y en particular para el equipo de desarrollo, para luego daren la seccion 2.2 una introduccion a los lenguajes de descripcion de arquitecturas(ADLs). En la seccion 2.3 se presentan los Use-Case Maps, una notacion simple yefectiva para la documentacion de comportamiento a nivel arquitectonico. Luego, enla seccion 2.4 se introduce un problema relacionado con las arquitecturas de softwareconocido como erosion arquitectonica, explicando las condiciones donde ocurre y lasgraves consecuencias que presenta para el desarrollo de software. Por ultimo, en laseccion 2.5 y a modo de resumen, se resaltan los conceptos clave detallados en estecapıtulo.

2.1. Arquitecturas de software

Si bien no existe una unica definicion de arquitectura de software universalmenteaceptada, generalmente todas lo hacen en funcion de conceptos comunes. En todasse encuentra la nocion de descomposicion de un sistema en diferentes partes, de rela-ciones existentes entre estas partes, de abstraccion de las propiedades que no seanexternamente visibles ni relevantes para la interaccion de sus elementos. Adicional-mente, se sabe que existen diferentes perspectivas desde las que se puede observar unsistema segun las propiedades de interes y que ninguna de estas vistas conforma laarquitectura en si. En su libro Software Architecture in Practice [6], Bass et.al. pro-ponen una definicion que abarca gran parte de las caracterısticas antes mencionadas:

La arquitectura de software de un programa o sistema de computacion esla estructura o estructuras del sistema, las cuales abarcan los elementosde software, las propiedades externamente visibles de esos elementos, ylas relaciones entre ellos.

Como se desprende de esta definicion, una arquitectura de software puede abarcar masde una estructura o vista. Un ejemplo que puede ilustrar esta propiedad es observarla estructura que presentan normalmente los proyectos de desarrollo. Generalmenteestos son particionados en modulos con una cierta cantidad de responsabilidadesfundamentales asignadas, que luego son asignadas a diferentes equipos para su desa-rrollo. Cada uno de estos modulos contiene programas y datos accesibles desde otroselementos, ademas de otros atributos que son privados. Este tipo de estructura seemplea a menudo para describir un sistema y define principalmente como se divide y

5

6 CAPITULO 2. CONTEXTO

asigna su funcionalidad, por esta razon, representa una perspectiva estatica. Por otrolado, existen estructuras que centran su atencion en como los elementos interactuanen tiempo de ejecucion para alcanzar la funcionalidad propuesta. Aquı el foco sepone sobre la manera en que los diferentes modulos interactuan para ejecutarse endiferentes procesos y como se comunican y sincronizan entre ellos. A pesar de queambas vistas aportan informacion sobre la arquitectura, ninguna de ellas la describeen su totalidad.

La definicion precedente tambien caracteriza a las vistas del sistema por estarcompuestas de elementos de software, de propiedades externamente visibles y derelaciones entre ellos. Esto implica que no es relevante en este nivel, y por lo tantose omite, la informacion de los elementos que no es pertinente a su interaccion. Jus-tamente por ser una abstraccion de un sistema complejo, la arquitectura de softwareoculta los detalles que no afectan la manera en que los diferentes elementos usan, sonusados por, se relacionan con o interactuan con otros elementos.

Una de las implicancias de la definicion de arquitectura, es su omnipresencia encualquier sistema de software, aunque esta no se encuentre documentada. Cualquiersistema posee elementos distinguibles con propiedades y relaciones asociadas, sinembargo no siempre existe alguien que conozca esta arquitectura, de aquı que resultemuy importante su documentacion.

Finalmente, de la definicion se deduce que el comportamiento de los elementos desoftware tambien forma parte de la arquitectura. Tal como ocurre con las propiedadesmeramente internas de los elementos de software, el comportamiento relevante en estenivel (y por lo tanto, integrante de la arquitectura) es aquel que afecte como los demaselementos tienen que ser escritos y de que manera deben comunicarse con el, comoası tambien aquellos que determinen el cumplimiento o no de alguna caracterısticadeseable en el sistema completo.

2.1.1. Documentacion

La documentacion de una arquitectura es una etapa crucial de su construccion.Incluso con una arquitectura excelente, si esta no es bien entendida y bien comunicada–en otras palabras, bien documentada– es muy probable que el proyecto falle[16].Si uno se toma el trabajo de crear una arquitectura robusta, debe describirla consuficiente detalle, sin ambiguedad y organizada de manera tal que los demas puedanencontrar la informacion que necesitan. Si no se logra esto, todo el esfuerzo habrasido en vano ya que la arquitectura no podra ser usada.

La documentacion de la arquitectura es tanto prescriptiva como descriptiva [6].Esto es, para desarrolladores con determinados roles, ella impone restricciones quedeben cumplirse al momento de tomar decisiones de diseno mas detallado. Para otrasaudiencias, su documentacion describe las decisiones tomadas sobre el diseno y porlo tanto, que cosas son ciertas sobre la arquitectura.

Quizas el concepto mas importante asociado con la documentacion de arquitec-turas de software es el de vista. Recordando la definicion de la seccion anterior, vemosa la arquitectura como “la estructura o estructuras del sistema, que abarcan los ele-mentos, sus propiedades externamente visibles, y las relaciones entre ellos”. Una vistaes una representacion coherente de esos los elementos importantes que constituyen unsistema, tal como lo son el software o el hardware, respecto a la forma en que los in-volucrados la leen y escriben. La vista provee el principio basico de la documentacionde una arquitectura de software:

Documentar una arquitectura significa documentar las vistas relevantesy luego agregar la documentacion que se aplica a mas de una vista.

2.1. ARQUITECTURAS DE SOFTWARE 7

Este principio es util porque separa el problema de la documentacion en las siguientespartes [16]:

Eleccion de las vistas relevantes. La eleccion depende de los usos que se le es-pera dar a la documentacion. A traves de estas vistas se deben expresar al menostres aspectos del sistema: (a) como esta estructurado el conjunto de unidadesde implementacion, (b) como esta estructurado el conjunto de elementos quetienen comportamiento e interacciones en tiempo de ejecucion y (c) como serelaciona con elementos de su ambiente que no son software.

Documentacion de una vista. Si bien no existe un template estandar de docu-mentacion de vistas, es esperable que contenga al menos la siguiente informa-cion:

1. Presentacion primaria: por lo general es un grafico; presenta los elementosprincipales y sus relaciones.

2. Catalogo de elementos: detalla los elementos y relaciones presentados enla presentacion primaria.

3. Diagrama de contexto: muestra como lo reflejado en la vista se relacionacon su ambiente usando el vocabulario de la misma.

4. Guıa de variabilidad: explica en detalle los puntos de variacion que sonparte de la arquitectura y estan explicados en esta vista.

5. Razonamiento arquitectonico: explica como el diseno reflejado en esta vistallego a ser como es.

6. Glosario de terminos.

7. Otra informacion.

Documentacion de comportamiento. Las vistas presentan informacion es-tructural del sistema. Sin embargo, esta informacion no es suficiente pararazonar acerca de ciertas propiedades del mismo. Exactamente que aspec-tos del comportamiento modelar va a depender del tipo de sistema quese esta disenando: en un sistema de tiempo real importan las propiedadestemporales de los eventos; mientras que en un sistema bancario las se-cuencias de eventos, las transacciones atomicas y los procedimientos derollback son lo mas importante.

Documentacion de la informacion que se aplica a mas de una vista. Cons-tituye el complemento de la documentacion de las vistas, es decir la informacionque se aplica a mas de una vista o al paquete de documentacion en sı. Consistede tres aspectos principales, el como, el que y el por que:

Como esta organizada la documentacion, de manera que los interesados en laarquitectura pueden encontrar la informacion que necesitan eficientemente.

Que es la arquitectura: una descripcion general del sistema para orientar allector acerca del proposito del sistema, la forma en que las vistas se rela-cionan entre sı, una lista de elementos y donde aparecen, y un glosario quese aplica a toda la arquitectura.

Por que la arquitectura es como es: el contexto del sistema, restricciones ex-ternas que han sido impuestas para darle forma a la arquitectura de ciertamanera, y el razonamiento para las decisiones de mayor granularidad yescala.


Figura 2.1: AcmeStudio

La documentacion de la arquitectura libera al arquitecto de tener que contestar cien-tos de preguntas acerca de ella. Para crear la documentacion, se deben entender atodas las partes interesadas y como esperan usarla. Por lo tanto, todos los interesadosdeben ser tenidos en cuenta a la hora de elegir las vistas relevantes.

2.2. ADLs

El desarrollo de software basado en arquitectura ha desplazado el foco de atencionsobre las “lıneas de codigo” hacia elementos arquitectonicos de mayor granularidad(componentes de software y conectores) y en la estructura de interconexion entreellos. Para soportar al desarrollo basado en la arquitectura, son necesarias notacionesformales de modelado y analisis junto con herramientas de desarrollo que operen sobrelas especificaciones arquitectonicas. Ante esta necesidad, se han propuesto los lengua-jes de descripcion arquitectonica (ADLs) y sus respectivas herramientas. Definido deforma general, “un ADL para aplicaciones de software se centra en la estructura dealto nivel de la aplicacion general en lugar de los detalles de implementacion de mo-dulos especıficos” [43].

Varios ADLs han sido propuestos para el modelado de arquitecturas tanto paradominios particulares como para propositos generales. Entre ellos podemos destacarAesop, ArTek, C2, Darwin, LILEANNA, MetaH, Rapide, SADL, UniCon, Weavesy Wright. Tambien se ha trabajado en un lenguaje de intercambio arquitectonicollamado ACME [21], para soportar el mapeo de especificaciones arquitectonicas entrediferentes ADLs y por tanto, permitir la integracion de herramientas de soporte comoAcmeStudio (Figura 2.1) [37]. Aunque ACME no es estrictamente un ADL, compartevarias de sus caracterısticas.

Sin embargo, aun no hay mucho consenso en la comunidad sobre lo que realmentees un ADL, que aspectos de una arquitectura deberıan ser modelados por un ADL yque deberıa ser intercambiado en un lenguaje de intercambio.

Recientemente Medvidovic et. al. [28] han propuesto una definicion en base a la de

2.2. ADLS 9

Figura 2.2: Framework de clasificacion y comparacion para ADLs. Caracterısticasesenciales de modelado se resaltan en negrita.

arquitectura de software presentada en la seccion 2.1, donde enuncian que “un ADLes un lenguaje que ofrece caracterısticas para modelar la arquitectura conceptual deun sistema de software, distinguida de la implementacion del sistema.” Los ADLsproveen tanto una sintaxis concreta como un framework conceptual para caracterizararquitecturas [20]. El framework conceptual refleja caracterısticas del dominio para elcual se pretende el ADL y/o el estilo arquitectonico. Este framework suele incluir lateorıa semantica detras del ADL en cuestion (por ejemplo, redes de Petri, maquinasde estado, etc.). A su vez, Medvidovic et. al. definen los requerimientos de un ADL yun framework de clasificacion: “un ADL debe modelar explıcitamente componentes,conectores y sus configuraciones; mas aun, para ser autenticamente util y usable,debe ofrecer una herramienta de soporte para el desarrollo y la evolucion basada enla arquitectura”.

Los elementos fundamentales de un ADL son los componentes, los conectores y lasconfiguraciones arquitectonicas. Para poder inferir cualquier tipo de informacion sobreuna arquitectura, al menos las interfaces de los componentes constituyentes debenmodelarse. Sin esta informacion, una descripcion arquitectonica se transformarıa enuna coleccion de identificadores interconectados, similar a los diagramas de “cajas ylıneas” sin semantica detras.

Si bien cada ADL tiene caracterısticas propias, todos comparten ciertos conceptosy estructuras principales:

Componentes. Representan los elementos primarios de un sistema, tanto computa-cionales como de almacenamiento de informacion. Ademas, los componentesconstan de interfaces, que son puntos especialmente designados para interac-tuar con el ambiente.

Conectores. Representan las interacciones entre componentes, es decir que actuancomo mediadores en la comunicacion y coordinacion de actividades entre com-


ADL ACME C2 MetaH Rapide UniCon

Foco Intercambio

arquitectonico,

predominante-

mente en el nivel

estructural

Arquitecturas de

sistemas

altamente

distribuidos,

evolutivos y

dinamicos

Arquitecturas

dentro del

dominio del

control,

navegacion y

asistencia

(GN&C)

Modelado y

simulacion del

comportamiento

descripto por

una arquitectura

Generacion de

codigo para

interconectar

componentes

existentes

utilizando

protocolos

comunes de

interaccion

Cuadro 2.1: Espectro de aplicacion de ADLs

ponentes. Tambien tienen interfaces, que definen los roles que los componentespueden cumplir en las interacciones que describen.

Sistemas. Pueden ser vistos como grafos o configuraciones de componentes y conec-tores. Pueden ser jerarquicos, de manera que los componentes y conectorespueden representar internamente subsistemas con diferentes arquitecturas.

Propiedades. Se usan generalmente para representar informacion semantica acercade un sistema que va mas alla de la estructura.

Restricciones. Representan reglas de diseno o sentencias invariantes que deberıanser ciertas a lo largo de la evolucion del diseno arquitectonico.

Estilos. Pueden ser vistos como familias de sistemas relacionados. Un estilo arqui-tectonico define basicamente un vocabulario de tipos de elementos de diseno yde reglas para componerlos.

En la Figura 2.2 se muestra el framework de clasificacion y comparacion para ADLspropuesto en [28]. Independientemente de la naturaleza del ADL (proposito especıficoo general), los tipos deseados de representacion, manipulacion y las cualidades de losmodelos arquitectonicos identificados en la Figura 2.2 se mantienen constantes. En elcuadro 2.1 se pueden ver los espectros de aplicacion de algunos ADLs muy difundidos.

2.3. Use-Case Maps

Los use case maps (UCM) son una notacion para diseno de alto nivel que ayudaa las personas tanto a expresar como a razonar acerca de los patrones de compor-tamiento de alta granularidad de un sistema [11]. El nombre proviene del hecho deque son una notacion visual para casos de uso y una extension de ellos hacia el disenode alto nivel. Sin embargo, el modelo no depende de la definicion de casos de uso:provee su propia definicion en sus propios terminos.

Los UCMs no son un lenguaje apropiado para especificacion formal de compor-tamiento, ya que deliberadamente dejan algunas decisiones abiertas para ser tomadasdurante el diseno detallado. Los UCM son solamente una notacion para razonar y ex-plicar el comportamiento de un sistema. Es importante de tener esto presente ya quees facil caer en la trampa de buscar o colocar mas informacion de la que correspondeencontrar en ellos.

2.3. USE-CASE MAPS 11

2.3.1. Notacion basica e interpretacion

A continuacion se da una breve descripcion de los diferentes elementos visualesque conforman la notacion, junto con los conceptos asociados a cada uno de ellos.La idea principal detras de los UCMs es la de modelar los casos de uso mediantesecuencias causales (en adelante, paths) a traves de estructuras organizacionales, deesta manera combinando vistas estructurales y comportamentales de la arquitecturadel sistema. Los UCMs tienen cuatro elementos principales: responsabilidades, paths,componentes y acoplamientos entre paths.

Responsabilidades. Expresan las funciones de las que cada componente esresponsable.

Paths. Trazan la progresion de causas y efectos entre responsabilidades.

Componentes. Actuan como contenedores de responsabilidades.

Acoplamientos. Sirven para conectar paths y ası lograr patrones de mayor granu-laridad.

And Forks. Indican la bifurcacion en dos paths concurrentes.

And Joins. Indican la union de dos paths concurrentes.

Or Forks. Indican el fin de un segmento causal comun entre dospaths.

Or Joins. Indican el comienzo de un segmento causal comun entredos paths.

2.3.2. Ejemplo

La Figura 2.3 muestra un ejemplo de UCMs, donde hay un simple escenario de“asignacion de nombre de usuario” para un sistema de manejo de cuentas de usuario.El sistema esta organizado alrededor de un estilo Model-View-Controller [13], en elcual el componente Model y sus componentes View estan desacoplados por mediode un componente Controller. La responsabilidad receiveWidgetEvent en Controllertraduce el evento producido por una View a la responsabilidad setUserName enModelo, la cual entonces activa la responsabilidad notifyModelObservers tambien enModel. Cuando se envıa una notificacion de cambio desde Model a Controller, estocausa la activacion de la responsabilidad handleModelChangeEvent, lo que finalmentedispara la actualizacion de View al ejecutar la responsabilidad updateView.


Figura 2.3: Ejemplo de UCM

2.3.3. Rol en la documentacion de arquitecturas

Documentar el comportamiento anade detalle semantico relacionado con el tiempoa los elementos y sus interacciones. Los modelos comportamentales agregan informa-cion que revela el orden de las interacciones entre los elementos, las oportunidadespara concurrencia, y las dependencias que tienen las interacciones con el tiempo.

Para atribuir comportamiento a elementos de una descripcion arquitectonica, esnecesario agregar“tejido conectivo”[9, 10]. Una forma de introducir este tipo de tejidoes usar conexiones que soportan interacciones (llamadas o mensajes) entre elemen-tos a traves de interfaces. Dichas interfaces definen los nombres y parametros detodas las posibles interacciones, ocultando detalles de la logica interna de los compo-nentes. A estas conexiones se les puede atribuir comportamiento al describir escena-rios de interaccion usando diagramas de interaccion UML (tambien conocidos comodiagramas de secuencia de mensajes). Sin embargo, la combinacion de conexiones,documentacion de interfaces y diagramas de interaccion muchas veces se excede encantidad de detalles -tales como operaciones, ensamblaje y estructura de herencia ensistemas orientados a objetos- y hace difıcil entender sistemas de cualquier tamano ycomplejidad. Es necesario tomar distancia de estos detalles para entender un sistemaen terminos arquitectonicos.

Los UCMs suben el nivel de abstraccion al simplificar los mas importantes factoresde complejidad:

Operaciones. Las secuencias de invocacion de operaciones son reemplazadas porpaths causa-efecto. El comportamiento no se representa en terminos de interac-ciones entre componentes a traves de mensajes, sino en terminos de secuenciascausa-efecto entre responsabilidades de los componentes. En otras palabras, lasinterfaces de los componentes, y las interacciones entre interfaces, tales comollamadas y mensajes, son consideradas detalles. Las responsabilidades puedenser de mayor granularidad que las llamadas y mensajes, y de esta manera sereduce el nivel de compromiso con los detalles.

Ensamblaje y Estructura de Herencia. A nivel de UCMs, el unico requerimien-to para la “conectabilidad” de un componente es que sea capaz de realizar lasresponsabilidades requeridas. Los detalles necesarios para realmente conectar(fısica o logicamente) un componente pueden ser diferidos hacia otro tipo dedocumentacion. A su vez, la dependencia de las descripciones de comportamien-

2.4. EROSION ARQUITECTONICA 13

Figura 2.4: UCM de un problema decontencion de recursos

Figura 2.5: UCM de una posiblesituacion de deadlock

to sobre los detalles como la estructura de herencia tambien es eliminada porel hecho de que los UCMs son modelos independientes de las descripciones declases.

Los UCMs pueden ser derivados a partir de requerimientos informales o de casos deuso, si estan disponibles. Las responsabilidades tienen que estar especificadas o serinferidas de estos requerimientos. Se pueden crear casos de uso separados para fun-cionalidades individuales del sistema o inclusive para escenarios individuales. Muchasveces, la forma de modelar una interaccion con UCMs depende de la intencion delarquitecto. Sin embargo, el fuerte de esta notacion reside principalmente en la in-tegracion de escenarios relacionados. En tales casos, los UCMs pueden usarse parailustrar y razonar respecto a concurrencia, como por ejemplo en problemas de con-tencion de recursos (multiples paths usando un elemento, como se muestra en laFigura 2.4) o posibles situaciones de deadlock (dos paths en direcciones opuestas atraves de al menos dos elementos en comun, como se muestra en la Figura 2.5).

2.4. Erosion arquitectonica

En la seccion 2.1.1 se explicaron las razones principales por las que la docu-mentacion de una arquitectura es fundamental para el desarrollo de software. Ladocumentacion es la vıa de comunicacion entre desarrolladores, y permite que el sis-tema se disene, implemente, pruebe, instale y mantenga siguiendo a la arquitecturaque lo sostiene.

Por otro lado, asegurarse de que un sistema sea construido en conformidad consu diseno arquitectonico durante su desarrollo, evolucion y mantenimiento es impor-tante, ya que divergencias significativas entre arquitectura e implementacion puedencomprometer la estructura, estilo y propiedades que han sido establecidas mediantecuidadoso analisis a nivel arquitectonico [1].

Durante las diferentes etapas del desarrollo de software, pueden producirse cam-bios en la documentacion arquitectonica que luego no son reflejados en el codigo(Figura 2.6), o cambios en el codigo que no son apropiadamente acomodados en ladocumentacion (Figura 2.7). Siendo la arquitectura una guıa fundamental durantetodo el ciclo de vida del sistema, el desfasaje entre documentacion e implementacionde una arquitectura se hara cada vez mas difıcil de remediar por sus desarrolladores,finalmente deteriorando la calidad del producto.


Figura 2.6: Cambio en la documentacion arquitectonica no reflejado en el codigo.

Figura 2.7: Cambio en el codigo no reflejado en la documentacion arquitectonica.

2.5. CONCLUSION 15

Durante la ultima decada, han sido desarrollados y aplicados varios modelos yanalisis de arquitecturas de software, para el estudio de la confiabilidad o la perfor-mance. Sin embargo, estos analisis de propiedades arquitectonicas pueden predecirla calidad del sistema siempre y cuando este haya sido implementado y mantenidode acuerdo a lo prescripto por la arquitectura. El desarrollo de un sistema de soft-ware confiable entonces necesita de la prevencion y correccion de violaciones a lasprescripciones arquitectonicas.

Desafortunadamente, debido a la evolucion natural del sistema, es probable que laarquitectura y la implementacion pierdan consistencia. Una vez que el diseno arqui-tectonico esta listo, tıpicamente todos los esfuerzos se focalizan en la implementacion,y esto hace que la documentacion se desactualice progresivamente. Por ejemplo,nuevos requerimientos pueden causar un rediseno de la arquitectura, con cambiosconsecuentes en algunas partes de la implementacion; y por otro lado, algunas tareasde mantenimiento pueden producir cambios en el codigo que deberıan ser reflejadosen modificaciones de la arquitectura. Si bien es aceptable que exista temporalmentecierto desfasaje, normalmente los desarrolladores trabajan en la implementacion sinmantener el modelo arquitectonico, el cual rapidamente queda desactualizado.

En algunos casos, los desarrolladores pueden introducir sutiles diferencias estruc-turales que invalidan intenciones claves de la arquitectura. Por ejemplo, en un sistemaestructurado en capas, es posible que un programador inadvertido genere dependen-cias no deseadas al saltear la capa inmediatamente inferior. Analogamente, en eldesarrollo de sistemas web multibanda es comun el error de invocar directamente ala base de datos desde la banda de presentacion. Como resultado, los arquitectos amenudo deben lidiar en sus analisis con conocimiento incompleto e incorrecto debidoa defectos en la documentacion [2]. En estos casos, las relaciones de los componentes(en el nivel arquitectonico) con clases y metodos (en el nivel de implementacion)ya no se mantienen, y los desarrolladores deben restablecer la consistencia manual-mente. Este fenomeno se conoce como corrimiento arquitectura-implementacion [32]o erosion arquitectonica. Si no se maneja correctamente, revierte los beneficios deldesarrollo centrado en la arquitectura, ya que se pierde la trazabilidad entre reque-rimientos, decisiones de diseno y artefactos de implementacion. Hasta hoy en dıa, elproblema ha sido atacado a traves de enfoques basados en ingenierıa reversa, con re-sultados dispares. La falta de herramientas de soporte adecuadas para generar codigopor medio de especificaciones arquitectonicas es todavıa un problema para muchosproyectos de software.

2.5. Conclusion

En este capıtulo se introdujo el concepto de arquitectura de software, una dis-ciplina que cumple un rol central en la toma de decisiones de diseno y en la co-municacion entre todos los participantes del desarrollo de un producto de software.Como vehıculo de comunicacion, su documentacion es fundamental, pues la falta deella, o peor aun, el descuido al producirla y mantenerla, anulan o revierten todos losbeneficios que el desarrollo centrado en la arquitectura puede aportar.

Posteriormente se presento la notacion de UCMs, un modelo para la descripcion depatrones de comportamiento y algunos aspectos estructurales en un alto nivel de abs-traccion y granularidad. Esta notacion es especialmente util para la documentacion decomportamiento a nivel arquitectonico, ya que permite expresar, analizar y comunicarlas trazas causa-efecto que proyectan los casos de uso sobre el sistema, dejando delado los detalles contextualmente irrelevantes.

En ultimo lugar se ofrecio una breve descripcion al problema de erosion arqui-


tectonica. Debido a la evolucion natural de un sistema de software, es muy probableque la arquitectura documentada y su implementacion pierdan consistencia, lo quepuede perjudicar todos los beneficios del desarrollo centrado en la arquitectura. Esteproblema ha motivado la creacion de herramientas que, mediante diversos enfoques,intentan mantener la consistencia documentacion-implementacion. El capıtulo sigu-iente se centra precisamente en estas herramientas.

Capıtulo 3

Trabajos relacionados

El problema de la erosion arquitectonica junto con la necesidad de prevenir ominimizar sus consecuencias han sido reconocidos en el capıtulo anterior como mo-tivadores principales de este trabajo. El desarrollo de software centrado en la ar-quitectura es una practica relativamente nueva que ha demostrado claramente susbeneficios cuando se pone en practica; principalmente en pos de la calidad del soft-ware en su ciclo de vida completo. Sin embargo, aprovechar sus ventajas demandaun costo: mantener la documentacion de la arquitectura consistente con su imple-mentacion [42]. Un desarrollo de software que pretenda basarse en una arquitecturasin propagar apropiadamente los cambios al resto de los modelos, en particular de suespecificacion arquitectonica, corre mayores riesgos de deteriorarse e incluso fracasar.

En este capıtulo intentaremos brindar una vision mas amplia sobre los distintosaportes existentes relacionados con la erosion arquitectonica, destacando los rasgosprincipales de cada enfoque.

3.1. Aportes relacionados

El problema de erosion arquitectonica ha sido tratado de diferentes maneras. Basi-camente, podemos reconocer dos grupos de enfoques: uno centrado en la recuperacionde la arquitectura a traves de tecnicas de ingenierıa reversa [34, 36, 38, 8, 18, 25, 44],y otro usando lenguajes de descripcion arquitectonica (ADLs) como soporte [2, 27].Podrıamos ver ambas tecnicas como enfoques correctivos y preventivos respectiva-mente.

Las soluciones basadas en la ingenierıa reversa pretenden reconstruir parcialmenteuna arquitectura en funcion de su codigo fuente o implementacion para compararlaposteriormente con la propuesta inicial del arquitecto. Suponiendo que un analizadorde codigo fuente fuera capaz de realizar el proceso inverso de abstraer y especificaruna arquitectura que represente fielmente lo que su materializacion implica, se estarıasolucionando el problema de inconsistencia entre ambos modelos, lo que significa tenera cada instante una arquitectura que refleja las propiedades principales del sistema.En otras palabras, podrıa controlarse la evolucion de la arquitectura permitiendodetectar erosiones en zonas no deseadas. Este es un posible camino para atacar elproblema de la erosion arquitectonica.

Por otro lado, es viable tambien tomar una postura conservadora, en el sentido deevitar torcer las restricciones impuestas por una arquitectura desde su concepcion.Siendo fundamental en el desarrollo centrado en arquitectura que toda etapa deimplementacion sea precedida por otra de diseno arquitectonico [7], sea este un ciclode desarrollo en cascada, evolutivo o iterativo; podrıa optarse por impedir, de algunamanera, que la implementacion viole o erosione, su arquitectura maestra.

17

18 CAPITULO 3. TRABAJOS RELACIONADOS

Lamentablemente ambas soluciones poseen inconvenientes. La tecnica esta limi-tada por la inherente diferencia entre estructuras estaticas (basadas en codigo, comoclases y paquetes) y las estructuras en tiempo de ejecucion, que son la esencia dela mayorıa de las descripciones arquitectonicas. Las estructuras pueden ser inclusodesconocidas hasta que el programa se ejecuta: clientes y servidores pueden aparecery desaparecer dinamicamente; componentes (por ejemplo, DLLs) fuera del controldirecto de los implementadores pueden cargarse dinamicamente, y ası podrıan enu-merarse otros ejemplos [44].

Tambien existe informacion semantica que se pierde cuando una arquitecturaes implementada mediante clases y metodos, haciendo imposible su recuperacionmediante ingenierıa reversa. Las representaciones generadas utilizando esta tecnicapueden aplicar informacion adicional provista por estandares como patrones, estilosarquitectonicos o incluso heurısticas para abstraer la informacion contenida en elcodigo, sin embargo esta representacion puede no ser necesariamente la pretendidapor el arquitecto.

Por otro lado, forzar el cumplimiento de las restricciones impuestas por la arqui-tectura tampoco es la solucion definitiva para la erosion arquitectonica, pues paradictar tales restricciones a una implementacion es necesario un lenguaje de especifi-cacion suficientemente rico en semantica y por lo tanto, de caracter mas formal, algoque en muchos proyectos puede resultar impracticable. Ademas, como veremos masadelante, las tecnicas basadas en ADLs suelen ser poco utiles cuando los cambios seproducen en la implementacion antes que en la descripcion arquitectonica.

3.1.1. Estrategias basadas en ingenierıa reversa

Los enfoques propuestos en [34, 36, 38], definen un conjunto de reglas que especifi-can la intencion del arquitecto, definiendo las relaciones permitidas y prohibidas entrelos componentes de software. Estas reglas pueden entonces ser usadas en cualquiermomento para realizar analisis estatico y/o dinamico sobre el codigo fuente paradetectar lugares donde las prescripciones arquitectonicas no son respetadas.

Sangal et.al. [36], por citar un ejemplo de esta clase, basan su enfoque en doselementos clave de la arquitectura de software: la descomposicion jerarquica de com-ponentes estructurales de un sistema y el control explıcito sobre las dependenciashabilitadas y deshabilitadas entre ellos. En base a tales elementos, el arquitecto cons-truye una Matriz de Dependencia Estructural (DSM) para representar la arquitecturade software como un grafo de dependencias, indicando cuales son posibles y cualesson “prohibidas”. Una matriz de ejemplo extraıda del trabajo puede observarse en laFigura 3.1. Esta representacion es informal y por otro lado, se representan exclusiva-mente los aspectos de interes para la sincronizacion.

Claramente este enfoque solo considera el aspecto estructural de una arquitectura.Las unidades atomicas de estos componentes son las clases Java y la abstraccion deestos se simplifica en funcion de la estructura jerarquica de paquetes Java del proyec-to, representando el paquete raız al sistema completo, esta es sin dudas una clarasimplificacion del mapeo entre arquitectura y codigo. Un posterior analisis estaticode codigo fuente detectara las dependencias existentes entre estos componentes, paracomparar la matriz DSM resultante con la especificada de antemano por el arquitec-to. Las dependencias etiquetadas como “prohibidas” por el disenador permiten a estaherramienta alertarlo ante estados durante el desarrollo donde la implementacion norespete estas restricciones. Ası, en caso de descubrirse relaciones de estas caracterıs-ticas en el analisis estatico, el equipo de desarrollo tendrıa la oportunidad de saberloy por tanto, de tomar acciones correctivas.

3.1. APORTES RELACIONADOS 19

Figura 3.1: Matriz de dependencia entre componentes de una arquitectura de capas.Los numeros indican la “intensidad” de la dependencia, calculada en funcion delnumero de referencias encontradas mediante el analisis estatico de clases en cadapaquete Java.

Richner [34] y Sefika et.al. [38] proveen mayor flexibilidad en ese aspecto, brindan-dole libertad al usuario para definir tanto la polıtica de clustering para los compo-nentes como las estrategias de analisis para diferentes tipos de relaciones por mediode reglas Prolog [40].

En el caso de Sefika et.al. [38], se utilizan modelos concretos como practicas re-comendadas de codificacion o diagramas de flujo de control, modelos arquitectonicosexpresados como patrones de diseno y modelos heurısticos como cohesion alta y bajoacoplamiento. La herramienta propuesta analiza, por ejemplo, una implementacionrespecto al estilo arquitectonico o al patron de diseno senalado por el usuario; perono es capaz de descubrir tales estilos o patrones. Se supone que el arquitecto conoceclaramente los patrones que aplico durante el diseno y es por ello que ahora podrıanecesitar contrastar su trabajo con la implementacion. Este primer analisis es decaracter estatico, sobre codigo C++ y de manera similar al trabajo anterior, detectarelaciones entre distintas clases. Sin embargo, en este caso las dependencias son com-paradas respecto a las que deberıan existir segun los roles que cada clase toma dentrode un patron de diseno especıfico. Tales dependencias son modeladas mediante unaserie de reglas Prolog. Guiado por los resultados del analisis estatico, la herramientapermite instrumentar la aplicacion aunque solamente dentro de un framework desa-rrollado especialmente, llamado µChoices, con el proposito de visualizar la conformi-dad con las mismas restricciones estructurales en tiempo de ejecucion, otorgando porende, un relativo control dinamico de la aplicacion.

Como desventajas podemos senalar la necesidad de indicar explıcitamente lospatrones de diseno aplicados, la dificultad impuesta para agregar nuevas reglas deanalisis en lenguaje Prolog, la incapacidad de trabajar con niveles altos de abstrac-cion y el limitado aprovechamiento en el analisis dinamico. Respecto a esta ultimaobservacion, el chequeo en tiempo de ejecucion es contrastado exclusivamente conaspectos estructurales de la arquitectura. No se analiza el comportamiento de la ar-quitectura ante diferentes escenarios funcionales pues estos nunca son especificadospor el arquitecto. La herramienta tampoco ofrece la opcion de sincronizar las posi-bles diferencias encontradas, es decir, no se modifica en consecuencia ninguno de losdos modelos: ni la arquitectura (estructura), ni el codigo fuente. El enfoque tampocosoporta integralmente el concepto de componente arquitectonico, sino que se centraen las clases C++ y en las relaciones existentes entre ellas.

Otros enfoques de recuperacion de arquitecturas tales como [8, 18, 25] intentanextraer la arquitectura del sistema directamente desde su codigo fuente. Quizas el en-


foque mas completo es el discutido por Medvidovic et.al.[25], donde las actividades deextraccion no solo se basan en el codigo fuente sino que ademas son complementadascon requerimientos y estilos arquitectonicos.

Mas recientemente, Yan et.al. [44] han desarrollado una herramienta llamadaDiscoTect que mapea eventos de bajo nivel del sistema a operaciones arquitectonicasabstractas; interpretadas luego por un motor especial que finalmente construye laestructura arquitectonica del sistema en tiempo de ejecucion como una descripcionACME [21]. La idea principal de este trabajo es traducir estilos de implementaciona estilos arquitectonicos. La traduccion se define conceptualmente como una red dePetri coloreada [22], empleada durante la ejecucion para interpretar los eventos debajo nivel y traducirlos cuando corresponda a eventos arquitectonicos, como porejemplo: creacion de componentes, establecimiento de conexiones entre ellos, etc. Loseventos de bajo nivel son instrucciones Java ejecutadas sobre una maquina virtual yse obtienen instrumentando el programa mediante AspectJ [23].

La arquitectura de DiscoTect puede observarse en la Figura 3.2. La red de Petricoloreada se obtiene como resultado de la compilacion de una especificacion escritaen un lenguaje especial llamado DiscoStep. DiscoStep fue disenado para permitir tra-ducir la ejecucion de instrucciones Java a eventos arquitectonicamente significativos,considerando que la aridad de esta relacion entre ambos tipos es n-m y que normal-mente los eventos de alto nivel pueden ocurrir simultaneamente cuando el sistemabajo analisis posee varios procesos o hilos de ejecucion concurrentes. Para que estaespecificacion DiscoStep sea efectiva, el programador debe seguir estrictamente losestilos de implementacion que permitiran construir correctamente la red de Petri co-loreada. Por ejemplo, si el sistema respeta el estilo arquitectonico cliente-servidor [13],el programador debera codificar las clases Java significativas para este estilo como“cliente”, “servidor” y “conexion cliente-servidor” con alguna convencion que ayude ala red de Petri a detectar estos eventos. Si la especificacion DiscoStep espera que elservidor sea representado por un socket TCP con el sufijo “ServerSocket”, el progra-mador debera seguir este estandar para que el mecanismo sea efectivo. Los autoresde esta herramienta aseguran bajo la condicion de que las implementaciones respetensiempre los mismos estilos, que DiscoTect puede monitorear diferentes sistemas sinque sea necesario modificar la especificacion del mapeo entre eventos de bajo nivel yeventos de alto nivel, es decir, el codigo DiscoStep.

Aunque este enfoque es interesante para visualizar la evolucion de una arquitec-tura durante la ejecucion de su implementacion, es importante hacer notar que estaevolucion se representa en terminos estructurales de la arquitectura, en otras pala-bras, como los componentes y sus conectores se reconfiguran entre si de acuerdo a lasdistintas situaciones que pueden ocurrir en el sistema. Los autores de DiscoTect hanreportado dos casos de estudio de sistemas legados, en los que recuperaron tanto unestilo pipe-and-filter como uno cliente-servidor. La herramienta todavıa necesita serevaluada con estilos arquitectonicos mas complejos, donde los mapeos a codigo no sonnecesariamente directos. Lamentablemente, al igual que en los trabajos anteriores, laherramienta no persigue como objetivo principal la sincronizacion de los modelosarquitectura - implementacion, sino descubrir y alertar posibles inconsistencias; porconsiguiente, esta labor debe ser realizada manualmente por el desarrollador. Ademas,ninguno de estos enfoques han considerado las extracciones de paths de funcionalidad,tales como los UCMs.

Focus [26] es el fruto de un enfoque tambien basado en ingenierıa reversa. Su ob-jetivo ultimo es extraer una descripcion estructural de la arquitectura en funcion dela informacion provista por su implementacion y el desarrollador. El codigo fuente deuna aplicacion es analizado estaticamente para obtener un diagrama de clases UML


Figura 3.2: Arquitectura de la herramienta DiscoTect

y luego las clases interrelacionadas son agrupadas en componentes. Este enfoquemantiene los mapeos entre arquitectura e implementacion durante la evolucion apli-cando el proceso de descubrimiento incrementalmente sobre las porciones de codigofuente modificadas. Los mapeos definen a los componentes como un grupo de clasesrelacionadas. El proceso de clustering para determinar los componentes utiliza dife-rentes polıticas, principalmente basadas en las relaciones de dependencia entre clasesJava. Los casos de uso son especificados por el arquitecto y luego chequeados parcial-mente en base a la inspeccion de codigo fuente. La Figura 3.3 ilustra las principalesactividades ordenadas parcialmente realizadas por Focus para recuperar una arqui-tectura. El enfoque es interesante para propagar cambios desde la implementacionhacia la arquitectura. La virtud principal, radica en refinar progresivamente la vistaarquitectonica en funcion de los cambios sucesivos del codigo, en lugar de intentarrecuperarla ıntegramente con un unico analisis exhaustivo. Como contras, se puedemencionar la escasa automatizacion (las abstracciones deben ser realizadas por elusuario, por ejemplo) y nuevamente, la falta de soporte para aspectos comportamen-tales de la arquitectura como es el caso de las representaciones UCM.

Un enfoque que aborda la especificacion UCM y emplea mecanismos de ingenierıareversa es el propuesto por Amyot et. al. [5] bajo el nombre de KLOCwork’s Archi-tecture Excavation method (KAE). Aunque el trabajo no tiene como objetivo directola sincronizacion de una vista arquitectonica con su correspondiente implementacion,algunas de sus caracterısticas lo acercan hacia este grupo de herramientas. KAE,extrae escenarios UCM a partir del analisis estatico de codigo C++. Su finalidad esayudar al nuevo desarrollador a comprender la arquitectura “escondida” detras deuna implementacion preexistente.

KAE utiliza una tecnica hıbrida basada en entrevistas (interviews) y etiquetado(tagging). Las entrevistas permiten obtener escenarios iniciales en base a charlas condesarrolladores involucrados y tambien mediante la inspeccion del codigo, por estarazon, esta tecnica es completamente manual. El etiquetado, tambien de caractermanual, es un proceso donde el desarrollador asocia etiquetas semanticas a diferentesporciones del codigo fuente; mas tarde estas etiquetas representaran responsabili-dades de distintos componentes de la arquitectura. KAE aproxima los casos de usoiniciales, en forma de trayectorias a traves de las diferentes etiquetas colocadas en elcodigo fuente. La herramienta ofrece un compilador para generar un modelo estruc-tural rudimentario de la arquitectura. Este modelo sera transformado iterativamentepara incrementar el nivel de abstraccion y para eliminar cualquier dependencia ınter-componente accidental.

La estructura estatica de la arquitectura es representada por medio de diagramas


Figura 3.3: Actividades principales del proceso de recuperacion de arquitecturas deFocus

de paquete UML: los paquetes simbolizan componentes y las dependencias entreellos, sus conexiones. Las conexiones entre componentes se detectan analizando lasdependencias entre clases C++ pertenecientes a diferentes paquetes. La abstraccionsubsiguiente del modelo queda a cargo del usuario, quien tiene a su disposicion paraeste proposito, dos operaciones: agregacion y ajuste. La agregacion permite seleccionardistintos bloques y agruparlos creando un nuevo nivel en la jerarquıa. El ajuste es otraoperacion visual donde se mueven bloques para eliminar dependencias entre paquetesde niveles mas altos que fueron introducidos por emplazamientos accidentales defuncionalidad a nivel de archivo. Como las etiquetas se aplicaron antes al codigofuente y este ya ha sido abstraıdo en componentes, la herramienta ahora es capaz degenerar Use Case Maps como trayectorias a traves de las distintas etiquetas colocadasen distintos puntos dentro de los paquetes (que ahora son vistos como componentes).

Aunque este es uno de los pocos enfoques que trabaja con las especificacionesUCM, se realizan demasiadas tareas manuales y otras tantas aplicando simplifica-ciones gruesas, que introducen errores extra, como es el caso de suponer que existe unadivision de componentes que coincide perfectamente con la estructura jerarquica depaquetes del proyecto, o crear trayectorias UCM en base al analisis estatico del codi-go, cuando en realidad la especificacion es inherentemente comportamental. Ademas,es el usuario quien determina en todo momento cuales son las responsabilidades y lastrayectorias de los distintos escenarios, limitando considerablemente la extraccion deinformacion.

3.1.2. Estrategias basadas en ADLs

Entre las soluciones a la erosion arquitectonica basadas en lenguajes de descrip-cion arquitectonicos, podemos mencionar el de Abi-Antoun et.al. [2], donde una es-pecificacion arquitectonica en el ADL ACME [21] es mantenida en sincronıa con unacontraparte implementada en ArchJava [3], aprovechando el hecho de que tanto enACME como en ArchJava los componentes y conectores son entidades de primera


Figura 3.4: Comparacion de estructuras jerarquicas de componentes ACME (arqui-tectura) y ArchJava (implementacion)

clase. Ambas vistas –la especificacion arquitectonica y la implementacion– son trans-formadas en instancias de una estructura de arbol en comun, que es luego comparadapara detectar cambios tales como inserciones, modificaciones y eliminaciones de no-dos, como puede apreciarse en la Figura 3.4.

Una de las principales ventajas mencionadas por sus autores es no solo la posi-bilidad de propagar los cambios desde la implementacion ArchJava hacia la descrip-cion ACME, sino tambien al reves, aunque en este caso, el script que concilia lasdiferencias solo es capaz de generar un esqueleto ArchJava. Los scripts de edicionque la herramienta produce para sincronizar ambas vistas deben ser complementa-dos manualmente por el arquitecto pues existen diferencias entre la representacioncomponente-conector (C&C) de cada modelo, como por ejemplo, tipos arquitectoni-cos, ausentes en ArchJava.

Desafortunadamente, esta sincronizacion no aborda el dinamismo arquitectoniconi la correspondencia de comportamiento entre la arquitectura y la implementacion.Ademas, debe tenerse en cuenta que si bien ArchJava es similar a Java, no es es-trictamente un lenguaje de programacion orientado a objetos ni mucho menos, unlenguaje empleado corrientemente por los equipos de desarrollo, dificultando ası laaplicabilidad en la industria.

Un trabajo pasado de Medvidovic et. al. [27] describe un ambiente basado encomponentes llamado DRADEL focalizado en el estilo C2 [24] que permite modelado,analisis y evolucion de arquitecturas basandose en un ADL que fue especıficamentedisenado para estas tareas (C2SADEL). La contribucion principal del trabajo es per-mitir la evolucion de componentes empleando subtipado heterogeneo, soportado porC2SADEL, la separacion de funcionalidad provista y requerida por medio de unaespecificacion formal, analisis de consistencia de una arquitectura, generacion de es-queletos para la implementacion de la arquitectura en base a su especificacion y laflexibilidad para soportar otros ADLs y otros estilos arquitectonicos. A pesar de estosaportes, el trabajo no pretende sincronizar una implementacion preexistente con suarquitectura sino garantizar la correctitud de la especificacion, facilitar su evoluciony definir las estructuras basicas para guiar a los programadores hacia una imple-


mentacion en conformidad con la arquitectura. Claramente, el enfoque es top-down,util cuando todos los cambios se aplican por primera vez sobre la arquitectura y a suvez, cuando la complejidad del sistema amerita el empleo de un lenguaje de especi-ficacion mas rico semanticamente y por lo tanto, mas formal. Desafortunadamente,el escenario mas comun sucede de manera contraria: se dedican mas esfuerzos a laimplementacion, y la documentacion suele ser pobre y desactualizada. Tampoco esclara la capacidad de la herramienta para propagar cambios hacia la implementacioncuando esta ya existe.

3.1.3. Estrategias basadas en SCM

Aunque esta familia de tecnicas es relativamente nueva, entre los enfoques o-rientados a SCM (Software Configuration Management) podemos encontrar algunostrabajos como ArchEvol [30], MAE [35], y MolhadoArch [29] entre otros, que proveenuna herramienta de soporte para el versionado de las relaciones entre arquitectura eimplementacion a lo largo del diseno, implementacion y deployment.

En el caso de ArchEvol, la herramienta presentada por Nistor et.al. [30]; se inte-gran en el entorno de desarrollo Eclipse [17] un modulo de versionado de proyectos(Subversion [33]) y un modulo de desarrollo guiado por arquitectura basado en C2(ArchStudio [41]). El esquema de ArchEvol puede verse en la Figura 3.5. El puntocentral consiste en tomar las ventajas ofrecidas por las herramientas de versionado ytrabajo concurrente sobre archivos, para hacer sistematico el proceso de introduccionde cambios en un sistema. ArchEvol propone un mecanismo donde la unica forma deintroducir un cambio (en la arquitectura o en la implementacion) es obteniendo la ver-sion del componente arquitectonico que se desea modificar, lo que a su vez impone aldesarrollador la necesidad de adquirir la version de la implementacion asociada parafinalmente colocar bajo administracion de configuracion los elementos modificados.

La solucion en este caso aborda el problema de mantener varias versiones parale-las de especificaciones arquitectonicas consistentes en relacion con su implementacion.De esta forma se permite la evolucion de la relacion entre los componentes de la ar-quitectura y el codigo fuente, lo que comunmente se conoce como mapeo, pero esel desarrollador quien debe actualizar manualmente ambas especificaciones. Un esce-nario de ejemplo ha sido representado en la Figura 3.6. La herramienta no es capaz,por ejemplo, de descubrir que la modificacion de un componente de la arquitecturaafecta a un subconjunto particular de las clases Java involucradas en el mapeo, sinoque lo asiste colocando automaticamente en su espacio de trabajo los elementos dela implementacion que potencialmente deberıan modificarse para ser coherentes conlos cambios en el componente arquitectonico en cuestion.

Las excelentes caracterısticas de soporte y agregado de plug-ins de Eclipse, entornodonde funciona ArchEvol, permiten que la herramienta cuente con la colaboracion decomponentes populares como son Subversion y ArchStudio, y presentan un escenariofavorable para el desarrollador respecto a otros enfoques, evitando que este debamigrar a un entorno desconocido, experimental y con escaso soporte ante la intencionde aprovechar las ventajas especıficas de sincronizacion.

En el caso de MAE [35], el enfoque es interesante desde el punto de vista de SCMpara versionar arquitecturas de software teniendo en cuenta sus particularidades,pero no soporta integralmente la evolucion de la implementacion ni el mapeo dearquitectura a codigo fuente.

MolhadoArch [29] posee caracterısticas similares a las de ArchEvol. Ofrece ca-pacidades de versionado tanto para la arquitectura como para los componentes indi-viduales de esta. Su mapeo arquitectura - implementacion comparte algunas carac-terısticas de ArchEvol pero es especıfico del entorno Molhado. La informacion arqui-


Figura 3.5: Componentes principales del sistema ArchEvol

Figura 3.6: Ejemplo de un escenario de actualizacion arquitectura-implementacionasistido por ArchEvol


tectonica puede importarse desde un archivo xADL, pero al realizarse, esta pasa aconvertirse al formato interno de representacion de Molhado, impidiendo que a partirde ese momento la arquitectura pueda editarse desde otras aplicaciones.

3.2. Resumen de caracterısticas principales

En la seccion 3.1 se analizaron individualmente las propuestas de los diferentesenfoques existentes para resolver en mayor o menor grado el problema de la erosionarquitectonica. Buscando ofrecer una mayor claridad al analisis de alternativas vin-culadas con el desarrollo de nuestro trabajo, se resumiran las caracterısticas massobresalientes de cada aporte y las desventajas detras de cada uno. Para tal proposi-to, el cuadro 3.1 presenta dichos aspectos, los que seran explicados y discutidos masadelante.

Las propiedades de cada enfoque resumidas en esta seccion son las siguientes:

Tipo: se refiere a la naturaleza del enfoque a grandes rasgos, como fueron pre-sentados en la seccion 3.1: basados en ingenierıa reversa, en ADLs o en SCM.

Analisis de la implementacion: se refiere al tipo de analisis (si existe) que serealiza sobre la implementacion del sistema. Este puede ser estatico, cuando seinspecciona (de manera automatica o manual) el codigo fuente correspondiente,o bien dinamico, en el caso donde la aplicacion es observada durante su ejecucionempleando algun mecanismo de instrumentacion.

Lenguaje de implementacion: se refiere al lenguaje de programacion en el quese espera que este codificado el sistema analizado por la herramienta.

Lenguaje arquitectonico: se refiere al lenguaje de descripcion de la arquitecturacon el que trabaja la herramienta.

Entorno: se refiere al ambiente especial necesario para el funcionamiento dela herramienta en cuestion, sin considerar compiladores o maquinas virtualesrequeridos por el lenguaje de implementacion. Este atributo es de interes a lahora de evaluar la practicidad de la herramienta en situaciones normales dedesarrollo.

Aridad del mapeo entre arquitectura e implementacion: se refiere a la aridadque existe entre un componente de la arquitectura considerada y un elementode la implementacion. Normalmente los elementos de la implementacion suelenser clases de objetos. Este atributo es importante en ciertos casos para analizarlas simplificaciones impuestas por el enfoque en cuestion.

Estrategia de analisis: da un breve resumen de las tecnicas empleadas paradetectar diferencias entre arquitectura e implementacion.

Aspecto a sincronizar: aspecto principal de la arquitectura considerada en elcontexto de la erosion arquitectonica. El aspecto considerado con mayor fre-cuencia, como se notara, es el estructural.

Direccion de los cambios: describe la habilidad del enfoque para propagar lainformacion desde un nivel de especificacion hacia otro para buscar la consis-tencia. Los niveles de especificacion considerados son el arquitectonico y el deimplementacion.

3.2. RESUMEN DE CARACTERISTICAS PRINCIPALES 27

Nom

bre

Tip

oA

nalisis

imple

-

men

taci

on

Len

g.im

ple

-

men

taci

on

Len

g.

arquitec

tonic

oEnto

rno

Aridad

mapeo

arq.-im

pl.

Est

rate

gia

analisis

Asp

ecto

a

sincr

oniz

ar

Direc

cion

cam

bio

sEsp

ecif.m

apeo

Sin

cro-

niz

aci

on

auto

matica

LSM

[36]

ingen

ierıa

reve

rsa

esta

tico

Java

DSM

Indep

.1

-n

Vio

laci

on

dep

enden

cias

Est

ruct

ura

-M

atr

izD

SM

No

Sefi

kaet

.

al.[3

8]

ingen

ierıa

reve

rsa

esta

tico

y

din

am

ico

C+

+Cla

ssdia

g.

µChoic

es1

-1

Model

os

concr

etos,

patr

ones

,es

tilo

s

arquitec

tonic

os,

heu

rıst

icos

Est

ruct

ura

-

Deb

e

conoce

rla

el

arquitec

to

No

Disco

tect

[44]

ingen

ierıa

reve

rsa

din

am

ico

Java

Acm

eIn

dep

.n

-m

Tra

ducc

ion

even

tos

imple

men

taci

on

-

even

tos

arquitec

tonic

os

Est

ruct

ura

din

am

ica

(en

tiem

po

de

ejec

uci

on)

-D

isco

Ste

pN

o

KA

E[5

]in

gen

ierıa

reve

rsa

esta

tico

C+

+U

CM

Indep

.1

-n

Etiquet

ado,agre

gaci

on,

aju

ste

Esc

enar

ios

funci

onale

s

arquitec

tonic

os

codig

o-

arquitec

tura

Etiquet

ado

No

Abi-A

nto

un

et.al.

[2]

AD

Les

tatico

Arc

hJa

vaA

cme

Indep

.1

-1

Com

par

aci

on

jera

rquıa

com

ponen

tes

Est

ruct

ura

bid

irec

cional

Arc

hJa

vaSi

DRA

DEL

[27]

AD

L-

Java

C2SA

DEL

Indep

.1

-1

Analısis

C2

basa

do

en

Teo

rıa

de

Tip

os

Est

ruct

ura

Arq

uitec

tura

haci

aco

dig

oC2SA

DEL

No

Arc

hEvo

l[3

0]

SCM

-Ja

vaC2

Ecl

ipse

,

Arc

hStu

dio

,

Subve

rsio

n

1-

m-

Est

ruct

ura

bid

irec

cional

Com

ponen

t

Pro

ject

sN

o

Focu

s[2

6]

ingen

ierıa

reve

rsa

esta

tico

Java

UM

LIn

dep

.1

-m

Clu

ster

ing

clase

s,

analisis

incr

emen

tal

asist

ido

por

elusu

ario

Est

ruct

ura

Codig

ohaci

a

arquitec

tura

Clu

ster

ing

sem

iauto

mati-

co

Si

Cuadro 3.1: Caracterısticas principales de los distintos enfoques


Especificacion del mapeo: indica cual es el recurso que emplea la herramientapara relacionar elementos de una arquitectura con su correspondiente imple-mentacion.

Sincronizacion automatica: indica si la herramienta posee caracterısticas deautomatizacion (completa o parcial) para propagar las diferencias de un modelohacia el otro.

Como observaciones de esta comparacion de caracterısticas, puede remarcarse el pre-dominio de enfoques que deciden tomar a Java como lenguaje para la implementacionque se pretende comparar con la arquitectura. De los dos trabajos que optan portomar C++ como lenguaje de programacion, el de Sefika et. al. [38] utiliza un en-torno de proposito especial para permitir la instrumentacion, mientras que KAE [5] noofrece analisis dinamico; necesario para extraer use case maps. La tercer herramientano implementada en Java es la desarrollada y presentada por Abi-Antoun et. al. [2],sin embargo optaron por emplear ArchJava, que no deja de ser una extension de Javacon la capacidad de representar entidades arquitectonicas. Esta caracterıstica comun,es decir, el lenguaje de implementacion bajo analisis, puede sugerir la convenienciade optar Java por sus caracterısticas conocidas de portabilidad y a su vez, el enormesoporte de la comunidad de desarrolladores y la disponibilidad de herramientas demultiples propositos escritos para trabajar con este lenguaje, como es el caso delentorno Eclipse.

Solo dos trabajos han decidido encaminar el analisis de la implementacion entiempo de ejecucion, en otras palabras, instrumentando la aplicacion. Sin embargoDiscoTect explota mejor la informacion que puede extraerse como consecuencia y escapaz de traducirlo a eventos arquitectonicos, algo que seguramente resultara crucialpara el enfoque ArchSync. Notar, en relacion a la observacion anterior, que para estaherramienta se opta por utilizar Java en la implementacion a causa del crecientenumero de frameworks que soportan la instrumentacion de aplicaciones escritas eneste lenguaje.

Los lenguajes de especificacion arquitectonica mas utilizados han sido ACME yC2, probablemente por ser muy difundidos, poseer las caracterısticas principales deun ADL y a su vez, no resultar excesivamente complejos como consecuencia de suformalidad, en especial ACME.

Respecto al aspecto a sincronizar, se nota una escasa cantidad de trabajos dedi-cados al aspecto comportamental de una arquitectura de software. De ellos podemosdestacar solo dos: DiscoTect [44] y KAE [5]. Aun ası, DiscoTect lo hace parcialmente,pues su objetivo continua siendo la estructura de la arquitectura, excepto que eneste caso el interes esta puesto en la evolucion a traves del tiempo, a medida que laaplicacion se ejecuta. En el caso de KAE se aborda la especificacion UCM, pero sehace por medio de un analisis estatico del codigo y con una dominante intervenciondel usuario.

La direccion de propagacion de cambios entre modelos de arquitectura e imple-mentacion, en los casos donde la herramienta la soporta, tiende a ser del codigohacia el nivel arquitectonico cuando la estrategia es la ingenierıa reversa mientrasque los orientados a los ADL normalmente lo hacen al reves, excepto el caso deAbi-Antoun et. al., donde es posible hacerlo en ambas direcciones. Cabe notar queesta familia de trabajos posee una capacidad limitada para sincronizar, en el sentidode crear o modificar una implementacion; en realidad la sincronizacion es manualpero se obtiene informacion para guiar al desarrollador que deberıa hacerla, o bien segeneran esqueletos incompletos de la implementacion para que el programador puedarealizar su trabajo minimizando los riesgos de violar restricciones estructurales arqui-

3.3. CONCLUSIONES 29

tectonicas. En el caso de ArchEvol, orientado al SCM, la direccion de los cambios esbidireccional pero es el arquitecto quien debe analizar que elementos del subconjuntosugerido deben modificarse. ArchEvol no sincroniza, sino que brinda la infraestruc-tura y asiste al desarrollador en la tarea.

Tambien es notable la escasa capacidad de sincronizacion automatica o semi au-tomatica ofrecida por las distintas herramientas. Solo dos se encuentran en condi-ciones de hacerlo: el enfoque de Abi-Antoun et. al. y Focus. El primero basado enArchJava y el segundo en Java; ambos dedicados al aspecto estructural de la arqui-tectura.

3.3. Conclusiones

En este capıtulo se han presentado los trabajos relacionados mas importantesque tratan la minimizacion de la erosion arquitectonica como objetivo principal. Enespecial se han discernido tres grandes grupos de soluciones, aquellas que recurren ala ingenierıa reversa para reconstruir la arquitectura subyacente, los que sujetan laimplementacion a las restricciones impuestas por las especificaciones arquitectonicasescritas en algun ADL y finalmente aquellas que aprovechan las herramientas de SCMcomo vıa para controlar las modificaciones en uno u otro modelo (el arquitectonico yel de implementacion). Se ofrecio una breve referencia a los trabajos mas importantes,con sus caracterısticas principales, ventajas y desventajas con respecto a la motivacionprincipal del trabajo, enunciada en la seccion 1.1.

Finalmente se compararon los atributos clave de cada enfoque de forma conjuntapara obtener las conclusiones que guiaran al analisis del enfoque ArchSync, presentadoa continuacion, en el capıtulo 4.

Capıtulo 4

El enfoque ArchSync

En este capıtulo se presenta el enfoque ArchSync, que propone la creacion de unaherramienta de soporte para la actualizacion semiautomatica de UCMs, usando paraello informacion de versionado de archivos de codigo fuente, junto con mapeos entreregiones de codigo y elementos arquitectonicos.

El resto del capıtulo se encuentra organizado de la siguiente forma. En la sec-cion 4.1 se presenta un breve analisis del problema y de los trabajos relacionados quedieron origen al conjunto de requerimientos para la creacion de ArchSync. Luego, laseccion 4.3 presenta el modelo conceptual de ArchSync, junto con una breve descrip-cion de cada uno de los elementos que interactuan para alcanzar la funcionalidadpropuesta. A continuacion, en la seccion 4.4 se muestra un ejemplo concreto de fun-cionamiento de ArchSync. Finalmente, en la seccion 4.5 se presentan las conclusionesdel capıtulo.

4.1. Analisis

El objetivo principal de ArchSync es encontrar diferencias entre una descripcionrealizada en UCM y su correspondiente codigo fuente dado como entrada, generandocomo salida una nueva version del UCM donde esas diferencias han sido resueltas.Como bien se detallo en el capıtulo anterior, existen actualmente varios enfoques paratratar el problema de erosion arquitectonica. Si bien no se centran especıficamente endocumentacion de comportamiento, su analisis detallado de cada uno nos permitiodetectar tanto caracterısticas no deseables, como tambien mecanismos y abstraccionesaplicables al caso especıfico de UCMs.

El analisis del problema en sı y de los trabajos relacionados puso a la luz algunascaracterısticas que hacen difıcil la incorporacion de ciertos mecanismos dentro deun proceso de desarrollo de software. Para evitar estos inconvenientes, ademas de laactualizacion de UCM se plantearon los siguientes objetivos secundarios:

Limitar la informacion requerida del usuario a UCMs, codigo fuente y mapeoresponsabilidad-codigo. Toda informacion adicional debera ser derivable a partirdel analisis automatico de estos tres elementos dados como entrada.

El uso de la herramienta no debera imponer el uso de un lenguaje de pro-gramacion de proposito especıfico, ni un estilo o un conjunto de convencionesde implementacion en particular. De esta forma sera posible la aplicacion delenfoque a sistemas legados.

Tampoco se debera imponer un proceso demasiado estricto para la modificaciontanto de la arquitectura como del codigo. Ası, el desarrollador tendra el control

31

32 CAPITULO 4. EL ENFOQUE ARCHSYNC

de cuando y como sincronizar los UCMs con la implementacion.

Como principales influencias para la concepcion de ArchSync se deben mencionar lostrabajos de Yan et.al. [44], Abi-Antoun et.al. [2] y Nistor et.al. [30].

Si bien los objetivos del enfoque son distintos, el analisis de eventos de bajo nivelmediante instrumentacion de codigo presentado en [44] fue un importante ejemplo de(a) cuanta informacion util se puede extraer de la ejecucion de una aplicacion y (b)que la aplicacion del enfoque no necesariamente debe requerir el uso de un lenguajede programacion para ese proposito especıfico.

Por otro lado, en [2] se plantea un modelo de actualizacion incremental en elque se supone un diseno arquitectonico y una implementacion inicial. Este enfoque,en contraste con la extraccion completa de un nuevo modelo arquitectonico a partirdel codigo, posee la ventaja de mantener el estilo de especificacion del arquitecto,ya que modifica la especificacion original solamente en las partes donde se producendivergencias con la implementacion.

Finalmente, el trabajo presentado en [30] ilustra las ventajas de integrar un en-foque para el tratamiento de erosion arquitectonica con sistemas de software confi-guration management.

4.2. Ejemplo: MVC

Como se menciono antes, una de las decisiones principales del enfoque ArchSyncha sido centrarse en las vistas comportamentales de una arquitectura, en particular,especificadas como UCMs. Para ayudar a comprender el enfoque en general que seexplica en este capıtulo, volvemos al ejemplo de la Seccion 2.3.2, basado en unaarquitectura que respeta el estilo definido en el Graphical Editing Framework (GEF)1 de Eclipse, un patron derivado del Model-View-Controller (MVC) [13].

El patron MVC se aplica en el contexto de aplicaciones interactivas que demandanun alto grado de interaccion con el usuario. Estos sistemas normalmente requieren unalto grado de flexibilidad, en especial sobre la interfaz de usuario, que debe adaptarsea las necesidades, muchas veces conflictivas, de los diferentes usuarios. En particular,MVC apunta a satisfacer las siguientes necesidades:

La misma informacion debe ser presentada de manera diferente

La representacion grafica y el comportamiento de la aplicacion debe reflejar lamanipulacion de datos inmediatamente

Cambios en la interfaz de usuario deben ser faciles de introducir, incluso, entiempo de ejecucion

El nucleo de la aplicacion (modelo) debe verse inalterado por el cambio deestilos o interfaces graficas

En el estilo MVC puro, normalmente el modelo representa los datos a ser mostrados,la vista es responsable de reflejarlos visualmente al usuario y el controlador es respon-sable de administrar las entradas del usuario, realizando cambios en el modelo cuandocorresponda y refrescando a la vista. En muchas implementaciones, las interfaces delos modelos son disenados especıficamente para la vista. Cuando la vista se dibuja,se comunica fuertemente con el modelo. Esto permite muchas optimizaciones, perohace difıcil el uso del par vista-modelo para situaciones que escapen al predefinido

1Eclipse GEF Project page: http://www.eclipse.org/gef/

http://www.eclipse.org/gef/

4.2. EJEMPLO: MVC 33

Figura 4.1: Diagrama de componentes para el ejemplo Model-View-Controller de GEF

por el disenador. Normalmente, el cliente de tales interfaces graficas siempre tieneque adaptar su modelo existente para ser compatible con el especıfico de la vista.

En GEF, normalmente no existe acoplamiento entre la vista y el modelo. Estosignifica que casi cualquier vista puede ser empleada para mostrar casi cualquiermodelo. No existe la necesidad de adaptar el modelo para que sea compatible conotra interfaz grafica. Aquı el mapeo vista-modelo puede no ser 1 a 1.

En la Figura 4.1 se presenta un diagrama con los tres componentes principalesde este patron arquitectonico, detallando en cada uno de ellos las responsabilidadesasociadas:

Modelo Representa los datos y la funcionalidad principal de la aplicacion. Proveeun mecanismo de registracion para los controladores. De este modo, permite lanotificacion de los cambios sufridos manteniendo la independencia del modelocon sus diferentes vistas.

Vista Provee informacion al usuario de manera visual y obtiene informacion delusuario mediante eventos (por ejemplo, clicks o movimientos de mouse, teclas,etc.). Obtiene sus datos del modelo. Cada vista posee un controlador. Unavista puede ser una composicion de varios elementos visuales y es trabajo delcontrolador construirlos y coordinarlos.

Controlador Traduce los eventos recibidos por la vista en operaciones sobre el mo-delo o la vista. Recibe notificaciones de cambio del modelo y es el encargado deactualizar las vistas.

En la Figura 4.2 se vuelve a introducir el escenario en forma de UCM. Se puedeobservar como esta notacion complementa a la vista estructural de componentes, yaque documenta sus roles e interacciones para cumplir con un caso de uso en particular.

Mapeo UCM - implementacion

Antes de proseguir con el ejemplo MVC es importante introducir el concepto demapeo entre la documentacion arquitectonica y su correspondiente implementacion.

Como se explico en la seccion 2.3.2, el comportamiento especificado a nivel arqui-tectonico toma distancia de los detalles de interaccion como las llamadas o mensajesentre componentes. En el lenguaje UCM, el comportamiento se representa en terminossecuencias causa-efecto entre responsabilidades de los componentes. Las responsabili-dades pueden ser de mayor granularidad que las llamadas y mensajes para reducir elnivel de compromiso con los detalles, por este motivo, una responsabilidad (funcionde la que es responsable un componente) puede ser materializada por varios metodose incluso clases de objeto a nivel implementacion. Por otro lado, una misma clase oun metodo particular de esta puede contribuir con la materializacion de diferentesresponsabilidades.


Figura 4.2: Diagrama UCM para el ejemplo Model-View-Controller de GEF

Figura 4.3: Mapeos clase - componente

En otras palabras, existe una correspondencia de aridad n:m entre una unidad decomportamiento a nivel arquitectonico, como lo es una responsabilidad UCM, y unaunidad de comportamiento a nivel implementacion, como lo son los metodos de unaclase. Tal relacion se denomina mapeo responsabilidad - codigo y es informacion quedebe proveer casi siempre el desarrollador a medida que implementa los componentes.El mapeo permite la trazabilidad entre la responsabilidad UCM de un componentey su implementacion. ArchSync depende en gran medida de esta informacion pararealizar las distintas operaciones que se describiran oportunamente en este capıtulo.

En la Figura 4.3 y la Figura 4.4 se muestra la correspondencia de la documentacionarquitectonica del caso de referencia y su implementacion en Java mediante talesmapeos. Si bien en este ejemplo las correspondencias clase-componente y metodo-responsabilidad son directas, es posible especificar casos mas complejos.

Figura 4.4: Mapeos metodo - responsabilidad

4.3. MODELO CONCEPTUAL 35

Continuando con el ejemplo de la arquitectura MVC, supondremos que en unaetapa posterior del desarrollo (por ejemplo, durante el mantenimiento), llega un nue-vo requerimiento, y ahora todas las operaciones efectuadas sobre el modelo debenser mostradas en un panel de historial de modificaciones. Ahora consideremos queun desarrollador que no esta al tanto del diseno arquitectonico es asignado al re-querimiento, y que inadvertidamente implementa una llamada al panel directamentedentro del modelo de usuario. El Algoritmo 1 ilustra una posible implementaciondel requerimiento. En vez de hacer uso del mecanismo de notificacion del modelo, seintroduce una dependencia en el modelo hacia el panel. Claramente, esto viola lasprescripciones impuestas por el estilo MVC al producir un acoplamiento perjudicialentre Model y View. A menos que hayan revisiones de codigo estrictas, este cambio(y otros similares) podrıan pasar desapercibidos por el resto de los desarrolladores.

Algoritmo 1 Violacion al estilo Model-View-Controller a nivel de codigo. La diver-gencia introducida por el desarrollador se subraya.

public class User {

...

public void setName(String newName) {

this.name = newName;

// cambio:historyPanel.append(‘Nombre de usuario modificado’);// fin del cambionotifyModelObservers(...);

}

...

}

4.3. Modelo conceptual

Para lograr la funcionalidad propuesta, ArchSync hace uso de un sistema decontrol de versiones y un conjunto de logs de ejecucion de la aplicacion. El sistema decontrol de versiones provee informacion acerca de las regiones de codigo que han sidocambiadas desde la ultima actualizacion del UCM, mientras que los logs de ejecucionrepresentan las trazas reales de ejecucion de la aplicacion en su estado actual. En laFigura 4.5 se presenta una vista general de ArchSync. Aquı, el “source code ∆” serefiere a los cambios en el codigo, el“UCM Φ”es la descripcion arquitectonica original,y el “UCM Φ + ∆” es la descripcion arquitectonica despues de la sincronizacion, encorrespondencia con el estado actual del codigo fuente.

Internamente, ArchSync esta equipado con una red de filtros que implementandiferentes tipos de procesamiento. La operacion de algunos de estos filtros requiereintervencion del usuario. A continuacion se da una breve descripcion de los filtros yde la informacion que toman como entrada y producen como salida:

Source Code ∆ Representa los cambios sufridos por el codigo fuente desde la ulti-ma actualizacion. Al ser una representacion abstracta que identifica elementosagregados, modificados y eliminados, es facilmente adaptable al modelo de codi-go fuente provisto por cualquier entorno de desarrollo con el que se integre elenfoque. A su vez, permite el analisis de varios lenguajes de programacion.

UCM Φ Representa la version desactualizada de la especificacion UCM, que ademascontiene mapeos responsabilidad-codigo. La notacion UCM es independiente dellenguaje de programacion, y al igual que en source code ∆, la representacion


Figura 4.5: Vista general de ArchSync

utilizada para los mapeos responsabilidad-codigo es adaptable a varios lenguajesde programacion.

Diff Mapper Analiza el source code ∆ para detectar un conjunto de paths potencial-mente modificados. Este filtro cuenta con una interfaz abstracta bien definida:toma un source code ∆ y un UCM Φ como entrada y como resultado identificael conjunto de paths que pueden verse alterados por los cambios en el codigo.Esto permite aprovechar todas las caracterısticas del lenguaje de programacionque lleven a un analisis mas exhaustivo sin que el enfoque pierda generalidad,ya que el filtro puede ser reemplazado sin afectar al resto de la implementacion.

Potentially Changed Paths Es el conjunto de paths potencialmente modificadosdesde la ultima actualizacion. Adicionalmente, en este conjunto de paths semantiene la trazabilidad con los elementos de source code ∆ que ocasionaronla identificacion de cambios en las responsabilidades.

Execution Logger Registra los eventos de bajo nivel que ocurren en la aplicacionmientras el usuario la ejercita con los casos de uso correspondientes a los pathsidentificados.

Execution Logs Son registros de las trazas reales de ejecucion de la aplicacion en suestado actual. Contienen informacion de bajo nivel, como llamadas a metodos,threads, creaciones de objetos, etc.

Log Analyzer Transforma la informacion de bajo nivel contenida en las trazas deejecucion en secuencias de responsabilidades, con ayuda de la informacion demapeo responsabilidad-codigo presente en UCM Φ. Estos ultimos tres elemen-tos del enfoque son dependientes del lenguaje de programacion de la aplicacionanalizada. Sin embargo, tanto la entrada de Execution Logger como la salidade Log Analyzer son abstractas. Por lo tanto, reemplazandolos en conjunto se


Use Case Map: UCM Diagram

s: Synchronizer

plm: PathLogMatcher

la: LogAnalyzer

el: ExecutionLogger

dm: DiffMapper

findModifiedCode

mapCodeToPathsexecuteUseCase

createExecutionLog

findMappedResponsibilities

createResponsibilitySequence

matchPathWithLog

createUpdateScript

selectUpdateScript

applyUpdateScript

Figura 4.6: UCM representando el comportamiento de ArchSync.

puede adaptar el enfoque a cualquier lenguaje de programacion que permitainstrumentacion de codigo.

Responsibility Sequence Representa una secuencia lineal de activacion de respon-sabilidades. Cada activacion contiene informacion de trazabilidad hacia loseventos de bajo nivel originales.

Path-Log Matcher Compara las secuencias de activacion de responsabilidades consus correspondientes paths, poniendo en evidencia los puntos donde hay diferen-cias y proponiendo acciones correctivas. Durante la exploracion de alternativasde conciliacion, se pueden aplicar reglas heurısticas que aprovechen la informa-cion de bajo nivel para descartar algunas opciones.

Update Scripts Corresponde a las secuencias de operaciones de transformacionatomicas que, aplicadas al path viejo, producen un nuevo UCM que correspondeal estado actual de la implementacion.

Synchronizer Aplica un update script seleccionado por el usuario sobre el UCM Φ.

UCM Φ + ∆ Representa la nueva version del UCM que se corresponde con la versionactual del codigo fuente. Surge de aplicar un update script sobre UCM Φ.

La Figura 4.6 resume el funcionamiento de ArchSync mediante un UCM.Como se menciono previamente, el UCM Φ tiene mapeos a codigo, pero muchos

de los mapeos pueden estar desactualizados en el source code ∆. Basado en estainformacion de mapeo entre elementos arquitectonicos y regiones de codigo fuente, elfiltro Diff Mapper esta a cargo de detectar todos los potenciales paths del UCM quepueden haber sido afectados por los cambios en el codigo. Dicha deteccion se realizaen varias etapas. Primero se identifican los archivos que han cambiado desde la ultimaactualizacion del UCM, para luego comparar la ultima version de cada uno de elloscon la version correspondiente a UCM Φ. Durante esta comparacion se analiza el


Accion Descripcionremove(targetNode) Elimina targetNode del pathinsertBetween(node1,

node2, newNode)

ellas

insertAfter(targetNode,

newNode)

Inserta newNode despues detargetNode en el path

transform(targetNode,

newType)

Transforma el tipo detargetNode a newType

Cuadro 4.1: Operaciones atomicas de actualizacion de UCMs

codigo y se identifican los elementos a nivel de implementacion (metodos y clases)que han sido eliminados, agregados y/o modificados. A partir de este punto, se utilizala informacion de mapeo entre responsabilidades y codigo para detectar el conjuntode responsabilidades que tienen relacion con el codigo cambiado. Finalmente, todoslos paths en los que aparece alguna de las responsabilidades relacionadas con loscambios son marcados como potencialmente cambiados.

Una vez que ha sido identificado el conjunto de paths “sospechosos”, los casos deuso correspondientes a cada uno de ellos son usados como casos de test para ejercitarel sistema y recolectar informacion acerca de su ejecucion. Asumiendo que el codigo hasido de alguna forma instrumentado, el filtro Execution Logger construye un conjuntode logs de ejecucion, que representan trazas de ejecucion del comportamiento real delsistema con respecto a los paths potencialmente cambiados. La instrumentacion estaa cargo de capturar diversos eventos de bajo nivel, tales como: llamadas a metodos,creaciones de objetos, threads, excepciones, etc. En este punto es imprescindible laintervencion manual del usuario ya que es necesario guiar la ejecucion de la apli-cacion, interactuando con ella de manera que se ejercite exactamente el caso de usocorrespondiente al path que esta siendo analizado.

Los mapeos a codigo de UCM Φ son tomados por el filtro Log Analyzer, queusa esta informacion para traducir los eventos de bajo nivel en una secuencia li-neal de activaciones de responsabilidades. A continuacion, el filtro Path-Log Matchertoma cada secuencia de responsabilidades y la compara con su path desactualizadocorrespondiente. A medida que el filtro realiza las comparaciones, este expone lasdiferencias entre el UCM Φ y el source code ∆ creando un conjunto de scripts deactualizacion. Un script de actualizacion es una secuencia de acciones atomicas quepermiten transformar UCMs, tales como las listadas en el cuadro 4.1. En principio,es importante tener en cuenta que hay muchas formas de representar el mismo com-portamiento del sistema con UCMs. Es por esto que el Path-Log Matcher produceun conjunto de scripts alternativos en vez de una unica actualizacion. Estos scriptsson priorizados basandose en la cantidad de cambios sobre el viejo UCM que cadauno aplica, suponiendo que los scripts cortos son mejores que los que tienen mayornumero de operaciones2. Entonces, el desarrollador es libre de seleccionar el scriptque encuentra mas apropiado para el caso especıfico de diseno arquitectonico.

En este punto, el filtro Synchronizer puede aplicar el script de actualizacion queseleccione el usuario sobre el UCM Φ para producir finalmente el UCM Φ + ∆. Deesta manera, los UCMs pueden ser puestos en correspondencia con los cambios en elcodigo fuente.

2Esta suposicion se basa en que, intuitivamente, el resultado de aplicar un script pequeno, alrealizar menos cambios sobre el UCM original, va a estar mas cerca del estilo de especificacion delarquitecto que el de uno mas grande.


4.3.1. Path-Log Matcher

Siendo la parte principal del enfoque ArchSync, en esta seccion se explica endetalle el funcionamiento del filtro Path-Log Matcher. El filtro toma como entradaun path potencialmente cambiado y una secuencia de activacion de responsabilidades(log o traza de nivel arquitectonico). El Algoritmo 2 correlaciona ambas entradas,realizando los cambios necesarios sobre el path desactualizado para que coincida conel log. Cada uno de los cambios realizados sobre el path es registrado en un script deactualizacion, que es retornado al finalizar el algoritmo.

Algoritmo 2 Algoritmo Path-Log Matcher.path-log-match(path: Path, log: Log)cursores := { path.nodoInicial }script := Øwhile log 6= Øcursor := seleccionarCursor(cursores)entradaLog := log.primeroif cursor.responsabilidad /∈ entradaLog.responsabilidades

accionCorrectiva := seleccionarAccion(path, cursor, entradaLog)script := script + accionCorrectivapath := corregirPath(path, accionCorrectiva)cursores := corregirCursores(path, cursores, accionCorrectiva)

elsecursores := avanzarCursor(cursor, cursores)log := eliminarPrimero(log)

end ifend whileif cursores 6= Øscript := script + eliminarSiguientes(cursores)

end ifreturn script

end path-log-match

El algoritmo se maneja alrededor de un conjunto de cursores, que marcan hastaque punto se ha avanzado sobre la correlacion y correccion del path desactualizado.Cada cursor apunta a una responsabilidad en el path que aun no ha sido correlaciona-da con una entrada en el log, e implica que todas las responsabilidades anteriores enla secuencia causal ya han sido correlacionadas o corregidas.

El script de actualizacion comienza vacıo, mientras que el conjunto de cursoresiniciales tiene un unico elemento que apunta a la responsabilidad inicial del path.Luego de la inicializacion, se toman las entradas del log una a una. Por cada una deellas, se selecciona un cursor y se busca la responsabilidad apuntada por el entre lasresponsabilidades candidatas. Si la responsabilidad no esta entre las candidatas, estoquiere decir que, en la traza real de ejecucion de la aplicacion, se ha activado unaresponsabilidad que no esta contemplada por el path en su estado actual, y que esnecesario tomar una accion correctiva. Las acciones correctivas posibles son:

Eliminar responsabilidad Elimina la responsabilidad actual, ya que es posibleencontrar la responsabilidad esperada entre las siguientes en el path.

Insertar responsabilidad Inserta una de las responsabilidades candidatas entre laresponsabilidad indicada por el cursor y la anterior en el path, de esta manerapermitiendo la correspondencia inmediata entre el log y el path.


Transformar responsabilidad Transforma la responsabilidad anterior a la indica-da por el cursor en un and fork e inserta una de las responsabilidades candidatasen una nueva rama del path, tambien permitiendo correspondencia inmediata.

Por otro lado, si la responsabilidad apuntada por el cursor esta entre las responsa-bilidades candidatas, se considera que el path y el log estan correlacionados en esepunto y por lo tanto se avanza el cursor y se elimina la entrada actual del log. Elprocedimiento para avanzar un cursor es diferente segun el caso:

Responsabilidad simple: el cursor avanza hacia la responsabilidad siguiente en elpath.

And Fork: el cursor es dividido en tantos cursores como ramas salientes tenga elpath en ese punto, que son posicionados en la primera responsabilidad de cadauna de ellas.

Or Fork: se avanza hacia la primera responsabilidad de solamente una de las ramassalientes del path en ese punto.

And Join: cada cursor que llega a un And-Join debe esperar ahı hasta que lleguenlos cursores de las demas ramas concurrentes. Una vez que han llegado todos,estos se fusionan en un solo cursor que avanza a la siguiente responsabilidad dela rama saliente.

Or Join: el cursor avanza normalmente. Si se llega al mismo Or-Join desde variasramas concurrentes, el path original posee un error semantico y se informa alusuario que debe corregirlo.

El algoritmo repite estas operaciones hasta vaciar el log, y finalmente, si los cursoresno han llegado al final del path, elimina todas las responsabilidades restantes. En estepunto, el script generado es uno que transforma el path dado como entrada en unoque corresponde correctamente a la secuencia de activacion de responsabilidades.

Es importante destacar que el script generado es solamente uno de los posiblesscripts que pueden poner al UCM en correspondencia con la traza de ejecucion dada.Para generar exhaustivamente todos los posibles scripts hay que reevaluar el algoritmotomando diferentes alternativas en los puntos de eleccion no-determinıstica que fueronmarcados en el algoritmo con cursiva y que se detallan a continuacion.

seleccionarCursor: Cuando se analizan ramas concurrentes de un path puede habermas de un cursor disponible en el conjunto y por lo tanto mas de una opcion.En el caso de un And-Join la opcion se descarta hasta que los cursores de todassus ramas hayan llegado.

seleccionarAccion: En este punto es donde mas opciones se presentan. Por unlado, hay que elegir entre alguna de las tres acciones correctivas presentadasanteriormente, mientras que por otro, en los casos en los que hay que insertaruna responsabilidad en el path, cualquiera de las responsabilidades candidatases una opcion.

avanzarCursor: En el caso de un Or-Fork se debe tomar solamente una de lasramas salientes. El no-determinismo esta en cual de ellas tomar.

En el capıtulo siguiente se explican algunas heurısticas que se aplicaron para evitar laprueba exhaustiva de todas las alternativas, tratando de encontrar primero los scriptsmas cortos.

4.4. RESOLUCION DEL EJEMPLO MVC 41

Figura 4.7: Identificacion de responsabilidades afectadas por cambios en el codigofuente

Figura 4.8: Log de ejecucion transformado en una secuencia de activacion de respon-sabilidades

4.4. Resolucion del ejemplo MVC

Volvamos al caso de referencia de la Seccion 4.2 para ver el funcionamiento deArchSync ante el problema planteado antes. Para tratar con este caso de desactualiza-cion de documentacion de diseno, ArchSync trabaja como se describe a continuacion.Primero, la herramienta es notificada de un cambio en el archivo User.java, que esanalizado en detalle para detectar que en realidad la modificacion fue sobre el metodosetName(). Ya que este metodo tenıa un mapeo con la responsabilidad setProperty,el filtro Diff Mapper la identifica como una responsabilidad afectada (ver Figura 4.7),y por lo tanto marca el path del ejemplo como potencialmente cambiado.

El desarrollador luego corre el caso de test sobre la implementacion actual delsistema, produciendo un log de ejecucion. Este log de ejecucion es, a su vez, procesadopor el filtro Log Analyzer, que genera una secuencia de activacion de responsabilidadescomo la presentada en la Figura 4.8. Los detalles del procesamiento para obtener estasecuencia implican la utilizacion del mapeo entre elementos de bajo nivel y elementosarquitectonicos, cuya implementacion se presenta en el capıtulo siguiente. Una vezgenerada esta secuencia de activacion de responsabilidades, el filtro Path-Log Matcherla compara con el UCM desactualizado. A continuacion se detallan los pasos de estacomparacion.

1. El cursor de log comienza en la primera responsabilidad activada –receive-WidgetEvent–, y el cursor de path en la primera responsabilidad del path –receiveWidgetEvent (Figura 4.9). Como las responsabilidades coinciden, amboscursores avanzan.

2. Cursor de log = handleWidgetEvent, cursor de path = handleWidgetEvent(Figura 4.10). Ambos cursores avanzan.


Figura 4.9: Path-Log Matcher (paso #1). Ambos cursores coinciden.


3. Cursor de log = setProperty, cursor de path = setProperty (Figura 4.11). Amboscursores avanzan.

4. Cursor de log = addLogEntry, cursor de path = notifyModelObservers (Figu-ra 4.12). El algoritmo registra la diferencia, y evalua alternativas de conciliacionsecuenciales y paralelas entre el path y el log. Avanza solamente el cursor delog.

5. Cursor de log = notifyModelObservers, cursor de path = notifyModelObservers(Figura 4.13). Ambos cursores avanzan.

6. Cursor de log = handleModelChangedEvent, cursor de path = handleMod-elChangedEvent (Figura 4.14). Ambos cursores avanzan.

7. Cursor de log = updateView, cursor de path = updateView (Figura 4.15). Fi-naliza el analisis.


4.4. RESOLUCION DEL EJEMPLO MVC 43

Figura 4.12: Path-Log Matcher (paso #4). Los cursores no coinciden.





Update script A: Update script B:

insertBetween(setUserName, \\ transform(setProperty, andFork)notifyModelObserver, addLogEntry) insertAfter(setProperty, addLogEntry)

↓ ↓

Figura 4.16: Alternativas de Actualizacion del UCM

Al finalizar la comparacion, Path-Log Matcher sugiere una lista de scripts de actua-lizacion. Algunos scripts aplicables al UCM desactualizado se muestran en la Figu-ra 4.16.

El primer script de actualizacion sugerido esta compuesto por una unica opera-cion, en este caso insertBetween. Esta instruccion inserta la responsabilidad addLog-Entry entre dos responsabilidades existentes en el path (setUserName y notifyModel-Obsevers).

El segundo, en cambio, esta conformado por dos operaciones: transform e insert-After. La primera transforma la responsabilidad setUserName en un nodo de tipoandFork. La ultima operacion inserta la responsabilidad addLogEntry despues delnodo setProperty, que fue transformado en el paso anterior. El resultado de estasecuencia de operaciones equivale a agregar un nuevo path paralelo al existente en elpunto donde se detecto la divergencia.

En este punto, se debe destacar que las dos soluciones propuestas por ArchSynccorresponden correctamente con la implementacion. En general, las variaciones en lassoluciones son debidas al hecho de que los UCMs son una notacion bastante abstracta,y por lo tanto dan una paleta de opciones para para representar el mismo caso de usoconceptual. Es por esto que, incluso cuando todas las soluciones generadas por Arch-Sync se consideran correctas, el arquitecto es responsable de elegir la solucion que esmas apropiada para el contexto real de diseno. Otra aclaracion relacionada es que lassoluciones a menudo sugieren cambios sobre los UCMs que comprometen la integri-dad del modelo arquitectonico. Por ejemplo, los scripts de actualizacion mostrados enla Figura 4.16 revelan un estilo de implementacion que viola el patron arquitectonicoMVC. En estos casos, el criterio del arquitecto juega de nuevo un rol fundamental. Elarquitecto puede elegir entre, por un lado, proceder aplicando la solucion propuestapor ArchSync y, por otro, decidir que el requerimiento que origino la inconsistenciadebe ser reimplementado de una forma acorde al estilo arquitectonico.


4.5. Conclusiones

En este capitulo se presento el enfoque ArchSync, que permite mantener la do-cumentacion arquitectonica, representada en forma de UCMs, actualizada a lo largodel desarrollo, evolucion y mantenimiento de una aplicacion. El enfoque utiliza infor-macion de mapeo entre elementos arquitectonicos y regiones de codigo fuente paratraducir los eventos de bajo nivel que aparecen en las trazas de ejecucion en ac-tivaciones de responsabilidades. Esa informacion se utiliza para analizar los pathsdesactualizados, finalmente produciendo una nueva version del UCM en la que lasdiferencias con el comportamiento real del sistema en desarrollo han sido eliminadas.

ArchSync es integrable con entornos de desarrollo que sean capaces de proveerinformacion de versionado de archivos de codigo fuente. Su modelo flexible de sin-cronizacion permite al desarrollador tener el control de cuando y como actualizar ladocumentacion arquitectonica. Por lo tanto, su utilizacion facilita la adopcion de unproceso de desarrollo centrado en la arquitectura, disminuyendo tiempo y recursos aser desviados de implementacion a documentacion.

Ademas ArchSync no impone restricciones de utilizacion de un lenguaje o conven-ciones de implementacion de proposito especıfico: el uso del lenguaje de programacionJava permite la aplicacion del enfoque en muchos sistemas existentes.

En el siguiente capıtulo se muestran en detalle algunos aspectos de la imple-mentacion.

Capıtulo 5

Diseno e implementacion

El presente capıtulo esta dedicado a la descripcion del diseno e implementacionde ArchSync. Para ello, su estructura y funcionamiento seran descriptos mediantediagramas de paquetes y de descomposicion de modulos a nivel arquitectonico y, anivel de diseno detallado, mediante diagramas de clases y de interaccion en notacionUML (Unified Modeling Language) [12], presentando los aspectos mas importantesde su implementacion.

El resto del capıtulo se encuentra organizado de la siguiente manera. En la sec-cion 5.1 se presenta la arquitectura de ArchSync. Luego, en las secciones 5.2, 5.3, 5.4y 5.5 se explican en detalle como fueron disenados e implementados los componentesDiff Mapper, Execution Logger, Log Analyzer y Path-Log Matcher, respectivamente.Finalmente, en la seccion 5.6 se presentan las conclusiones del capıtulo.

5.1. Arquitectura

Como ya se explico en los capıtulos anteriores, ArchSync es una herramientade natural integracion con entornos de desarrollo Java con soporte para control deversiones. ArchSync fue implementado como un plug-in de la plataforma Eclipse[17], aprovechando su arquitectura extensible, su funcionalidad expuesta de controlde versiones y su modelo para analisis estatico de codigo fuente Java. Ademas, estopermitio aprovechar el editor grafico de UCMs y el instrumentador de bytecode delproyecto FLABot, ya que ambos tambien fueron implementados como plug-ins [31].

El diseno de ArchSync esta muy influenciado por la arquitectura ya definida porEclipse. Esencialmente, Eclipse (ver Apendice A.1) es una plataforma disenada paraconstruir herramientas de desarrollo. Si bien la plataforma por sı misma no proveemucha funcionalidad al usuario final, facilita el rapido desarrollo de herramientas concaracterısticas integradas. Ası, la organizacion de estas herramientas alrededor deun espacio de trabajo comun es un principio de diseno central, tanto para Eclipsecomo para ArchSync. En el caso particular de este trabajo, es necesario un ciertonivel de integracion para aprovechar los componentes existentes de FLABot y la in-fraestructura basica de Eclipse. Por estas razones, la arquitectura de FLABot ha sidoorganizada mayormente alrededor de un estilo data-centered (centrado en los datos)[6]. La imposicion de este estilo ayuda a soportar los niveles de integracion antes men-cionados y ademas permite una evolucion casi independiente de las herramientas. Lafigura 5.1 ilustra el contexto de operacion de ArchSync.

En la Figura 5.2 se ilustra, mediante un diagrama de paquetes UML, como fueorganizado ArchSync en diferentes unidades de implementacion. Los cuatro paquetescentrales de la figura son los que fueron desarrollados en este trabajo. Ademas, eldiagrama especifica las relaciones de los paquetes propios de ArchSync con los pa-

47

48 CAPITULO 5. DISENO E IMPLEMENTACION

Figura 5.1: Estilo data-centered para ArchSync en Eclipse

quetes existentes que fueron reutilizados. El origen del resto de los paquetes se indicamediante estereotipos: < <eclipse> > para la plataforma Eclipse, < <flabot> > paraFLABot y < <javalog> > para JavaLog.

La funcionalidad propia de ArchSync se encuentra organizada alrededor de unestilo pipes and filters [6], donde los pipes se utilizan para conectar filtros y cada filtrotransforma a su salida la informacion recibida como entrada. El filtro Diff Mapperemplea el metamodelo Java (JDT) y la historia local de Eclipse (Local History) paradeterminar los paths de la especificacion UCM que pueden haberse visto afectadosen funcion de las modificaciones producidas en la implementacion del sistema.

Los escenarios marcados como “sospechosos” son tomados como entrada parael filtro Execution Logger, que luego registra los eventos de bajo nivel (llamadas ametodos, creacion de objetos, etc.) que ocurren en la aplicacion en funcionamientodurante su ejecucion. Execution Logger emplea los servicios del Bytecode Instrumentorde FLABot para poder monitorear la ejecucion de la aplicacion en las regiones quecorrespondan. Esta informacion se registra en un log de ejecucion, representado por unTrace Model, que luego es tomado como entrada por el siguiente filtro: Log Analyzer.Este se encarga de traducir las instrucciones ejecutadas por la maquina virtual Javaen una secuencia de activacion de responsabilidades UCM.

Finalmente, el filtro Path-Log Matcher toma como entrada las salidas de los fil-tros Diff Mapper (paths posiblemente desactualizados) y Log Analyzer (secuencia deresponsabilidades), y emplea un interprete Prolog (Prolog Interpreter) para la eje-cucion de un algoritmo de comparacion entre ambas. Como salida de este filtro seproduce un conjunto de scripts de actualizacion, donde cada uno de ellos representauna alternativa de conciliacion entre la especificacion UCM desactualizada y el esta-do actual del codigo fuente. Todos los componentes dependen de la informacion demapeo encontrada en el UCM Model, que representa a la especificacion que se intentasincronizar.

En la Figura 4.6 del capıtulo anterior se puede ver un UCM que resume la fun-cionalidad descripta.

5.2. DIFF MAPPER 49

Figura 5.2: Diagrama de paquetes de ArchSync

5.2. Diff Mapper

En el capıtulo 4 se presento brevemente al componente Diff Mapper como respon-sable de analizar el source code ∆ para detectar un conjunto de paths potencialmentemodificados. Diff Mapper debe procesar los cambios“recientes”producidos por un de-sarrollador en la implementacion, y utilizar esta informacion para analizar los UCMsexistentes en busqueda de paths funcionales que puedan haber perdido consistenciacomo consecuencia de tales cambios.

5.2.1. Source code ∆

La entrada principal para Diff Mapper son los cambios que han aparecido comoconsecuencia del desarrollo en el codigo fuente; en nuestro caso, proyectos Java. En laimplementacion inicial de ArchSync se opto por controlar exclusivamente los cambiosdirectos en la implementacion del sistema. Esto se debe a que la implementacion deArchSync depende de FLABot y este, solo permite el mapeo de metodos Java. Lasclases compiladas se excluyen tambien del analisis de Diff Mapper para simplificarsu implementacion.

ArchSync considerara como unidades de cambio, aquellos metodos Java que hayansido agregados, modificados o eliminados de una implementacion. Dicho de otro mo-do, la diferencia entre una implementacion Java en un tiempo t1 y esa misma imple-mentacion en un tiempo posterior t2 es el conjunto de metodos que se han agregado,modificado o eliminado del proyecto. Tal modelo de representacion de una diferen-cia entre implementaciones es llamado source code ∆ y puede verse reflejado en eldiagrama de clase de la Figura 5.3.

Diff Mapper tomara como entradas para determinar el source code ∆, el ultimomomento en que se sincronizo la implementacion con su representacion UCM, y porotro lado, el conjunto de proyectos sobre los que se aplicara la sincronizacion, es decir,el lugar donde ArchSync debera buscar metodos agregados, modificados o cambiados.

Para construir la representacion source code ∆, Diff Mapper realiza el trabajo endos etapas diferentes (Figura 5.4): primero detecta las clases afectadas por los cam-bios (interfaz IJavaClassDiffStrategy) y luego las analiza para descubrir los metodos


Figura 5.3: Diagrama de clase de source code ∆

agregados, modificados y eliminados (interfaz IJavaSourceDiffStrategy).En la primer etapa, se emplea la funcionalidad ofrecida por el modulo Local His-

tory de Eclipse, que permite recuperar las versiones anteriores de todos los archivosdel espacio de trabajo. Analizando la historia del proyecto a partir de la ultima fechaen que se sincronizo la implementacion con su representacion UCM es posible des-cubrir facilmente que clases han sido cambiadas, creadas o eliminadas. En vistas dela necesidad de independencia del analisis de codigo fuente del origen de los datos,se emplea aquı el patron de diseno Strategy [19]. La independencia de este algoritmode su interfaz publica permite que futuras implementaciones puedan utilizar otrosmodulos o recursos, por ejemplo, inspeccionando un repositorio CVS.

Durante la segunda fase, las clases descubiertas como modificadas por el algo-ritmo anterior son procesadas por la implementacion correspondiente a la interfazIJavaSourceDiffStrategy. Su funcion es detectar cuales de los metodos que conformanla clase han sido modificados, eliminados o agregados respecto a la ultima version sin-cronizada. En el caso de las clases eliminadas, todos sus metodos son marcados comoeliminados; de forma analoga ocurre con las clases agregadas. La implementacionactual, tambien independizada mediante el uso del patron de diseno Strategy, utilizala funcionalidad provista por el plug-in de Eclipse JDT, especıficamente, se espe-cializa la clase org.eclipse.jdt.core.dom.ASTVisitor. Esta implementacion se realizosobre la clase ASTMethodDeclarationVisitor, que especializa la clase anterior, basadaen el patron de diseno Visitor [19]. ASTMethodDeclarationVisitor recorre el arbol deparsing de una clase Java permitiendo procesar diferentes algoritmos segun el tipode nodo que se este “visitando”. En particular, el interes de esta clase son todos losmetodos y constructores del arbol de parsing que esta siendo comparado. Por cadametodo encontrado en una version del codigo fuente, se busca su contraparte en laversion posterior y de encontarse, se descubren modificaciones que puedan haberserealizado en su cuerpo.

5.2.2. IDiffMapper

La segunda fase del analisis estatico realizado por Diff Mapper es realizada por laimplementacion correspondiente a la interfaz IDiffMapper (Figura 5.5). La funciona-lidad principal es descubrir los paths UCM que han sido potencialmente alterados porel source code ∆ construido en la fase previa. La implementacion actual inspeccionacada uno de los paths que conforman el UCM y siguiendo su mapeo al codigo fuente,detecta si alguno de los metodos que materializan las responsabilidades es afectadodirecta o indirectamente por el source code ∆. Para ser mas precisos, una responsabi-lidad es afectada directamente cuando alguno de los metodos que la materializan hasido eliminado o modificado, en otras palabras, si se encuentra en el source code ∆.Por otro lado, una responsabilidad se considera afectada indirectamente si algunode los metodos que la materializan se relaciona mediante la jerarquıa de llamados

5.3. EXECUTION LOGGER 51

Figura 5.4: Diagrama de secuencia para la deteccion de source code ∆

Figura 5.5: Diagrama de secuencia para la deteccion de paths posiblemente cambiados

con un metodo encontrado en el source code ∆. La implementacion actual solo con-sidera aquellos metodos que llaman o son llamados por alguno de los metodos delsource code ∆.

Como resultado del analisis estatico de Diff Mapper, se obtiene una lista de pathsposiblemente afectados por los cambios en el codigo fuente, los que seran procesadosen las subsiguientes etapas. El diagrama de clase del componente puede apreciarseen la Figura 5.6.

5.3. Execution Logger

Como se expuso brevemente en el capıtulo anterior, este componente registra loseventos de bajo nivel que ocurren en la aplicacion mientras el usuario la ejercitacon los casos de uso correspondientes a los paths posiblemente cambiados. Para ello,se utilizo la infraestructura de instrumentacion de codigo de FLABot (apendice A,seccion A.2), ya que define un punto de extension para la configuracion de los eventosque deben ser registrados en tiempo de ejecucion.


IDiffMapper

getPotentiallyChangedUCMPaths...

IJavaSourceDiffStrategy

getDelta...

ASTMethodDeclarationVisitor

org.eclipse.jdt.core.dom.ASTParser

<<uses>>

org.eclipse.jdt.core.dom.ASTMatcher<<uses>>

org.eclipse.jdt.core.dom.AST

<<uses>>

org.eclipse.jdt.core.ICompilationUnit

org.isistan.flabot.javamodel.JBehavior

LocalHistoryJavaSourceDiffStrategy

<<implements>>

JavaClassDiffStrategy

runDif...

<<implements>>

org.isistan.flabot.coremodel.Path

org.isistan.flabot.coremodel.CoreModel IDelta<JBehavior>

0..n

1 2

<<compares>>

1

<<detects>><<detects>>

0..n

<<<<detects>>>>

<<<<searches on>>>> <<parameter>>

<<uses>>

org.eclipse.core.resources.IFileState

<<uses>>

Figura 5.6: Diagrama de clases del componente Diff Mapper

Basicamente, para la ejecucion de una aplicacion instrumentada es necesario (a)crear una nueva configuracion de ejecucion en Eclipse (launch configuration, Figu-ra 5.7) y (b) iniciar la ejecucion de esta configuracion. FLABot permite la especia-lizacion de la funcionalidad del modulo de instumentacion mediante el punto de ex-tension “org.isistan.flabot.traceConfigurationProvider”, que consiste en la definicionde dos interfaces abstractas: TraceConfigurationTab y TraceConfigurationProvider,responsables de los puntos (a) y (b) respectivamente. Las implementaciones de laprimera interfaz se encargan de permitir al usuario configurar de manera grafica lainformacion necesaria para la creacion del log de ejecucion (ubicacion el archivo desalida, tipos de eventos a registrar, etc.), mientras que las de la segunda proveen estainformacion al modulo de instrumentacion. La relacion entre ArchSync y FLABotpor medio de puntos de extension se resume en la Figura 5.8.

Una vez definida la extension, la interaccion entre FLABot y ArchSync es relati-vamente simple. Cuando la aplicacion a instrumentar esta a punto de ser ejecutada,se crea una instancia de ArchSyncTraceConfigurationProvider a la que se le interrogaacerca de que eventos deben ser registrados durante la ejecucion. A su vez, el objetoutiliza los mapeos del UCM desactualizado y el resultado del analisis realizado porDiff Mapper, para indicar que debe ser registrada la ejecucion de tanto los meto-dos asociados directamente a alguna responsabilidad como los metodos agregados omodificados que afectan indirectamente. Esta interaccion se detalla de manera grafi-ca en el diagrama de secuencia de la Figura 5.9. Una vez provisto de la informacionnecesaria, FlabotInstumentationLaucher se encarga de ejecutar la aplicacion instru-mentada y de registrar los eventos necesarios en el archivo que fue indicado durantela configuracion.

5.3. EXECUTION LOGGER 53

Figura 5.7: Configuracion de ejecucion en Eclipse

Figura 5.8: Relacion entre ArchSync y FLABot mediante puntos de extension

Figura 5.9: Interaccion entre ArchSync y FLABot previa a la instrumentacion


Figura 5.10: Diagrama de clases de Log Analyzer

5.4. Log Analyzer

Una vez que fue creado un log de ejecucion para un caso de uso en particular,Log Analyzer se encarga de interpretar los eventos de bajo nivel contenidos en el logpara transformarlo en una secuencia de activacion de responsabilidades. El proceso detransformacion fue abstraıdo mediante una interfaz abstracta para permitir la pruebacon diferentes heurısticas sin que los cambios se propaguen en el resto del sistema,como se muestra en la Figura 5.10.

Para hacer esta transformacion, el componente utiliza la informacion de mapeoentre responsabilidades y metodos como se muestra en el Algoritmo 3.

Algoritmo 3 Algoritmo Log Analyzerlog-analyzer(log: Log, mappings: Mappings)secuenciaActivaciones := ØultimaActivacion := nullfor entradaLog in log

responsabilidades = mappings.getCandidatas(entradaLog)if (ultimaActivacion 6= null) and

(responsabilidades ∩ ultimaActivacion.responsabilidades 6= Ø)ultimaActivacion.responsabilidades :=responsabilidades ∩ ultimaActivacion.responsabilidades

elseultimaActivacion = new ActivacionultimaActivacion.responsabilidades := responsabilidadessecuenciaActivaciones := secuenciaActivaciones + ultimaActivacion

end ifend forreturn secuenciaActivaciones

end log-analyzer

El algoritmo recorre el log de ejecucion, tomando sus entradas (ejecuciones demetodos) una a una. Dado que el mapeo responsabilidades-metodos es N:N, cadaentrada puede corresponder a un conjunto de responsabilidades candidatas. Una vezque obtuvo este conjunto, verifica si su interseccion con la ultima activacion (entradade log de alto nivel) no es vacıa. Si esto es ası, actualiza la activacion con la inter-seccion. Si la interseccion es vacıa, crea una nueva activacion y pasa a la entradasiguiente.

A modo de ejemplo, supongamos el log de ejecucion del Cuadro 5.1. En la primeraiteracion del algoritmo, se crea una nueva activacion con las responsabilidades {r1,r2, r3}. Luego, esta misma activacion se reduce al conjunto {r1, r3}. En la tercera

5.5. PATH-LOG MATCHER 55

Metodo ejecutado Responsabilidades candidatasa() {r1, r2, r3}b() {r1, r3, r4}c() {r2}d() {r2, r3}

Cuadro 5.1: Ejemplo de log de ejecucion

iteracion, se crea una nueva activacion con el conjunto {r2}, que en la iteracion finalno es modificada. La secuencia de activaciones resultante es {{r1, r3}, {r2}}, y seinterpreta de la siguiente manera: primero se activo r1 o r3, luego se activo r2.

5.5. Path-Log Matcher

El modulo Path-Log Matcher es la parte central del enfoque ArchSync. Este tomacomo entradas un UCM desactualizado y una secuencia de activacion de responsabi-lidades, realiza una comparacion entre ambas y finalmente, si encuentra diferencias,produce como salida un conjunto de alternativas de conciliacion.

Como se explico en el capıtulo anterior, el algoritmo Path-Log Matcher poseevarios puntos cuyo comportamiento esta gobernado por reglas: el procedimiento paraavanzar un cursor segun el tipo de nodo, las acciones correctivas posibles segun eltipo de inconsistencia, la eleccion del cursor a comparar, etc. Ademas, en cada puntodonde las reglas presenten mas de una alternativa valida es necesario reevaluar cadauna de ellas hasta alcanzar una solucion. Por otro lado, al tratarse de un prototipo,era sabido de antemano que serıa necesario experimentar con diferentes reglas decomportamiento hasta encontrar un conjunto relativamente estable.

Path-Log Matcher fue implementado usando JavaLog [4], una integracion de Javay Prolog. Esto permitio la especificacion del algoritmo en Prolog, un lenguaje en elque resulta mas natural la programacion de reglas y la reevaluacion de alternativas.Ademas, al ser un lenguaje interpretado, fue posible probar diferentes combinacionesde reglas con diferentes prioridades sin necesidad de recompilar y reiniciar el pro-totipo.

En la Figura 5.11 se muestra un diagrama de clases que ilustra como fue estruc-turado el modulo:

PathLogMatcher: actua como fachada del modulo, utilizando el patron de disenoFacade [19]. Posee un metodo pathLogMatch que recibe un path y una secuenciade activacion de responsabilidades como parametros y devuelve un conjunto descripts de actualizacion.

JavalogConverter: se encarga de convertir los parametros de entrada en estruc-turas Javalog (ver Figura 5.12). Para realizar esta tarea, abstrae la creacion delos distintos tipos de estructuras por medio de la utilizacion del patron de disenoAbstract Factory [19]. Una vez resuelto el algoritmo, convierte las estructurasJavalog generadas en scripts de actualizacion.

ArchSyncJavalogEngine: es responsable de interactuar directamente con Javalogpara obtener los resultados. Suministra el conjunto de reglas prolog definidasen pathLogMatch.pl y los parametros recibidos como entrada a Javalog, paraluego interrogarlo hasta obtener todas las alternativas de conciliacion.


Figura 5.11: Diagrama de clases de Path-Log Matcher

Path:

Representacion en Prolog:

path([node(node1, r, role1, ’C1’, andFork),node(node2, r1, role2, ’C2’, simple),node(node3, r2, role2, ’C2’, simple)], [link(node1, node2),link(node1, node3)

])

Figura 5.12: Representacion de paths en Prolog

Brain: actua como fachada de Javalog, tambien segun el patron Facade [19]. Sim-plifica la tarea de cargar y eliminar reglas de la base de datos, realizar queriesy obtener resultados ofreciendo los metodos necesarios en su interfaz.

Cuando se invoca a Path-Log Matcher, el componente actua como se muestraen el diagrama de secuencia de la Figura 5.13. Primero, PathLogMatcher conviertelos parametros recibidos como entrada en estructuras Javalog mediante JavalogCon-verter. Luego, invoca a ArchSyncJavalogEngine, que carga las reglas contenidas enpathLogMatch.pl y las agrega a la base de datos de Brain. Una vez que las reglas es-tan cargadas, se reevalua el query principal del algoritmo hasta que este falla, de estaforma obteniendo de manera exhaustiva todas las alternativas de conciliacion. Fi-nalmente, PathLogMatcher utiliza a JavalogConverter para convertir las estructurasJavalog obtenidas como resultado en scripts de actualizacion.

5.6. Conclusiones

En este capıtulo se describieron los aspectos mas importantes acerca de la arqui-tectura, diseno detallado e implementacion de ArchSync. La herramienta requiere lacolaboracion de componentes pertenecientes a otros sistemas, mas especıficamenteEclipse, FLABot y JavaLog.

Eclipse fue seleccionado principalmente por ser el entorno de desarrollo Java maspopular en la actualidad y ademas, por brindar una arquitectura preparada para laintegracion de herramientas mediante extensiones. En segundo lugar, Eclipse ofreceun metamodelo del lenguaje Java idoneo para la manipulacion de informacion de


Figura 5.13: Diagrama de secuencia de Path-Log Matcher

codigo fuente. Las estrategias definidas en el modulo Diff Mapper hacen uso de es-ta infraestructura para detectar clases eliminadas y modificadas, ası como para lacomparacion de versiones diferentes de clases Java. Aunque la version actual de DiffMapper emplea la historia local de Eclipse como repositorio de clases modificadas yeliminadas, se tomaron las precauciones necesarias para que pueda hacerlo utilizandootros recursos, como repositorios CVS, Subversion, etc.

FLABot, por otro lado, se emplea por dos razones centrales: ofrece un editor UCMcon soporte para mapeo responsabilidad-codigo y ademas incluye soporte para instru-mentar aplicaciones. El motor de instrumentacion de aplicaciones FLABot genera unlog de bajo nivel que es procesado por el componente Log Analyzer para construirun registro de responsabilidades activadas.

El algoritmo Path-Log Matcher se materializo en Prolog, por resultar el paradigmade la programacion logica mucho mas natural a la hora de especificar la comparacionentre el UCM desactualizado y la secuencia de activacion de responsabilidades. Sinembargo, en vistas de que la mayor parte de ArchSync se implemento en Java, fuenecesario integrar este paradigma con el de la programacion orientada a objetos. Paratal fin, JavaLog resulto ideal pues ha sido concebido con tales objetivos.

De esta forma, si el equipo de desarrollo pretende incorporar la nueva tarea desincronizacion entre implementacion y especificacion UCM a sus tareas rutinarias,podra hacerlo incluyendo unicamente el plug-in ArchSync para Eclipse y sus depen-dencias, es decir: FLABot y JavaLog. En la mayorıa de los casos, este requerimientoimplica que los programadores no necesitaran nuevas herramientas de desarrollo, nisiquiera repositorios para el control formal de versiones.

En el proximo capıtulo se analizara el desempeno de ArchSync ante dos sistemasreales en desarrollo: G2 y FLABot. Tales casos de estudio permitiran evaluar mejorla conveniencia de las decisiones de diseno explicadas en este capıtulo.

Capıtulo 6

Casos de estudio

Este capıtulo describe una serie de casos de estudio que realizamos para verificarsi las suposiciones hechas a nivel conceptual pueden ser corroboradas en la practica.Los casos de estudio presentados aquı apuntan primero a demostrar que el enfoqueArchSync puede ser aplicable a la sincronizacion de UCMs con implementacion, ysegundo, a ilustrar como se uso la herramienta en diferentes proyectos, para poderinvestigar los puntos fuertes y debiles del enfoque. En particular, en este capıtulo sepretende analizar la utilidad, precision y validez de la herramienta frente a modifica-ciones del codigo fuente y UCMs de diferente complejidad. En cada caso de estudiose mediran (a) la cantidad de trabajo que le fue ahorrado al arquitecto en el anali-sis de los cambios y en la sincronizacion de la documentacion –como indicadores deutilidad–, (b) la cantidad de soluciones diferentes propuestas por la herramienta –como indicador inverso a la precision– y (c) si la solucion esperada por el arquitectoestaba entre las alternativas –como indicador de validez.

La seleccion de los casos de estudio estuvo organizada de acuerdo con una estrate-gia incremental. Inicialmente, se probo la herramienta con ejemplos simples como lospresentados en los capıtulos anteriores. Esto permitio ajustar el funcionamiento delprototipo hasta obtener resultados aceptables. Una vez alcanzada una version relati-vamente estable del prototipo, se tomaron las especificaciones UCM y el historial decodigo fuente de un proyecto comercial de tamano mediano, llamado G2. En esta eta-pa, se probo el desempeno de la herramienta frente a cambios en el codigo fuente deun sistema real. Finalmente, analizamos los cambios en el codigo frente a la especifi-cacion en UCMs de FLABot, un proyecto de investigacion de mayor envergadura. Enesta etapa, hicimos pruebas de mayor complejidad, evaluando la herramienta frentea casos en los que un mismo cambio en el codigo afecta varios paths. A su vez, estaetapa fue util como una forma de auto-validacion, ya que se trata del mismo proyectoal cual ArchSync se integra.

El capıtulo se encuentra organizado de la siguiente manera. Primero se presentanlos casos de G2 en la seccion 6.1. A continuacion, en la seccion 6.2, se presentan losresultados de las pruebas con FLABot. Finalmente, en la seccion 6.3, se comparanlos resultados de ambos experimentos mediante un breve analisis.

6.1. G2

El sistema G2 se basa en la arquitectura client-server de tres bandas (three-tier)que se muestra en la Figura 6.1. El usuario interactua por medio de un browser y envıasolicitudes que son interceptadas por un servidor web para ser delegadas al servidorG2, en la segunda banda correspondiente a la logica del negocio, por intermedio delcomponente GateKeeper. Esta banda fue implementada mediante la instanciacion

59

60 CAPITULO 6. CASOS DE ESTUDIO

Figura 6.1: Arquitectura de G2

de un framework basado en invocacion implıcita llamado Bubble [14], donde la fun-cionalidad se encuentra organizada en tareas que son asignadas a diferentes agentesreactivos. GateKeeper traduce cada solicitud para activar a los agentes encargadosde ejecutar las tareas correspondientes. Las tareas relacionadas con la administraciondel modelo del negocio normalmente interactuan con el componente de persistenciapara consultar o alterar los datos relevantes del repositorio de datos, en la tercerbanda.

Los siguientes casos de estudio sobre el sistema G2 se efectuaron sobre el com-ponente de la segunda banda del modelo three-tier, por ser este el subsistema mascomplejo y donde se concentro el trabajo de desarrollo.

6.1.1. Caso 1

Un escenario donde puede verse en accion el modelo tıpico del sistema G2 esel caso de uso removeUser presentado en el path la Figura 6.2. Aquı un usuarioadministrador envıa por medio de su browser la solicitud de eliminar a otro usuariodel sistema, siempre que sus permisos lo permitan. Cuando esta solicitud llega alsistema por medio del GateKeeper, se activan los agentes encargados de eliminar aun usuario del modelo. Una vez que el agente asignado detecta esta senal, invoca ala tarea de eliminacion, representada por la responsabilidad UCM removeUser. Masadelante, se eliminan los registros relacionados del repositorio de datos, como lo indicala responsabilidad UCM deleteUserFromDB y finalmente se le retorna una paginacon el listado actualizado de usuarios; representado por la secuencia de activacion deresponsabilidades listUsers, generateHTMLResponse y sendResponse.

A pesar de que el escenario es sencillo y concuerda con lo que puede esperarse dela funcionalidad de borrado, durante el desarrollo se reporto la necesidad no solo dedar de baja al usuario del sistema, sino tambien de cerrarle su sesion en caso de queeste se encontrara utilizando el sistema al mismo tiempo que es eliminado.

Aunque las modificaciones realizadas para soportar este requerimiento fueronpocas, el caso de analisis propuesto es interesante por la relativa complejidad dela arquitectura: un sistema basado en agentes reactivos por invocacion implıcita, ca-da uno con su propio thread. Por otro lado, el intervalo entre la ultima sincronizaciony el momento en que se realizaron los cambios fue de seis dıas, caracterizados por un

6.1. G2 61

Figura 6.2: UCM para la accion “eliminar usuario”

Figura 6.3: Analisis estatico de codigo fuente durante la deteccion de paths poten-cialmente modificados

trabajo intensivo dedicado a cerrar un nuevo release del producto. En otras palabras,los cambios en el codigo fuente desde la ultima sincronizacion fueron numerosos y elanalisis de ArchSync (Figura 6.3) senalo, como se esperaba, que el path removeUser ylogout, podrıan haber sido afectados por estas modificaciones sobre la implementacion(Figura 6.4).

La Figura 6.5 muestra la interfaz grafica del sistema G2 durante su ejecucioninstrumentada, lista para proceder con la eliminacion de un usuario. A su vez puedeobservarse un panel de control que el arquitecto emplea para decidir el momento enque las acciones instrumentadas deben registrarse en el log de ejecucion. Luego dereproducido el escenario sobre el sistema instrumentado, Path-Log Matcher analizo latraza de ejecucion (ver Figura 6.6) y sugirio (ver dialogo “Path-Log Matcher Result”en fig. 6.7) el script de actualizacion reproducido en la Figura 6.9. Aquı ArchSyncindica que entre el borrado del usuario en la base de datos (deleteUserFromDB)y el listado de los usuarios restantes (listUsers) ha detectado una potencial nueva

Figura 6.4: Paths potencialmente cambiados segun el analisis estatico de codigo fuente


Figura 6.5: Instrumentacion de la aplicacion G2 durante el caso de uso “eliminarusuario”

Figura 6.6: Seleccion de traza de ejecucion para analizar

6.1. G2 63

Figura 6.7: Dialogo “Path-Log Matcher Result”

responsabilidad y dos responsabilidades existentes en el UCM logout, ilustrado en laFigura 6.11.

En resumen, el script sugiere la insercion secuencial de tres nuevas responsabili-dades en el path:

GateKeeperImplementation.getUserAgents(...): La primer insercion, listadaen la Figura 6.8 correspondiente a una responsabilidad candidata, surge luegode que ArchSync detectara la ejecucion de un metodo que no tiene mapeo di-recto en el caso de uso, pero que tampoco deberıa ser descartado porque podrıaalterar el path. El comando de correccion en este caso es de tipo insert-Between, es decir, sugiere agregar un nuevo nodo entre dos existentes, especi-ficados en los dos primeros argumentos: deleteUserFromDB y listUsers. Elnuevo nodo que sugiere ArchSync se especifica en la estructura definida comotercer argumento del comando de actualizacion. Este nuevo nodo, cuyo iden-tificador asignado es newNode1, esta formado por la responsabilidad candidatagetUserAgents(int):java.util.Vector, identificada ası en base al metododetectado como posible alterador del path; mapeada al componente potencialcom.delsatgroup.g2.kernel.GateKeeperImplementation, sugerido en fun-cion de la clase que contiene al metodo anterior, con un rol no determinado ytipo de nodo asociado simple (es decir que no se trata de un nodo fork o unjoin). En este caso, el metodo sugerido como potencial responsabilidad permiteel acceso a los usuarios logueados en el sistema y no se considera relevantearquitectonicamente, por lo tanto, la experiencia del desarrollador deberıa de-terminar que esa insercion sugerida puede descartarse.

LoginManager.logoutUserAgent: La segunda sugerencia, tambien de tipo detipo insertBetween, aparece como consecuencia de la activacion de metodosmapeados al UCM logout, que se analizara mas adelante. Aquı se descubre laaccion de desloguear al agente asociado al usuario que se esta eliminando.

GateKeeper.invalidateSession: Mas adelante, en el mismo escenario, ArchSyncdetecto la activacion de otra responsabilidad existente en el UCM logout, eneste caso se trata de la invalidacion de sesion del usuario eliminado del sistema,como indica el mapeo a la responsabilidad invalidateSession.

Las ultimas dos sugerencias reflejan correctamente en el UCM los cambios ejercidosen su implementacion y por lo tanto, son aplicados, dando como resultado el UCMilustrado en la Figura 6.10.

6.1.2. Caso 2

El segundo caso de estudio relacionado con el sistema G2 se enfoca sobre elescenario logout, reflejado en al Figura 6.11. Este caso de uso es muy conocido por


insertBetween(deleteUserFromDB, listUsers,

node(newNode1,

’getUserAgents(int):java.util.Vector’,

’com.delsatgroup.g2.kernel.GateKeeperImplementation’,

’?role’,

simple

)

)

Figura 6.8: Primer sugerencia de insercion de la responsabilidad candidata ’getUser-Agents(int):java.util.Vector’. En este caso, no se considera relevante arquitectonica-mente.

insertBetween(deleteUserFromDB,

listUsers,

node(newNode1,

’getUserA-

gents(int):java.util.Vector’,

’com.delsatgroup.g2.kernel.GateKeeperImplementation’,

’?role’,

simple

)

),

insertBetween(newNode1, lis-

tUsers,

node(newNode2,

logoutUserAgent,

’LoginManager’,

loginManager,

simple

)

),

insertBetween(newNode2, lis-

tUsers,

node(newNode3,

invalidateSession,

’GateKeeper’,

gatekeeper,

simple

)

)

Figura 6.9: Script de actuali-zacion para el path “eliminarusuario”

Figura 6.10: UCM actualizado para laaccion “eliminar usuario”

6.1. G2 65

Figura 6.11: UCM para la accion “salir del sistema”

la mayorıa de los usuarios de aplicaciones web, pues se trata de la funcionalidad quepermite a un usuario identificado, cerrar su sesion de trabajo dentro del sistema.

Dentro del servidor G2, la partida de un usuario implica a grandes rasgos doscaminos, identificados a partir de la responsabilidad de tipo AND Fork, llamadadoLogoutRequest. Una secuencia es la que elimina efectivamente la instancia que re-presenta al usuario dentro del servidor, la otra es la encargada de retornar una paginade respuesta, informando que se ha salido del sistema.

Uno de los requerimientos de modificacion del sistema, tambien implementadodurante el mismo perıodo que el analizado en la subseccion 6.1.1, fue la serializacionde las operaciones requeridas para despedir a un usuario del sistema. Anteriormentese invocaba implıcitamente la generacion de la respuesta y luego se invalidaba susesion, pero la caracterıstica asıncrona de la primer invocacion no aseguraba quela sesion se invalidara antes de que se remitiera la respuesta, generando paginas deerror en el browser del usuario. La nueva modificacion empleo invocacion sıncronapara generar la respuesta, evitando el problema anterior.

La deteccion de cambios efectuada por ArchSync informo que este path podrıahaber sido afectado por los ultimos trabajos de implementacion, como se esperaba.Efectivamente, dentro del intervalo ∆ la tarea encargada de realizar este trabajo,mapeada a la responsabilidad doLogoutRequest, habıa sufrido cambios en el orden enque se ejecutaban los dos paths posteriores.

Una vez ejecutado el escenario, el analisis de trazas de ArchSync sugirio variosscripts alternativos. El primero indicaba que el path de ejecucion concordaba con laimplementacion, y por consiguiente, que no era necesaria la actualizacion del UCM.Tal afirmacion es valida porque la bifurcacion tipo AND Fork de caminos es logica, osea, indica que conceptualmente los caminos son paralelos porque pueden ejecutarseen cualquier orden, independientemente de que su implementacion sea secuencial,dentro de un unico hilo de ejecucion o en threads o procesos diferentes. Sin embargo,aquı nuevamente entra en juego el criterio del usuario para determinar si esta sugeren-cia refleja nuestra intencion o no. Puntualmente para esta situacion, la sugerencia noes la mas apropiada, pues conceptualmente, una cadena de activacion debe seguirseestrictamente antes que la otra, para evitar los problemas que motivaron los cambiosen el codigo fuente.

A pesar de que la primer sugerencia no es la ideal, ArchSync ofrece otra alterna-tiva, planteada en la Figura 6.12. Aquı se sugieren dos inserciones y una secuenciade eliminaciones. Las responsabilidades que se sugieren agregar a continuacion de la


insertAfter(sendResponse,

node(newNode1,

logoutUserAgent,

’LoginManager’,

loginManager,

simple

)

),

insertAfter(newNode1,

node(newNode2,

invalidateSession,

’GateKeeper’,

gatekeeper,

simple

)

),

removeAllFrom(logoutUserAgent)

Figura 6.12: Script de actuali-zacion alternativo para el UCM“salir del sistema”

Figura 6.13: UCM actualizado para laaccion “salir del sistema”

existente sendResponse son las siguientes:

LoginManager.logoutUserAgent: Esta responsabilidad es la que elimina al agenteasociado al usuario en cuestion y es insertada luego de que se le remite la pagi-na de despedida al usuario. Notar que este nodo ya existe en el otro subpathparalelo, aunque sera eliminado mas tarde de allı.

GateKeeper.invalidateSession: La accion asociada con esta responsabilidad esinvalidar la sesion del usuario en el servidor web. Al igual que en el caso anterior,esta responsabilidad ya existıa en el otro subpath paralelo.

Por otro lado, ArchSync indica que deberıan eliminarse todas las responsabilidadesdespues de logoutUserAgent, inclusive. En otras palabras, se eliminan de un sub-path las responsabilidades que acaban de insertarse en el otro, accion equivalente amover la secuencia (logoutUserAgent, invalidateSession) al final del envıo de la pagi-na de respuesta, transformando implıcitamente la responsabilidad de tipo AND Fork(doLogoutRequest) en una responsabilidad simple y al UCM resultante en un unicocamino secuencial. Tal script refleja los cambios en la implementacion y por lo tantoes aplicado, transformando el UCM en el de la Figura 6.13.

6.2. FLABot

Como se explica en la seccion A.2, FLABot es una herramienta de debugging ylocalizacion de fallas para plug-ins de Eclipse, que se basa en informacion arquitec-tonica, expresada en forma de UCMs, para aproximar las regiones de codigo dondees mas probable que se hayan originado las fallas.

En este caso de estudio, nos enfocamos sobre el editor de UCMs provisto porFLABot. En particular, analizamos tres paths correspondientes a acciones de edi-cion activadas a traves del menu contextual: “insertar fork”, “rotar fork” e “insertarresponsabilidad” (Figura 6.14). Como se puede ver en la figura, los tres paths sonmuy similares: todos comienzan con la activacion de la accion de menu contextual(XAction), siguen con la creacion del comando correspondiente (XCommand), para

6.2. FLABOT 67

Figura 6.14: UCMs para la acciones “insertar fork”, “rotar fork” e “insertar responsa-bilidad”.

Figura 6.15: Vista de ArchSync en Eclipse, mostrando el conjunto de paths de FLABotidentificados como posiblemente cambiados.

luego solicitar a la pila de comandos (CommandStack) que ejecute el comando creado;finalmente, el comando se ejecuta.

Luego de que se termino de implementar un nuevo requerimiento, que consistıa enla insercion de un mediador entre las acciones y la pila de comandos, nos pusimos enel rol de arquitectos de FLABot y usuarios de ArchSync. Entonces, decidimos contro-lar la nueva version del proyecto, para detectar si los cambios en la implementacionafectan alguno de los UCMs actuales, y si ası fuera, cuales son los artefactos de imple-mentacion modificados que lo hacen. El analisis detecto que los UCMs presentadospodrıan estar afectados por los cambios (Figura 6.15). A partir de este punto, sefueron tomando estos paths uno a uno para generar sus correspondientes trazas deejecucion, compararlas con el modelo desactualizado y finalmente aplicar o no algunscript de actualizacion. A continuacion, se muestran los resultados obtenidos paracada uno de los paths afectados:

1. Insertar fork

La comparacion del path “insertar fork” con su correspondiente traza de eje-


insertBetween(

createInsertForkCommand,

stackExecuteCommand,

node(newNode1,

’executeCommand(Command,...)’,

’FlabotGraphicalEditor’,

?role,

simple)),

insertAfter(

executeInsertFork3,

node(newNode2,

markDirty,

’FlabotMultiPageEditor’,

?role,

simple))

Figura 6.16: Script de actualizacionpara el path “insertar fork”

Figura 6.17: UCM actualizado para laaccion “insertar fork”

cucion, produjo como resultado el script de actualizacion que se muestra en laFigura 6.16. El script sugiere la insercion de dos nuevas responsabilidades en elpath:

FlabotGraphicalEditor.executeCommand(...): La primera operacion su-gerida advierte la ejecucion del metodo executeCommand(...) de la claseFlabotGraphicalEditor entre las responsabilidades createInsertFork-Command y stackExecuteCommand. Teniendo en cuenta el requerimientoque origino el cambio, identificamos a la clase sugerida como una imple-mentacion del mediador entre acciones y pila de comandos (al que lla-mamos CommandExecutor). Asimismo, identificamos al metodo sugeridocomo la implementacion de la responsabilidad del mediador encargada dela ejecucion de comandos (a la que llamamos executorExecuteCommand,para diferenciarla de otra responsabilidad existente). La aplicacion de estaoperacion del script, entonces, implica la creacion de un nuevo compo-nente y una nueva responsabilidad, respectivamente mapeados a la clasey el metodo sugeridos.

FlabotMultipageEditor.markDirty: En contraste, la segunda operacion ad-vierte la ejecucion de un metodo que realiza una operacion irrelevante enel contexto de este path: poner un flag de “sucio” en el editor en valor “ver-dadero” para saber que, cuando se cierre, es necesario pedir confirmacional usuario. Por lo tanto, como usuarios de la herramienta decidimos noaplicar el segundo cambio.

El UCM resultante se muestra en la Figura 6.17.

2. Rotar fork

Luego de actualizar el path anterior, se creo una nueva traza de ejecucion paracomparar con el path desactualizado “rotar fork”. Terminada la comparacion,el dialogo “Path-Log Matcher Result” (Figura 6.18) propuso el script de actua-lizacion de la Figura 6.19. Al analizar el script se puede notar que sugiere lainsercion de responsabilidades y componentes; el script anterior, en contraste,sugirio clases y metodos. Esto se debe a que durante la actualizacion del pathanterior se crearon elementos arquitectonicos mapeados a estos elementos de

6.2. FLABOT 69

Figura 6.18: Dialogo “Path-Log Matcher Result”.

insertBetween(

createRotateForkCommand,


node(newNode1,

executorExecuteCommand,

’CommandExecutor’,

newCommandExecutor,

simple))

Figura 6.19: Script de actualizacionpara el path “rotar fork”

Figura 6.20: UCM actualizado para laaccion “rotar fork”

bajo nivel, y ArchSync ha incorporado esta informacion para el analisis delpath actual. El path resultante de la aplicacion del script se puede ver en laFigura 6.20.

3. Insertar responsabilidad

Finalmente, se comparo el path“insertar responsabilidad”con su correspondien-te traza de ejecucion. Como resultado, se produjo el script de la Figura 6.21.De manera similar al caso anterior, ArchSync propone otra vez la insercion dela nueva responsabilidad. En la Figura 6.22 se muestra el UCM luego de laactualizacion.

Desde la perspectiva de ArchSync, este resulto ser un cambio relativamente complejo:

insertBetween(

createInsertResponsibilityCommand,


node(newNode1,

executorExecuteCommand,

’CommandExecutor’,

newCommandExecutor,

simple))

Figura 6.21: Script de actualizacionpara el path“insertar responsabilidad”

Figura 6.22: UCM actualizado para laaccion “insertar responsabilidad”


fue necesario detectar la creacion de un nuevo componente y una nueva responsabi-lidad. Ademas de la deteccion de los nuevos elementos arquitectonicos, ArchSyncidentifico correctamente todos los paths afectados por el cambio y sugirio las actua-lizaciones apropiadas para reflejar la insercion de un intermediario entre acciones ypila de comandos.

6.3. Analisis de resultados

Los casos de prueba desarrollados en el presente capıtulo ponen bajo analisisdos sistemas de proporciones diferentes. Por un lado, G2, un proyecto mediano deaproximadamente 900 clases, especificado parcialmente a nivel arquitectonico por 34escenarios UCM. Por otro lado, FLABot, un proyecto casi tres veces mayor en tamano,conformado por mas de 2500 clases java y especificado tambien parcialmente por 122UCMs.

Si bien es importante tener en cuenta la cantidad de clases como medida detamano de un sistema, en nuestro caso es importante determinar cuales de estasclases juegan un papel importante en la materializacion de la arquitectura. En otraspalabras, cuales contribuyen a la materializacion de las responsabilidades asignadasa los diferentes componentes de la arquitectura del sistema. En el caso de G2, de las900 clases, solo 98 podıan considerarse relevantes arquitectonicamente, mientras queen FLABot este numero fue de 270. Claramente estos valores indican una proporcionmuy baja de clases relevantes, hecho que pone bajo duda la razon de existencia de tanelevado numero de clases que aparentemente no contribuyen con los aspectos elemen-tales de la arquitectura propuesta. Para entender esta relacion, es importante aclararque este numero se presupone mucho mayor, pero siendo que la especificacion UCMde ambos sistemas es incompleta, es decir que solamente cubre un subconjunto de to-da la funcionalidad, solo una porcion pequena de la implementacion es mapeada a lospaths UCM. Por esta razon, varias clases han quedado sin su correspondiente mapeo,pasando implıcitamente a la categorıa de “clase no relevante arquitectonicamente”.

Esta diferencia en el volumen de ambos proyectos puede notarse en el numero declases y paths afectados descubiertos por ArchSync, como se refleja en la Figura 6.23.

6.3.1. Estado de los proyectos ante cambios en la implementacion

En el caso de G2, ArchSync determino que el source code ∆ de prueba estaba con-formado por 20 clases modificadas. Sin embargo, solamente 2 de ellas tenıan mapeosarquitectonicos. En otras palabras, ArchSync redujo el espacio de busqueda en un90 %. Estas 2 clases representan el 2,04 % del total de clases con importancia arqui-tectonica, y los dos paths detectados por ArchSync como potencialmente modificadosrepresentan el 5,88 % de todos los paths de la especificacion UCM. Esto significo unahorro significativo en el esfuerzo del arquitecto, ya que evito revisar un 97,96 % delas clases relevantes y un 94,12 % de los paths.

Por otro lado, en el caso del proyecto FLABot, el source code ∆ del caso deestudio estaba constituido por un total de 91 clases modificadas, de las cuales solo 15afectaban algun flujo de control en la especificacion UCM. Al detectar esto, ArchSyncredujo el espacio de busqueda en un 83,52 %. Esas 15 clases representan el 5,56 % deltotal de clases relevantes arquitectonicamente, y ArchSync detecto que 11,48% de lospaths (14 de 122) habıan sido cambiados. Esto evito revisar un 94,44% de las clasesrelevantes y un 88,52 % de los paths.

Un resumen de estos ındices puede verse en el Cuadro 6.1.

6.3. ANALISIS DE RESULTADOS 71

G2 FLABot# total de clases ˜900 ˜2500# clases con mapeo 98 270# clases en ∆ 20 91# clases con mapeo en ∆ 2 15% clases con mapeo 2,04 % 5,56 %% paths afectados 5,88 % 11,48 %% clases ahorrado 97,96 % 94,44 %% paths ahorrado 94,12 % 88,52 %

Cuadro 6.1: Estado del proyecto ante cambios en la implementacion

Figura 6.23: Clases con mapeo cambiadas vs. paths afectados

La primer conclusion que puede derivarse de estos valores es la utilidad de Arch-Sync para reducir el espacio de busqueda ante los cambios sufridos durante el de-sarrollo en la implementacion. Como se justifico antes, la deteccion y exposicion delos cambios brinda al arquitecto la oportunidad de descubrir potenciales violacionesa las restricciones impuestas por la arquitectura, pero si el espacio de busqueda, esdecir, la cantidad de clases sospechosas se mantiene demasiado alto, este trabajo dejanuevamente de ser trivial, de aquı que la drastica reduccion en este espacio es unacaracterıstica beneficiosa.

Por otro lado, descubrimos que mientras mas clases relevantes arquitectonica-mente sean afectadas, mayor es la cantidad de paths a corregir y por lo tanto es mastrabajo para el arquitecto. Esta consecuencia es inevitable y razonable: si los cambiosen la implementacion son importantes y numerosos, mas comprometida se vera la es-pecificacion UCM y por lo tanto, mayor sera la cantidad de trabajo a sincronizar.

6.3.2. Propuesta de solucion de ArchSync

Antes de proceder con el analisis de las soluciones propuestas por ArchSync antelos distintos casos de estudio, vale la pena explicar brevemente una medida de com-plejidad de los paths UCM que se utilizara aquı. Tomamos como medida de comple-jidad de los paths a la cantidad de responsabilidades que intervienen en el escenariomultiplicada por la cantidad de bifurcaciones (AND fork y OR fork) cuando exista


G2.1 G2.2 FLABot.1 FLABot.2 FLABot.3complejidad del path 6 12 4 4 4# alternativas 3 10 2 2 2# operaciones (prom.) 3,3 4,2 2 2,5 2

Cuadro 6.2: Complejidad de los paths existentes y de las soluciones propuestas

Figura 6.24: Complejidad del path vs. alternativas de conciliacion

al menos alguna en el path. La razon de esta metrica se fundamenta en que cadabifurcacion puede considerarse como un nuevo path y por lo tanto, la cantidad de al-ternativas a evaluar crece proporcionalmente con este numero, aumentando entoncessu complejidad intrınseca.

Para el primer caso de analisis del sistema G2 (UCM removeUser) la complejidaddel path es de 6 y la cantidad de soluciones alternativas de 3. Por otro lado, el segundocaso (UCM logoutUser) se determino de complejidad 12 por contener una bifurcacionde tipo AND, con 10 scripts alternativos para corregir el UCM desactualizado. Encualquiera de los casos de estudio sobre FLABot la complejidad es de 4 mientras quela cantidad de scripts alternativos fue de 2.

Respecto a la caracterıstica de las soluciones propiamente dichas, dado que en elcaso de estudio G2 los cambios en el codigo fueron mas profundos (es decir, afectabanen mayor grado el flujo de control y datos de los paths relacionados), se obtuvieronscripts con un numero promedio de operaciones de 3,1 y 4,2 respectivamente. EnFLABot, en cambio, si bien se afecto un numero mayor de paths, el cambio en cadauno de ellos fue mas simple y por lo tanto el numero de operaciones promedio porscript fue de 2,2. Estos valores pueden verse resumidos en el Cuadro 6.2.

Aquı la conclusion principal que puede extraerse es que el numero de posibles solu-ciones aumenta a medida que lo hace la complejidad de los paths. Este aumento en elnumero de opciones para sincronizar el UCM puede verse como una disminucion enla precision, al requerir mayor atencion por parte del arquitecto quien debe analizarcada una para escoger la mas apropiada. La Figura 6.24 muestra el crecimiento en lacantidad de alternativas a medida que la complejidad tambien aumenta. Ademas esimportante destacar que a veces los cambios en el codigo representan una violacionde las prescripciones impuestas por la arquitectura. En estos casos no es necesario ac-tualizar los UCMs, sino recodificar las partes de la implementacion correspondientes.

6.3. ANALISIS DE RESULTADOS 73

Tambien se desprende de estos casos de estudio que la complejidad de los scripts,medido en funcion del numero de operaciones, aumenta cuanto mas profundo es elcambio introducido en la implementacion. La profundidad de un cambio en el codigopuede verse como la variacion en el flujo de control y de datos representado en elUCM, tal cual lo alterarıa un arquitecto manualmente en la documentacion.

El haber utilizado JavaLog para la implementacion de Path-Log Matcher, si bienbrinda flexibilidad a la hora de agregar o modificar reglas, acarrea los problemastıpicos en los lenguajes interpretados. Por otro lado, la ejecucion de una aplicacioninstrumentada es cada vez mas lenta a medida que crece la cantidad de puntos queestan siendo inspeccionados. Asimismo, la memoria y el procesamiento requeridospara el analisis de los logs de bajo nivel crece segun la naturaleza del caso de uso queesta siendo analizado.

En resumen, las pruebas realizadas sobre ambos proyectos revelaron la impor-tante asistencia que significa el uso de ArchSync en proyectos de desarrollo. El es-pacio de busqueda, tal como deberıa ser analizado por un arquitecto para descubrirlos cambios, se reduce notablemente en comparacion con el total de clases relevantesarquitectonicamente y aun ası, el registro de trazas de ejecucion del sistema evita queestas clases deban ser inspeccionadas. Por otro lado, la precision de la herramienta seve comprometida por la complejidad de los paths y por la profundidad de los cambios.Este ultimo ındice ira en aumento a medida que el intervalo entre sincronizaciones au-mente, confirmando la suposicion de que de ArchSync debe utilizarse frecuentementepara minimizar la cantidad de cambios importantes sobre los paths UCM.

Capıtulo 7

Conclusiones y trabajos futuros

En los capıtulos previos de este trabajo se presento ArchSync, un enfoque para lasincronizacion de documentacion de diseno en forma de UCMs con su implementacion.Mediante el uso de informacion de mapeo entre elementos arquitectonicos y codigofuente, ArchSync permite la modificacion semiautomatica de las partes de la docu-mentacion que han quedado desactualizadas para ponerlas en correspondencia conel estado actual de la implementacion. Las opciones de actualizacion propuestas porel enfoque se obtienen como producto de la comparacion de los paths descriptos porla documentacion con las trazas de ejecucion capturadas durante el ejercicio de laaplicacion.

El prototipo de ArchSync fue implementado como plug-in de Eclipse, aprovechan-do su infraestructura de historial de archivos y su metamodelo Java para el analisis decodigo fuente. A su vez, esto permitio aprovechar los editores de UCM y el modulo deinstrumentacion de codigo de FLABot. Adicionalmente, la integracion con el entornode desarrollo facilita la adopcion del enfoque dentro del proceso de desarrollo de unsistema, ya que permite la ejecucion del proceso de sincronizacion como una tareamas del desarrollador.

Como aporte principal, ArchSync permite actualizar los UCMs arquitectonicoscon respecto a su implementacion. Al mismo tiempo, el enfoque revela violacionesa las reglas de comportamiento impuestas por el estilo arquitectonico a un nivel deabstraccion apropiado para hacerlas evidentes. Por lo tanto, el analisis realizado porla herramienta tambien puede ser usado por el arquitecto para decidir la recodi-ficacion de algunas partes de la implementacion de acuerdo con las prescripcionesarquitectonicas.

Por otro lado, el enfoque se basa en ciertas suposiciones y tiene algunas limita-ciones. Primero, cuando ocurre un cambio en el codigo fuente, suponemos que esposible conocer los mapeos previos entre UCMs e implementacion. Esto significa quela implementacion anterior a los cambios era consistente con los escenarios descrip-tos en los UCMs. Estos mapeos deberıan ser especificados cuando el arquitecto crealos UCMs por primera vez y luego procede a implementarlos. En segundo lugar, elenfoque asume que las sincronizaciones entre UCMs e implementacion se realizancon una frecuencia acorde al ritmo de desarrollo del sistema, para asegurar que loscambios entre las diferentes versiones del codigo fuente presenten pocas variaciones.Si esto no es ası, el reconocimiento de las activaciones de responsabilidades basado enlos eventos de los logs de ejecucion se puede volver computacionalmente inmanejable.

La desventaja principal del enfoque radica en la distancia entre un UCM da-do y las muchas implementaciones posibles para los paths de responsabilidades. Laherramienta trata de reconstruir los paths de responsabilidades usando un analisisbidireccional, que combina ingenierıa reversa de los logs de ejecucion con informa-

75

76 CAPITULO 7. CONCLUSIONES Y TRABAJOS FUTUROS

cion semantica proveniente de los UCMs desactualizados. Sin embargo, este proce-samiento esta lejos de ser automatico, porque requiere una cantidad considerable deconocimiento semantico que debe ser proporcionado por el arquitecto. El arquitec-to interactua con la herramienta en dos puntos: para proveer los logs de ejecucioncorrectos y para seleccionar entre las opciones de conciliacion. Ademas, si bien laherramienta proporciona indicios de la aparicion de nuevas responsabilidades, tantoestas como sus correspondientes mapeos deben ser especificados de manera manual.

La notacion UCM da una nocion de la estructura del sistema mediante compo-nentes y responsabilidades, que es reforzada mediante los mapeos componente-clasey responsabilidad-metodo. Sin embargo, esta informacion no puede considerarse unadocumentacion completa de la estructura de un sistema a nivel arquitectonico, yaque no define de manera explıcita las relaciones entre estos elementos (por ejemplo,la estructura de herencia en una vista estatica o los puertos y conectores en tiempode ejecucion). Otra debilidad que detectamos en nuestro enfoque es que su analisises puramente sintactico: no considera la semantica de las prescripciones ni los estilosarquitectonicos.

Finalmente, es necesario mencionar algunas desventajas inherentes a las tecnicasde instrumentacion de codigo y analisis de logs de ejecucion, que fueron acarreadas poreste trabajo. El modulo de instrumentacion de FLABot se encuentra estable y ha sidoutilizado exitosamente en un gran numero de aplicaciones. Sin embargo, justamenteal modificar el codigo existente, es imposible garantizar que el comportamiento de laaplicacion no se ve modificado respecto a su version sin instrumentar. Por otro lado,la eleccion de los puntos a inspeccionar para generar un log de ejecucion implica untradeoff importante. En teorıa, serıa posible registrar la ejecucion de cada lınea decodigo y el estado de todos los objetos en cada instante. De esta manera, se podrıa rea-lizar un analisis mas preciso y exhaustivo, ya que se contarıa con absolutamente todala informacion posible acerca de la ejecucion de la aplicacion. Sin embargo, la cantidadde informacion almacenada se volverıa inmanejable y la aplicacion analizada.se verıaextremadamente afectada en su rendimiento, ya que por cada lınea ejecutada seactivarıa el mecanismo de publicacion y subscripcion de eventos del instrumentador.

7.1. Trabajos futuros

La elaboracion de este trabajo, junto con la implementacion del prototipo, puso enevidencia nuevas posibilidades para investigaciones futuras, como ası tambien algunasposibles mejoras a la implementacion existente. En esta seccion se describen algunasde ellas.

7.1.1. Integracion con aspectos estructurales

Si bien ArchSync produjo buenos resultados en la sincronizacion de UCMs conimplementacion, esta claro que hay muchas partes de la documentacion de una arqui-tectura para las que esta notacion no es apropiada. Para abarcar una mayor propor-cion de la documentacion, es necesario tener en cuenta los aspectos estructurales dela arquitectura, generalmente especificados mediante diagramas de descomposicionde modulos para una vista estatica, de componentes y conectores para vistas querepresentan la estructura en tiempo de ejecucion y de deployment para mostrar comose relaciona el sistema con los elementos de su ambiente que no son software.

Creemos que la integracion de algunos de los enfoques estructurales basados eningenierıa reversa, presentados en la Seccion 3.1.1, con el concepto de sincronizacionincremental presentado en este trabajo puede ser beneficiosa por varias razones. Prin-

7.1. TRABAJOS FUTUROS 77

cipalmente, mejorarıa el desempeno de ArchSync al permitir una sincronizacion mascompleta de la documentacion de diseno. Ademas, al aprovechar la documentacionexistente que no ha sido afectada por los cambios en el codigo, se reduce la cantidadde informacion semantica que se requiere y, por lo tanto, la necesidad de intervenciondel arquitecto en el proceso.

7.1.2. Trazabilidad en metodos de diseno

Los artefactos producidos durante el desarrollo de software –tales como descrip-ciones de modelos, diagramas, especificaciones formales abstractas y codigo fuente–estan altamente interrelacionados, ya que los cambios en algunos de ellos afectan aotros. La falta de informacion acerca de estas relaciones o la incerteza acerca de lainformacion existente limita la utilidad de los modelos de software durante el desa-rrollo.

ArchSync ataca el problema particular de sincronizacion de relaciones entre codigofuente y UCMs. Sin embargo, la perspectiva practica tomada en el desarrollo de estetrabajo nos hace creer posible su extension para soportar la sincronizacion de otrotipo de relaciones entre elementos de los modelos.

7.1.3. Mapeo de paths con casos de test

Una vez que la aplicacion que esta siendo analizada se ha puesto en ejecucion,el proceso de ejercitarla con los casos de uso correspondientes a los paths desac-tualizados se debe realizar de manera manual. En caso de tener que verificar unnumero considerable de paths, la tarea se puede volver muy tediosa, aumentando laprobabilidad de introducir errores en el analisis por distracciones del usuario.

Un posible trabajo futuro para mitigar esta debilidad del enfoque puede ser per-mitir el mapeo de UCMs con casos de test. Al contar la herramienta con informacionacerca de que caso de test corresponde a cada path, serıa posible la creacion de loslogs de ejecucion necesarios sin intervencion del usuario. Ademas, esto puede permitirun analisis de cobertura de los casos de test: si se detecta que un log de ejecucion nocubre cierta porcion de codigo que ha sido modificada, se puede advertir al usuarioque es necesaria la creacion de un nuevo caso o la modificacion del existente.

7.1.4. Especializacion del enfoque

Durante la elaboracion de este trabajo, se trato de mantener la generalidad delenfoque al no limitarlo a ningun estilo arquitectonico en particular o a algun conjuntode convenciones de implementacion especıfico. Como objetivo de diseno, esto tuvo unefecto positivo en el trabajo ya que permite el uso de la herramienta en cualquiersistema que haya sido implementado en Java.

Sin embargo, creemos que los estilos arquitectonicos y las convenciones de imple-mentacion pueden aportar informacion valiosa al enfoque. Mediante la especializacionde las reglas de analisis de Path-Log Matcher para algun estilo particular, se puedemejorar su precision al eliminar algunas alternativas de conciliacion que de ante-mano se sabe que no son validas. Asimismo, se podrıan introducir nuevas reglas enel componente Diff Mapper que, al aportar informacion acerca de las convencionesde implementacion, permitan una mayor precision en la deteccion de nuevas respon-sabilidades.

78 CAPITULO 7. CONCLUSIONES Y TRABAJOS FUTUROS

Apendice A

Eclipse y FLABot

A.1. Plataforma Eclipse

Eclipse es una comunidad open-source cuyos proyectos estan orientados a proveeruna plataforma de desarrollo extensible y frameworks de aplicaciones para construirsoftware. Eclipse provee herramientas y frameworks extensibles que abarcan el ciclode vida de desarrollo de software, incluyendo soporte para modelado, entornos dedesarrollo para Java, C/C++ y otros lenguajes, testing y performance, business in-telligence, aplicaciones de escritorio y desarrollo embebido. Un gran ecosistema deimportantes empresas de software, universidades, institutos de investigacion e indi-viduos extienden, complementan y soportan la plataforma Eclipse [17].

Uno de los beneficios claves de la plataforma Eclipse aparece a traves de su usocomo un punto de integracion. Al construir las herramientas o aplicaciones sobre laplataforma Eclipse, se les permite integrarse con otras herramientas tambien escritasusando la plataforma. De esta manera, la plataforma integra las herramientas indi-viduales en un unico producto, proveyendo una experiencia rica y consistente paralos usuarios.

El rol principal de la plataforma es brindar a los desarrolladores un conjunto demecanismos y reglas para conducir a la integracion simple y sistematica de herramien-tas. Estos mecanismos son expuestos por medio de APIs (Application ProgrammingIntefaces), clases y metodos bien definidos. La plataforma ademas provee bloques deconstruccion y frameworks muy utiles para facilitar el desarrollo de nuevas herra-mientas.

En la Figura A.1 se muestra un esquema de los componentes principales de laarquitectura de plug-ins de Eclipse.

A.1.1. Arquitectura de Plug-ins

Un plug-in es la menor unidad de funcion de la plataforma Eclipse que puedeser desarrollada y entregada por separado. Por lo general, una herramienta pequenase escribe como un solo plug-in, mientras que una herramienta compleja tiene sufuncionalidad repartida entre varios plug-ins. Excepto por un pequeno kernel llamadoPlatform Runtime, toda la funcionalidad de la plataforma es provista en forma deplug-ins.

La configuracion de cada plug-in se describe a traves de un par de archivos.El manifiesto declara informacion esencial acerca del plug-in, incluyendo nombre,version y dependencias hacia otros plug-ins. El segundo archivo, plugin.xml, declaralas interconexiones del plug-in con otros plug-ins. El modelo de interconexion essimple: un plug-in declara cualquier numero de puntos de extension, y cualquier

79

80 APENDICE A. ECLIPSE Y FLABOT

Figura A.1: Arquitectura de Plug-ins de Eclipse

Figura A.2: Comunicacion entre Plug-ins de Eclipse

numero de extensiones a uno o mas puntos de extension en otros plug-ins. Los puntosde extension pueden ser extendidos por otros plug-ins.

Un punto de extension puede tener una interfaz API correspondiente. Otros plug-ins contribuyen implementaciones de esta interfaz por medio de extensiones de estepunto de extension. Cualquier plug-in es libre de definir nuevos puntos de extension yde proveer una nueva API para que usen otros plug-ins. En la Figura A.2 se ilustranlos roles principales para la comunicacion entre plug-ins.

Al iniciar, la plataforma descubre el conjunto de plug-ins disponibles, lee susarchivos de manifiesto, y construye un registro de plug-ins en memoria. Al determi-nar el conjunto de plug-ins al principio, y al soportar un significativo intercambiode informacion entre plug-ins sin tener que activar ninguno de ellos, la plataformapuede proveer a cada plug-in de una rica fuente de informacion pertinente acerca delcontexto en el que esta corriendo.

La plataforma corre en una unica invocacion de una maquina virtual Java estan-dar. A cada plug-in se le es asignado su propio class loader Java, que es responsablede cargar sus clases y recursos. Cada plug-in declara explıcitamente su dependenciacon otros plug-ins de los que espera acceder directamente a sus clases, y controlala visibilidad frente a los plug-ins dependientes de las clases e interfaces publicas ensus librerıas. Esta informacion se declara en el manifiesto, y las reglas de acceso sonaplicadas en tiempo de ejecucion por los class loaders de los plug-ins.

A.2. FLABOT 81

Figura A.3: Esquema de funcionamiento de FLABot

A.2. FLABot

FLABot1 es una herramienta de soporte para la localizacion de fallas y debuggingde plug-ins de Eclipse. El tipo de soporte que provee la herramienta no se trata deencontrar puntos de error especıficos en el codigo, sino que se enfoca en el modeloarquitectonico de un plug-in y usa esa informacion para aproximar las regiones decodigo donde los errores se originan con mayor probabilidad. El proyecto fue inspiradopor el enfoque propuesto en [39]. Basicamente, este enfoque se basa en la nocion deque usar modelos arquitectonicos permite al desarrollador razonar y resolver muchosproblemas de debugging en un nivel que es razonablemente manejable, inclusive parasistemas complejos [6].

En la Figura A.3 se presenta un esquema del funcionamiento de FLABot. Paraalcanzar la funcionalidad propuesta, la herramienta utiliza informacion de mapeoresponsabilidad-codigo para configurar un instrumentador de bytecode Java, de estamanera generando registros de las trazas de ejecucion problematicas. Estos registros ologs son tomados por el Asistente de Localizacion de Fallas para realizar un analisisexploratorio de los paths de funcionalidad descriptos en la especificacion arquitec-tonica. Este analisis combina informacion de ejecucion de bajo nivel contenida enlos logs con feedback del usuario, para ası identificar la causa de la falla en un con-junto de responsabilidades. Una vez detectadas las causas del error, el conjunto deresponsabilidades problematicas es traducido en un conjunto de breakpoints en suscorrespondientes regiones de codigo, una vez mas utilizando la informacion de mapeoresponsabilidad-codigo. Finalmente, el usuario es libre de utilizar tecnicas de debug-ging tradicionales sobre este espacio de busqueda reducido.

La funcionalidad principal de FLABot se encuentra organizada basicamente entres modulos:

Editores de Especificaciones Arquitectonicas: Este modulo posee la funciona-lidad necesaria para la especificacion y manipulacion de modelos de compo-nentes UML y de UCMs de manera grafica, como se muestra en las Figuras A.4y A.5. Los editores permiten mapear cada componente UML a un conjunto declases Java, para luego mapear cada responsabilidad a un subconjunto de losmetodos de estas clases. Estos modelos son los vehıculos principales para con-struir la informacion arquitectonica que los otros dos modulos necesitan parafuncionar. Ambos editores fueron implementados como plug-ins de Eclipse, porlo que se integran completamente con la plataforma y tanto los editores mismoscomo sus correspondientes modelos pueden ser reutilizados por cualquier otro

1FLABot homepage: http://www.exa.unicen.edu.ar/isistan/flabot/

http://www.exa.unicen.edu.ar/isistan/flabot/


Figura A.4: Editor de componentes UML de FLABot

plug-in.

Asistente para Localizacion de Fallas: Este modulo materializa las estrategiaspara localizacion de fallas guiada por la arquitectura, de acuerdo al enfoquedescripto en [39].

Debugger Especializado: Este modulo anada el soporte para debugging en sı. Eldebugger especializado permite relacionar la salida del asistente con estructurasde codigo, insertando breakpoints en las que resulten apropiadas, para luegopermitir al desarrollador aplicar tecnicas tradicionales de debugging sobre elcodigo de la aplicacion.

Ademas de estos tres modulos principales, para generar los logs de ejecucion FLABotimplementa un modulo de instrumentacion de codigo estructurado en forma de ca-pas. La capa superior recibe parametros de configuracion que indican el conjunto declases y metodos que deben ser inspeccionados, es encargada de iniciar la ejecucionde la aplicacion instrumentada y produce como respuesta un log con las trazas deejecucion. En las capas inferiores se implementa la infraestructura de bajo nivel parala instrumentacion en sı, que hace uso de un class loader especializado para analizary modificar el bytecode de las clases en los puntos que deben ser inspeccionados.Cuando una clase esta a punto de ser cargada dentro de la maquina virtual, el byte-code se analiza para detectar si en ella se produce alguno de los eventos indicadosen los parametros de configuracion. Si esto es ası, se utiliza la librerıa Javassist [15]para insertar llamadas en los puntos inspeccionados a un mecanismo de publicaciony subscripcion de eventos que se encarga de generar el log.

Independientemente de sus detalles de implementacion, para reutilizar el instru-mentador de FLABot solamente hace falta comunicarse con la capa superior. Estose hace a traves de un punto de extension, definido en el instrumentador, al que esposible contribuir los parametros de configuracion necesarios para indicar tanto las

A.2. FLABOT 83

Figura A.5: Editor de UCM de FLABot

clases y metodos a inspeccionar como la ubicacion donde se debe guardar el log deejecucion.

Bibliografıa

[1] Marwan Abi-Antoun, Jonathan Aldrich, David Garlan, Bradley Schmerl, andNagi Nahas. Semi-automated incremental synchronization between conceptualand implementation level architectures. In Proceedings of the 2005 WorkingIEEE/IFIP Conference on Software Architecture (WICSA 2005), Pittsburgh,PA., USA, November 2005. 13

[2] Marwan Abi-Antoun, Jonathan Aldrich, David Garlan, Bradley Schmerl, NagiNahas, and Tony Tseng. Improving system dependability by enforcing architec-tural intent. In Proceedings of the 2005 Workshop on Architecting DependableSystems (WADS 2005), St. Louis, MS., USA, May 2005. 15, 17, 22, 27, 28, 32

[3] Jonathan Aldrich, Craig Chambers, and David Notkin. Archjava: Connectingsoftware architecture to implementation. In Proceedings of the 24th InternationalConference on Software Engineering, 2002. 22

[4] A. Amandi, M. Campo, and A. Zunino. JavaLog: A framework-based integra-tion of Java and Prolog for agent-oriented programming. Computer Languages,Systems and Structures, 31, 2004. ISSN 0096-0551. 55

[5] Daniel Amyot, Nikolai Mansurov, and Gunter Mussbacher. Understanding ex-isting software with use case map scenarios. In 3rd SAM Workshop on SDL andMSC, University of Wales Aberystwyth, June 2002. 21, 27, 28

[6] L. Bass, P. Clement, and R. Kazman. Software Architecture in Practice. 2ed.Addison-Wesley, 2003. ISBN 0-321-15495-9. 1, 5, 6, 47, 48, 81

[7] Pierre Bourque, Robert Dupuis, Alain Abran, James W. Moore, and LeonardTripp. The guide to the software engineering body of knowledge. IEEE Software,16(6):35–44, 1999. 17

[8] I. T. Bowman, R. C. Holt, and N. V. Brewster. Linux as a case study: Itsextracted software architecture. In ICSE’99, Los Angeles, CA, USA, 1999. 17,19

[9] R. J. A. Buhr. Use case maps for attributing behaviour to system architecture.In WPDRTS ’96: Proceedings of the 4th International Workshop on Paralleland Distributed Real-Time Systems, page 3, Washington, DC, USA, 1996. IEEEComputer Society. 12

[10] R. J. A. Buhr. Making behaviour a concrete architectural concept. In HICSS’99: Proceedings of the Thirty-second Annual Hawaii International Conferenceon System Sciences-Volume 8, page 8065, Washington, DC, USA, 1999. IEEEComputer Society. 12

85

86 BIBLIOGRAFIA

[11] R.J.A. Buhr. Use Case Maps: A New Model to Bridge the Gap Between Re-quirements and Design. Austin, TX., USA, October 1995. Contribution to theOOPSLA 95 Use Case Map Workshop. 2, 10

[12] Rainer Burkhardt. UML: Unified Modeling Language. Addison-Wesley, 1997. 47

[13] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, andMichael Stal. Pattern-oriented software architecture: a system of patterns. JohnWiley & Sons, Inc., New York, NY, USA, 1996. 11, 20, 32

[14] Marcelo Campo, Andres Dıaz Pace, and Mario Zito. Developing object-orientedenterprise quality frameworks using proto-frameworks. Software Practice andExperience, 32:1–7, jul 2002. 60

[15] S. Chiba. Javassist — a reflection-based programming wizard for java, 1998. 82

[16] Paul Clements, David Garlan, Len Bass, Judith Stafford, Robert Nord, JamesIvers, and Reed Little. Documenting Software Architectures: Views and Beyond.Pearson Education, 2002. 1, 6, 7

[17] IBM Corporation and The Eclipse Foundation. Eclipse platform technicaloverview. 2001, 2003, 2005. 24, 47, 79

[18] H. Gall, R. Klosch, and R. Mittermeir. Object-oriented re-architecting. InESEC-5, Berlin, Germany, 1995. 17, 19

[19] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design pat-terns: Abstraction and reuse of object-oriented design. Lecture Notes in Com-puter Science, 707:406–431, 1993. 50, 55, 56

[20] D. Garlan, R. Monroe, and D. Wile. Acme: An architecture description inter-change language. In Proceedings of CASCON 97, November 1997. 9

[21] D. Garlan, R. Monroe, and D. Wile. ACME: Architectural Description ofComponent-Based Systems. Cambridge University Press, 2000. 8, 20, 22

[22] K. Jensen. An introduction to the theoretical aspects of coloured petri nets. ADecade of Concurrency, Lecture Notes in Computer Science, 803:230–272, 1994.20

[23] Gregor Kiczales, John Lamping, Anurag Menhdhekar, Chris Maeda, CristinaLopes, Jean-Marc Loingtier, and John Irwin. Aspect-oriented programming.In Proceedings European Conference on Object-Oriented Programming, volume1241, pages 220–242. Springer-Verlag, 1997. 20

[24] Nenad Medvidovic. Formal definition of the Chiron-2 software architecturalstyle. Technical Report UCI-ICS-95-24, Irvine, CA, USA, August 1995. 23

[25] Nenad Medvidovic, Alexander Egyed, and Paul Gruenbacher. Stemming archi-tectural erosion by coupling architectural discovery and recovery. In STRAW’03:Second International SofTware Requirements to Architectures Workshop at ICSE2003, Portland, Oregon, USA, 2003. 17, 19, 20

[26] Nenad Medvidovic and Vladimir Jakobac. Using software evolution to focusarchitectural recovery. Automated Software Engg., 13(2):225–256, 2006. 20, 27

BIBLIOGRAFIA 87

[27] Nenad Medvidovic, David S. Rosenblum, and Richard N. Taylor. A language andenvironment for architecture-based software development and evolution. In ICSE’99: Proceedings of the 21st international conference on Software engineering,pages 44–53, Los Alamitos, CA, USA, 1999. IEEE Computer Society Press. 17,23, 27

[28] Nenad Medvidovic and Richard N. Taylor. A classification and comparisonframework for software architecture description languages. Software Engineering,26(1):70–93, 2000. 8, 10

[29] Tien N. Nguyen, Ethan V. Munson, John T. Boyland, and Cheng Thao. Mol-hado: Object-oriented architectural software configuration management. icsm,00:510, 2004. 24

[30] Eugen Nistor, Justin R. Erenkrantz, Scott A. Hendrickson, and Andre van derHoek. Archevol: Versioning architectural-implementation relationships. In Pro-ceedings of the 12th International Workshop on Software Configuration Manage-ment, Lisbon, Portugal, September 2005. 24, 27, 32

[31] Andres Dıaz Pace and Alvaro Soria. Technical report: Flabot architectural de-sign. 2005. 47

[32] Dewayne E. Perry and Alexander L. Wolf. Foundations for the study of softwarearchitecture. SIGSOFT Softw. Eng. Notes, 17(4):40–52, 1992. 1, 15

[33] Michael Pilato. Version Control With Subversion. O’Reilly & Associates, Inc.,Sebastopol, CA, USA, 2004. 24

[34] Tamar Richner. Using recovered views to track architectural evolution. InECOOP Workshops, pages 74–75, 1999. 17, 18, 19

[35] Roshanak Roshandel, Andre Van Der Hoek, Marija Mikic-Rakic, and NenadMedvidovic. Mae-a system model and environment for managing architecturalevolution. ACM Transactions on Software Engineering and Methodology, 13:240–276, 2004. 24

[36] Neeraj Sangal, Ev Jordan, Vineet Sinha, and Daniel Jackson. Using dependencymodels to manage complex software architecture. In OOPSLA ’05: Proceedingsof the 20th annual ACM SIGPLAN conference on Object oriented programming,systems, languages, and applications, pages 167–176, New York, NY, USA, 2005.ACM Press. 17, 18, 27

[37] Bradley Schmerl and David Garlan. Acmestudio: Supporting style-centered ar-chitecture development. In ICSE ’04: Proceedings of the 26th International Con-ference on Software Engineering, pages 704–705, Washington, DC, USA, 2004.IEEE Computer Society. 8

[38] Mohlalefi Sefika, Aamod Sane, and Roy H. Campbell. Monitoring compliance ofa software system with its high level design models. In Proceedings of the 18th In-ternational Conference on Software Engineering, pages 387–397. IEEE ComputerSociety Press, 1996. 17, 18, 19, 27, 28

[39] Alvaro Soria. Architecture-driven fault localization of implicit invocation sys-tems. In Proceedings ASSE 2004, dentro de las 33 Jornadas Argentinas de In-formatica e Investigacion Operativa (JAIIO), Cordoba, Argentina, September2004. 81, 82

88 BIBLIOGRAFIA

[40] Leon Sterling and Ehud Shapiro. The art of Prolog: advanced programmingtechniques. MIT Press, Cambridge, MA, USA, 1986. 19

[41] Richard Taylor and David Redmiles. Archstudio. SIGSOFT Softw. Eng. Notes,25(1):97, 2000. 24

[42] Andre van der Hoek, Dennis Heimbigner, and Alexander L. Wolf. Softwarearchitecture, configuration management, and configurable distributed systems:A menage a trois. In Technical Report CU-CS-849-98, University of Boulder,CO., USA, January 1998. 17

[43] S. Vestal. A cursory overview and comparison of four architecture descriptionlanguages. Technical report, Honeywell Technology Center, February 1993. 8

[44] H. Yan, D. Garlan, B. Schmerl, J. Aldrich, and R. Kazman. Dis-covering architectures from running systems using colored petri nets.http://www.cs.cmu.edu/afs/cs/project/able/ftp/discotect-jp05/DiscoTect.pdf.17, 18, 20, 27, 28, 32

ArchSync -...

Documents

Transcript of ArchSync -...