ArchSync. Asistencia en la Sincronización de Documentación de Diseño con Implementación. por. Martín Blech y Juan Pablo Carlino

Tamaño: px
Comenzar la demostración a partir de la página:

Download "ArchSync. Asistencia en la Sincronización de Documentación de Diseño con Implementación. por. Martín Blech y Juan Pablo Carlino"

Transcripción

1 ArchSync Asistencia en la Sincronización de Documentación de Diseño con Implementación 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. Andrés Diaz Pace Co-Director: Ing. Álvaro Soria Tandil, Argentina. Octubre de 2006

2 ii

3 Resumen Las arquitecturas de software son modelos de sistemas que, al poseer un alto nivel de abstracción, permiten manejar correctamente la distancia entre requerimientos e implementación. La adopción cada vez mayor del desarrollo centrado en la arquitectura se debe a que éstas exponen las principales decisiones de diseño y sus consecuencias en una etapa temprana del desarrollo de software, y al hacerlo permiten un mejor entendimiento tanto del sistema como de sus requerimientos por parte de todas las personas involucradas. Por estas razones, un buen diseño arquitectónico tiene un impacto positivo en la calidad final de los productos. Normalmente, los desarrolladores toman la descripción arquitectónica del sistema y progresivamente la refinan hasta derivar una implementación concreta. Durante esta actividad, también especifican las relaciones entre el modelo arquitectónico como fue documentado y el modelo arquitectónico como fue implementado, para asegurar cierto grado de consistencia entre los modelos. Desafortunadamente, debido a la evolución natural del sistema, es probable que la arquitectura e implementación pierdan consistencia. Una vez que el diseño arquitectónico está listo, comúnmente todos los esfuerzos se enfocan en la implementación, y ésto desactualiza progresivamente la documentación de diseño. Este fenómeno es conocido como corrimiento arquitecturaimplementación o erosión arquitectónica, y si no es manejado apropiadamente, puede perjudicar los beneficios del desarrollo centrado en la arquitectura. Actualmente, el problema ha sido tratado por medio de algunos enfoques basados en ingeniería reversa, con resultados dispares. La falta de una herramienta de soporte más adecuada para relacionar especificaciones arquitectónicas con código sigue siendo un problema para muchos proyectos de software. En este trabajo, proponemos un enfoque materializado en una herramienta de soporte llamada ArchSync, para asistir a los desarrolladores a conciliar la documentación arquitectónica con su implementación a medida que la segunda cambia con el tiempo. En particular, asumimos que existe alguna documentación arquitectónica previa a la codificación del sistema. Los modelos arquitectónicos son representados con use case maps (UCMs), una notación práctica para especificar tanto componentes como flujos de responsabilidades. Estas responsabilidades son materializadas por clases y métodos en el código. Cuando algo cambia en el código y viola lo que fue prescripto por la arquitectura, ArchSync es capaz de trazar esos cambios hacia la especificación arquitectónica original. Para hacerlo, debemos instrumentar el código de la aplicación y registrar información acerca de su ejecución. Para su análisis, ArchSync compara estos registros con la especificación arquitectónica, usando un conjunto de filtros de reconstrucción, y luego detecta qué UCMs no son consistentes con el código. Además, ArchSync puede proveer una lista de posibles reparaciones para los UCMs, que el desarrollador puede ejecutar para actualizar la arquitectura si es necesario. iii

4 iv

5 Agradecimientos A nuestros padres y demás familiares que nos brindaron su afecto y colaboración durante estos años de estudio. Un especial agradecimiento a nuestro director Andrés Díaz Pace y a nuestro codirector Alvaro Soria, por su colaboración, disposición y confianza brindados durante el desarrollo de este trabajo. A nuestros amigos y compañeros, los cuales supieron estar a nuestro lado en forma incondicional durante todo este tiempo, y de los cuales nos sentimos muy contentos y orgullosos. Gracias! v

6 vi

7 Índice general Resumen Agradecimientos Índice de figuras Índice de cuadros Índice de algoritmos III V IX XI XIII 1. Introducción Motivación Objetivos y restricciones Organización del trabajo Contexto Arquitecturas de software Documentación ADLs Use-Case Maps Notación básica e interpretación Ejemplo Rol en la documentación de arquitecturas Erosión arquitectónica Conclusión Trabajos relacionados Aportes relacionados Estrategias basadas en ingeniería reversa Estrategias basadas en ADLs Estrategias basadas en SCM Resumen de características principales Conclusiones El enfoque ArchSync Análisis Ejemplo: MVC Modelo conceptual Path-Log Matcher Resolución del ejemplo MVC Conclusiones vii

8 viii ÍNDICE GENERAL 5. Diseño e implementación Arquitectura Diff Mapper Source code IDiffMapper Execution Logger Log Analyzer Path-Log Matcher Conclusiones Casos de estudio G Caso Caso FLABot Análisis de resultados Estado de los proyectos ante cambios en la implementación Propuesta de solución de ArchSync Conclusiones y trabajos futuros Trabajos futuros Integración con aspectos estructurales Trazabilidad en métodos de diseño Mapeo de paths con casos de test Especialización del enfoque A. Eclipse y FLABot 79 A.1. Plataforma Eclipse A.1.1. Arquitectura de Plug-ins A.2. FLABot Bibliografía 85

9 Índice de figuras 2.1. AcmeStudio Framework de clasificación y comparación para ADLs. Características esenciales de modelado se resaltan en negrita Ejemplo de UCM UCM de un problema de contención de recursos UCM de una posible situación de deadlock Cambio en la documentación arquitectónica no reflejado en el código Cambio en el código no reflejado en la documentación arquitectónica Matriz de dependencia entre componentes de una arquitectura de capas. Los números indican la intensidad de la dependencia, calculada en función del número de referencias encontradas mediante el análisis estático de clases en cada paquete Java Arquitectura de la herramienta DiscoTect Actividades principales del proceso de recuperación de arquitecturas de Focus Comparación de estructuras jerárquicas de componentes ACME (arquitectura) y ArchJava (implementación) Componentes principales del sistema ArchEvol Ejemplo de un escenario de actualización arquitectura-implementación asistido por ArchEvol Diagrama de componentes para el ejemplo Model-View-Controller de GEF Diagrama UCM para el ejemplo Model-View-Controller de GEF Mapeos clase - componente Mapeos método - responsabilidad Vista general de ArchSync UCM representando el comportamiento de ArchSync Identificación de responsabilidades afectadas por cambios en el código fuente Log de ejecución transformado en una secuencia de activación de responsabilidades Path-Log Matcher (paso #1). Ambos cursores coinciden Path-Log Matcher (paso #2). Ambos cursores coinciden Path-Log Matcher (paso #3). Ambos cursores coinciden Path-Log Matcher (paso #4). Los cursores no coinciden Path-Log Matcher (paso #5). Ambos cursores coinciden Path-Log Matcher (paso #6). Ambos cursores coinciden Path-Log Matcher (paso #7). Ambos cursores coinciden Alternativas de Actualización del UCM ix

10 x ÍNDICE DE FIGURAS 5.1. Estilo data-centered para ArchSync en Eclipse Diagrama de paquetes de ArchSync Diagrama de clase de source code Diagrama de secuencia para la detección de source code Diagrama de secuencia para la detección de paths posiblemente cambiados Diagrama de clases del componente Diff Mapper Configuración de ejecución en Eclipse Relación entre ArchSync y FLABot mediante puntos de extensión Interacción entre ArchSync y FLABot previa a la instrumentación Diagrama de clases de Log Analyzer Diagrama de clases de Path-Log Matcher Representación de paths en Prolog Diagrama de secuencia de Path-Log Matcher Arquitectura de G UCM para la acción eliminar usuario Análisis estático de código fuente durante la detección de paths potencialmente modificados Paths potencialmente cambiados según el análisis estático de código fuente Instrumentación de la aplicación G2 durante el caso de uso eliminar usuario Selección de traza de ejecución para analizar Diálogo Path-Log Matcher Result Primer sugerencia de inserción de la responsabilidad candidata getuseragents(int):java.util.vector. En este caso, no se considera relevante arquitectónicamente Script de actualización para el path eliminar usuario UCM actualizado para la acción eliminar usuario UCM para la acción salir del sistema Script de actualización alternativo para el UCM salir del sistema UCM actualizado para la acción salir del sistema UCMs para la acciones insertar fork, rotar fork e insertar responsabilidad Vista de ArchSync en Eclipse, mostrando el conjunto de paths de FLABot identificados como posiblemente cambiados Script de actualización para el path insertar fork UCM actualizado para la acción insertar fork Diálogo Path-Log Matcher Result Script de actualización para el path rotar fork UCM actualizado para la acción rotar fork Script de actualización para el path insertar responsabilidad UCM actualizado para la acción insertar responsabilidad Clases con mapeo cambiadas vs. paths afectados Complejidad del path vs. alternativas de conciliación A.1. Arquitectura de Plug-ins de Eclipse A.2. Comunicación entre Plug-ins de Eclipse A.3. Esquema de funcionamiento de FLABot A.4. Editor de componentes UML de FLABot A.5. Editor de UCM de FLABot

11 Índice de cuadros 2.1. Espectro de aplicación de ADLs Características principales de los distintos enfoques Operaciones atómicas de actualización de UCMs Ejemplo de log de ejecución Estado del proyecto ante cambios en la implementación Complejidad de los paths existentes y de las soluciones propuestas.. 72 xi

12 xii ÍNDICE DE CUADROS

13 Índice de algoritmos 1. Violación al estilo Model-View-Controller a nivel de código. La divergencia introducida por el desarrollador se subraya Algoritmo Path-Log Matcher Algoritmo Log Analyzer xiii

14 xiv ÍNDICE DE ALGORITMOS

15 Capítulo 1 Introducción El desarrollo centrado en la arquitectura está siendo ampliamente aceptado como una práctica de ingeniería de software. Cada vez más, tanto investigadores como equipos de desarrollo reconocen que las arquitecturas de software son modelos muy convenientes para hacer diseño de software [6], ya que estos modelos permiten a los desarrolladores manejar la distancia entre requerimientos e implementación en un alto nivel de abstracción. El valor de tener un modelo arquitectónico reside en que documenta los motivos principales del diseño en una etapa temprana del proceso de desarrollo, describe las estructuras principales del sistema en construcción y, por lo tanto, impacta la calidad final de los productos. Siguiendo esta línea, los desarrolladores normalmente toman la descripción arquitectónica del sistema y progresivamente la refinan hasta derivar una implementación concreta. Durante esta actividad, también especifican las relaciones entre el modelo arquitectónico como fue documentado y el modelo arquitectónico como fue implementado [6, 16], para asegurar cierto grado de consistencia entre los modelos. Actualmente existen varias notaciones y perfiles para este propósito [16] Motivación Desafortunadamente, debido a la evolución natural del sistema, es probable que la arquitectura e implementación pierdan consistencia. Una vez que el diseño arquitectónico está listo, comúnmente todos los esfuerzos se enfocan en la implementación, y ésto desactualiza progresivamente la documentación de diseño. Por ejemplo, nuevos requerimientos pueden causar un rediseño de la arquitectura, con consecuentes cambios en algunas partes de la implementación; y viceversa, tareas de mantenimiento pueden producir cambios en el código que deberían ser actualizados en la arquitectura. En estos casos, las relaciones de componentes (en el nivel arquitectónico) con clases y métodos (en el nivel de implementación) no siempre se mantienen, y los desarrolladores deben restaurar manualmente la consistencia. Este fenómeno es conocido como corrimiento arquitectura-implementación [32] o erosión arquitectónica, y si no es manejado apropiadamente, puede realmente perjudicar los beneficios del desarrollo centrado en la arquitectura. Actualmente, el problema ha sido tratado por medio de algunos enfoques basados en ingeniería reversa, con resultados dispares. La falta de una herramienta de soporte más adecuada para relacionar especificaciones arquitectónicas con código sigue siendo un problema para muchos proyectos de software. En este trabajo, proponemos un enfoque materializado en una herramienta de soporte llamada ArchSync, para asistir a los desarrolladores a conciliar la documentación arquitectónica con su implementación a medida que la segunda cambia 1

16 2 CAPÍTULO 1. INTRODUCCIÓN con el tiempo. El enfoque ArchSync ha sido desarrollado en el contexto del proyecto FLABot, una herramienta de debugging que se basa en información arquitectónica para aproximar las regiones de código donde es más probable que se hayan originado las fallas (ver Apéndice A.2). En particular, asumimos que existe alguna documentación arquitectónica previa a la codificación del sistema. Los modelos arquitectónicos son representados con use case maps (UCMs)[11], una notación práctica para especificar tanto componentes como flujos de responsabilidades. Estas responsabilidades son materializadas por clases y métodos en el código. Cuando algo cambia en el código y viola lo que fue prescripto por la arquitectura, ArchSync es capaz de localizar esos cambios en la especificación arquitectónica original. Para hacerlo, se debe instrumentar el código de la aplicación y registrar información acerca de su ejecución. Para su análisis, ArchSync compara estos registros con la especificación arquitectónica, usando un conjunto de filtros de reconstrucción, y luego detecta qué UCMs no son consistentes con el código. Además, ArchSync puede proveer una lista de posibles reparaciones para los UCMs, que el desarrollador puede ejecutar para actualizar la arquitectura si es necesario. De esta manera, el desarrollador está siempre consciente del estado de trazabilidad entre la especificación arquitectónica y el código Objetivos y restricciones Como objetivo principal del trabajo se propuso encontrar diferencias entre una descripción realizada en UCMs y el código fuente de su implementación. El análisis automatizado de estas diferencias, además, se debe usar para asistir al usuario en la generación de una nueva versión de los UCMs afectados donde esas diferencias han sido resueltas. Por otro lado, el análisis de algunos trabajos similares puso a la luz ciertas características que pueden dificultar la aplicación de un enfoque de esta naturaleza en un proceso de desarrollo de software. Por esta razón se impusieron las siguientes restricciones: Limitar la información requerida del usuario a UCMs, código fuente e información que relacione elementos individuales de la arquitectura con porciones de código. Toda información adicional deberá ser derivable a partir del análisis automático de estos tres elementos dados como entrada. No se deberá imponer el uso de un lenguaje de programación de propósito específico, ni un estilo o un conjunto de convenciones de implementación en particular. De esta forma será posible la aplicación del enfoque a sistemas existentes. Tampoco se deberá imponer un proceso demasiado estricto para la modificación tanto de la arquitectura como del código. Así, el desarrollador tendrá el control de cuándo y cómo sincronizar los UCMs con la implementación Organización del trabajo El resto de este trabajo se encuentra organizado de la siguiente manera. En el capítulo 2 se presentan los conceptos de Arquitecturas de Software, Lenguajes de Descripción de Arquitecturas (ADLs), Use Case Maps y Erosión Arquitectónica, que son las nociones principales en las que está basado nuestro enfoque. Una vez introducido el contexto, en el capítulo 3 se analizan y comparan algunos trabajos relacionados que, de diferentes maneras, apuntan a solucionar el problema de erosión arquitectónica.

17 1.3. ORGANIZACIÓN DEL TRABAJO 3 Luego de este análisis, en el capítulo 4 se explica el enfoque ArchSync, detallando cada uno de los pasos que propone para la actualización de use case maps. Dado que el enfoque requirió la construcción de una herramienta de soporte, en el capítulo 5 se presentan su diseño y los aspectos más importantes de su implementación. A modo de casos de estudio, se ejercitó la herramienta implementada con el historial de desarrollo de G2 una aplicación comercial desarrollada en un proyecto de transferencia con la empresa Delsat, S.A. y de FLABot una herramienta realizada dentro de un proyecto de investigación. Más adelante, en el capítulo 6, se presentan los resultados de estos casos de estudio. Finalmente, en el capítulo 7 se presentan las conclusiones del trabajo, junto con algunas propuestas para posibles trabajos futuros.

18 4 CAPÍTULO 1. INTRODUCCIÓN

19 Capítulo 2 Contexto En este capítulo se ofrecerá una introducción a los conceptos centrales sobre los que se ha realizado este trabajo. En primer lugar se define la noción de Arquitectura de Software en la sección 2.1, enfatizando la importancia de su documentación dentro de la organización y en particular para el equipo de desarrollo, para luego dar en la sección 2.2 una introducción a los lenguajes de descripción de arquitecturas (ADLs). En la sección 2.3 se presentan los Use-Case Maps, una notación simple y efectiva para la documentación de comportamiento a nivel arquitectónico. Luego, en la sección 2.4 se introduce un problema relacionado con las arquitecturas de software conocido como erosión arquitectónica, explicando las condiciones donde ocurre y las graves consecuencias que presenta para el desarrollo de software. Por último, en la sección 2.5 y a modo de resumen, se resaltan los conceptos clave detallados en este capítulo Arquitecturas de software Si bien no existe una única definición de arquitectura de software universalmente aceptada, generalmente todas lo hacen en función de conceptos comunes. En todas se encuentra la noción de descomposición de un sistema en diferentes partes, de relaciones existentes entre estas partes, de abstracción de las propiedades que no sean externamente visibles ni relevantes para la interacción de sus elementos. Adicionalmente, se sabe que existen diferentes perspectivas desde las que se puede observar un sistema según las propiedades de interés y que ninguna de estas vistas conforma la arquitectura en si. En su libro Software Architecture in Practice [6], Bass et.al. proponen una definición que abarca gran parte de las características antes mencionadas: La arquitectura de software de un programa o sistema de computación es la estructura o estructuras del sistema, las cuales abarcan los elementos de software, las propiedades externamente visibles de esos elementos, y las relaciones entre ellos. Como se desprende de esta definición, una arquitectura de software puede abarcar más de una estructura o vista. Un ejemplo que puede ilustrar esta propiedad es observar la estructura que presentan normalmente los proyectos de desarrollo. Generalmente éstos son particionados en módulos con una cierta cantidad de responsabilidades fundamentales asignadas, que luego son asignadas a diferentes equipos para su desarrollo. Cada uno de estos módulos contiene programas y datos accesibles desde otros elementos, además de otros atributos que son privados. Éste tipo de estructura se emplea a menudo para describir un sistema y define principalmente cómo se divide y 5

20 6 CAPÍTULO 2. CONTEXTO asigna su funcionalidad, por esta razón, representa una perspectiva estática. Por otro lado, existen estructuras que centran su atención en cómo los elementos interactúan en tiempo de ejecución para alcanzar la funcionalidad propuesta. Aquí el foco se pone sobre la manera en que los diferentes módulos interactúan para ejecutarse en diferentes procesos y como se comunican y sincronizan entre ellos. A pesar de que ambas vistas aportan información sobre la arquitectura, ninguna de ellas la describe en su totalidad. La definición precedente también caracteriza a las vistas del sistema por estar compuestas de elementos de software, de propiedades externamente visibles y de relaciones entre ellos. Esto implica que no es relevante en este nivel, y por lo tanto se omite, la información de los elementos que no es pertinente a su interacción. Justamente por ser una abstracción de un sistema complejo, la arquitectura de software oculta los detalles que no afectan la manera en que los diferentes elementos usan, son usados por, se relacionan con o interactúan con otros elementos. Una de las implicancias de la definición de arquitectura, es su omnipresencia en cualquier sistema de software, aunque ésta no se encuentre documentada. Cualquier sistema posee elementos distinguibles con propiedades y relaciones asociadas, sin embargo no siempre existe alguien que conozca esta arquitectura, de aquí que resulte muy importante su documentación. Finalmente, de la definición se deduce que el comportamiento de los elementos de software también forma parte de la arquitectura. Tal como ocurre con las propiedades meramente internas de los elementos de software, el comportamiento relevante en este nivel (y por lo tanto, integrante de la arquitectura) es aquel que afecte cómo los demás elementos tienen que ser escritos y de qué manera deben comunicarse con él, como así también aquellos que determinen el cumplimiento o no de alguna característica deseable en el sistema completo Documentación La documentación de una arquitectura es una etapa crucial de su construcción. Incluso con una arquitectura excelente, si ésta 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 con suficiente detalle, sin ambigüedad y organizada de manera tal que los demás puedan encontrar la información que necesitan. Si no se logra esto, todo el esfuerzo habrá sido en vano ya que la arquitectura no podrá ser usada. La documentación de la arquitectura es tanto prescriptiva como descriptiva [6]. Ésto es, para desarrolladores con determinados roles, ella impone restricciones que deben cumplirse al momento de tomar decisiones de diseño más detallado. Para otras audiencias, su documentación describe las decisiones tomadas sobre el diseño y por lo tanto, que cosas son ciertas sobre la arquitectura. Quizás el concepto más importante asociado con la documentación de arquitecturas de software es el de vista. Recordando la definición de la sección anterior, vemos a la arquitectura como la estructura o estructuras del sistema, que abarcan los elementos, sus propiedades externamente visibles, y las relaciones entre ellos. Una vista es una representación coherente de esos los elementos importantes que constituyen un sistema, tal como lo son el software o el hardware, respecto a la forma en que los involucrados la leen y escriben. La vista provee el principio básico de la documentación de una arquitectura de software: Documentar una arquitectura significa documentar las vistas relevantes y luego agregar la documentación que se aplica a más de una vista.

21 2.1. ARQUITECTURAS DE SOFTWARE 7 Éste principio es útil porque separa el problema de la documentación en las siguientes partes [16]: Elección de las vistas relevantes. La elección depende de los usos que se le espera dar a la documentación. A través de estas vistas se deben expresar al menos tres aspectos del sistema: (a) cómo está estructurado el conjunto de unidades de implementación, (b) cómo está estructurado el conjunto de elementos que tienen comportamiento e interacciones en tiempo de ejecución y (c) cómo se relaciona con elementos de su ambiente que no son software. Documentación de una vista. Si bien no existe un template estándar de documentación de vistas, es esperable que contenga al menos la siguiente información: 1. Presentación primaria: por lo general es un gráfico; presenta los elementos principales y sus relaciones. 2. Catálogo de elementos: detalla los elementos y relaciones presentados en la presentación primaria. 3. Diagrama de contexto: muestra cómo lo reflejado en la vista se relaciona con su ambiente usando el vocabulario de la misma. 4. Guía de variabilidad: explica en detalle los puntos de variación que son parte de la arquitectura y están explicados en esta vista. 5. Razonamiento arquitectónico: explica cómo el diseño reflejado en esta vista llegó a ser como es. 6. Glosario de términos. 7. Otra información. Documentación de comportamiento. Las vistas presentan información estructural del sistema. Sin embargo, ésta información no es suficiente para razonar acerca de ciertas propiedades del mismo. Exactamente qué aspectos del comportamiento modelar va a depender del tipo de sistema que se está diseñando: en un sistema de tiempo real importan las propiedades temporales de los eventos; mientras que en un sistema bancario las secuencias de eventos, las transacciones atómicas y los procedimientos de rollback son lo más importante. Documentación de la información que se aplica a más de una vista. Constituye el complemento de la documentación de las vistas, es decir la información que se aplica a más de una vista o al paquete de documentación en sí. Consiste de tres aspectos principales, el cómo, el qué y el por qué: Cómo está organizada la documentación, de manera que los interesados en la arquitectura pueden encontrar la información que necesitan eficientemente. Qué es la arquitectura: una descripción general del sistema para orientar al lector acerca del propósito del sistema, la forma en que las vistas se relacionan entre sí, una lista de elementos y dónde aparecen, y un glosario que se aplica a toda la arquitectura. Por qué la arquitectura es como es: el contexto del sistema, restricciones externas que han sido impuestas para darle forma a la arquitectura de cierta manera, y el razonamiento para las decisiones de mayor granularidad y escala.

22 8 CAPÍTULO 2. CONTEXTO Figura 2.1: AcmeStudio La documentación de la arquitectura libera al arquitecto de tener que contestar cientos de preguntas acerca de ella. Para crear la documentación, se deben entender a todas las partes interesadas y cómo esperan usarla. Por lo tanto, todos los interesados deben ser tenidos en cuenta a la hora de elegir las vistas relevantes ADLs El desarrollo de software basado en arquitectura ha desplazado el foco de atención sobre las líneas de código hacia elementos arquitectónicos de mayor granularidad (componentes de software y conectores) y en la estructura de interconexión entre ellos. Para soportar al desarrollo basado en la arquitectura, son necesarias notaciones formales de modelado y análisis junto con herramientas de desarrollo que operen sobre las especificaciones arquitectónicas. Ante esta necesidad, se han propuesto los lenguajes de descripción arquitectónica (ADLs) y sus respectivas herramientas. Definido de forma general, un ADL para aplicaciones de software se centra en la estructura de alto nivel de la aplicación general en lugar de los detalles de implementación de módulos específicos [43]. Varios ADLs han sido propuestos para el modelado de arquitecturas tanto para dominios particulares como para propósitos generales. Entre ellos podemos destacar Aesop, ArTek, C2, Darwin, LILEANNA, MetaH, Rapide, SADL, UniCon, Weaves y Wright. También se ha trabajado en un lenguaje de intercambio arquitectónico llamado ACME [21], para soportar el mapeo de especificaciones arquitectónicas entre diferentes ADLs y por tanto, permitir la integración de herramientas de soporte como AcmeStudio (Figura 2.1) [37]. Aunque ACME no es estrictamente un ADL, comparte varias de sus características. Sin embargo, aún no hay mucho consenso en la comunidad sobre lo que realmente es un ADL, qué aspectos de una arquitectura deberían ser modelados por un ADL y qué debería ser intercambiado en un lenguaje de intercambio. Recientemente Medvidovic et. al. [28] han propuesto una definición en base a la de

23 2.2. ADLS 9 Figura 2.2: Framework de clasificación y comparación para ADLs. Características esenciales de modelado se resaltan en negrita. arquitectura de software presentada en la sección 2.1, donde enuncian que un ADL es un lenguaje que ofrece características para modelar la arquitectura conceptual de un sistema de software, distinguida de la implementación del sistema. Los ADLs proveen tanto una sintaxis concreta como un framework conceptual para caracterizar arquitecturas [20]. El framework conceptual refleja características del dominio para el cual se pretende el ADL y/o el estilo arquitectónico. Este framework suele incluir la teoría semántica detrás del ADL en cuestión (por ejemplo, redes de Petri, máquinas de estado, etc.). A su vez, Medvidovic et. al. definen los requerimientos de un ADL y un framework de clasificación: un ADL debe modelar explícitamente componentes, conectores y sus configuraciones; mas aún, para ser auténticamente útil y usable, debe ofrecer una herramienta de soporte para el desarrollo y la evolución basada en la arquitectura. Los elementos fundamentales de un ADL son los componentes, los conectores y las configuraciones arquitectónicas. Para poder inferir cualquier tipo de información sobre una arquitectura, al menos las interfaces de los componentes constituyentes deben modelarse. Sin esta información, una descripción arquitectónica se transformaría en una colección de identificadores interconectados, similar a los diagramas de cajas y líneas sin semántica detrás. Si bien cada ADL tiene características propias, todos comparten ciertos conceptos y estructuras principales: Componentes. Representan los elementos primarios de un sistema, tanto computacionales como de almacenamiento de información. Además, los componentes constan de interfaces, que son puntos especialmente designados para interactuar con el ambiente. Conectores. Representan las interacciones entre componentes, es decir que actúan como mediadores en la comunicación y coordinación de actividades entre com-

24 10 CAPÍTULO 2. CONTEXTO ADL ACME C2 MetaH Rapide UniCon Foco Intercambio Arquitecturas de Arquitecturas Modelado y Generación de arquitectónico, sistemas dentro del simulación del código para predominante- altamente dominio del comportamiento interconectar mente en el nivel distribuidos, control, descripto por componentes estructural evolutivos y navegación y una arquitectura existentes dinámicos asistencia utilizando (GN&C) protocolos comunes de interacción Cuadro 2.1: Espectro de aplicación de ADLs ponentes. También tienen interfaces, que definen los roles que los componentes pueden cumplir en las interacciones que describen. Sistemas. Pueden ser vistos como grafos o configuraciones de componentes y conectores. Pueden ser jerárquicos, de manera que los componentes y conectores pueden representar internamente subsistemas con diferentes arquitecturas. Propiedades. Se usan generalmente para representar información semántica acerca de un sistema que va más allá de la estructura. Restricciones. Representan reglas de diseño o sentencias invariantes que deberían ser ciertas a lo largo de la evolución del diseño arquitectónico. Estilos. Pueden ser vistos como familias de sistemas relacionados. Un estilo arquitectónico define básicamente un vocabulario de tipos de elementos de diseño y de reglas para componerlos. En la Figura 2.2 se muestra el framework de clasificación y comparación para ADLs propuesto en [28]. Independientemente de la naturaleza del ADL (propósito específico o general), los tipos deseados de representación, manipulación y las cualidades de los modelos arquitectónicos identificados en la Figura 2.2 se mantienen constantes. En el cuadro 2.1 se pueden ver los espectros de aplicación de algunos ADLs muy difundidos Use-Case Maps Los use case maps (UCM) son una notación para diseño de alto nivel que ayuda a las personas tanto a expresar como a razonar acerca de los patrones de comportamiento de alta granularidad de un sistema [11]. El nombre proviene del hecho de que son una notación visual para casos de uso y una extensión de ellos hacia el diseño de alto nivel. Sin embargo, el modelo no depende de la definición de casos de uso: provee su propia definición en sus propios términos. Los UCMs no son un lenguaje apropiado para especificación formal de comportamiento, ya que deliberadamente dejan algunas decisiones abiertas para ser tomadas durante el diseño detallado. Los UCM son solamente una notación para razonar y explicar el comportamiento de un sistema. Es importante de tener esto presente ya que es fácil caer en la trampa de buscar o colocar más información de la que corresponde encontrar en ellos.

25 2.3. USE-CASE MAPS Notación básica e interpretación A continuación se da una breve descripción de los diferentes elementos visuales que conforman la notación, junto con los conceptos asociados a cada uno de ellos. La idea principal detrás de los UCMs es la de modelar los casos de uso mediante secuencias causales (en adelante, paths) a través de estructuras organizacionales, de esta manera combinando vistas estructurales y comportamentales de la arquitectura del sistema. Los UCMs tienen cuatro elementos principales: responsabilidades, paths, componentes y acoplamientos entre paths. Responsabilidades. Expresan las funciones de las que cada componente es responsable. Paths. Trazan la progresión de causas y efectos entre responsabilidades. Componentes. Actúan como contenedores de responsabilidades. Acoplamientos. Sirven para conectar paths y así lograr patrones de mayor granularidad. And Forks. Indican la bifurcación en dos paths concurrentes. And Joins. Indican la unión de dos paths concurrentes. Or Forks. Indican el fin de un segmento causal común entre dos paths. Or Joins. Indican el comienzo de un segmento causal común entre dos paths Ejemplo La Figura 2.3 muestra un ejemplo de UCMs, donde hay un simple escenario de asignación de nombre de usuario para un sistema de manejo de cuentas de usuario. El sistema está organizado alrededor de un estilo Model-View-Controller [13], en el cual el componente Model y sus componentes View están desacoplados por medio de un componente Controller. La responsabilidad receivewidgetevent en Controller traduce el evento producido por una View a la responsabilidad setusername en Modelo, la cual entonces activa la responsabilidad notifymodelobservers también en Model. Cuando se envía una notificación de cambio desde Model a Controller, ésto causa la activación de la responsabilidad handlemodelchangeevent, lo que finalmente dispara la actualización de View al ejecutar la responsabilidad updateview.

26 12 CAPÍTULO 2. CONTEXTO Figura 2.3: Ejemplo de UCM Rol en la documentación de arquitecturas Documentar el comportamiento añade detalle semántico relacionado con el tiempo a los elementos y sus interacciones. Los modelos comportamentales agregan información que revela el orden de las interacciones entre los elementos, las oportunidades para concurrencia, y las dependencias que tienen las interacciones con el tiempo. Para atribuir comportamiento a elementos de una descripción arquitectónica, es necesario agregar tejido conectivo [9, 10]. Una forma de introducir este tipo de tejido es usar conexiones que soportan interacciones (llamadas o mensajes) entre elementos a través de interfaces. Dichas interfaces definen los nombres y parámetros de todas las posibles interacciones, ocultando detalles de la lógica interna de los componentes. A estas conexiones se les puede atribuir comportamiento al describir escenarios de interacción usando diagramas de interacción UML (también conocidos como diagramas de secuencia de mensajes). Sin embargo, la combinación de conexiones, documentación de interfaces y diagramas de interacción muchas veces se excede en cantidad de detalles -tales como operaciones, ensamblaje y estructura de herencia en sistemas orientados a objetos- y hace difícil entender sistemas de cualquier tamaño y complejidad. Es necesario tomar distancia de estos detalles para entender un sistema en términos arquitectónicos. Los UCMs suben el nivel de abstracción al simplificar los más importantes factores de complejidad: Operaciones. Las secuencias de invocación de operaciones son reemplazadas por paths causa-efecto. El comportamiento no se representa en términos de interacciones entre componentes a través de mensajes, sino en términos de secuencias causa-efecto entre responsabilidades de los componentes. En otras palabras, las interfaces de los componentes, y las interacciones entre interfaces, tales como llamadas y mensajes, son consideradas detalles. Las responsabilidades pueden ser de mayor granularidad que las llamadas y mensajes, y de esta manera se reduce el nivel de compromiso con los detalles. Ensamblaje y Estructura de Herencia. A nivel de UCMs, el único requerimiento para la conectabilidad de un componente es que sea capaz de realizar las responsabilidades requeridas. Los detalles necesarios para realmente conectar (física o lógicamente) un componente pueden ser diferidos hacia otro tipo de documentación. A su vez, la dependencia de las descripciones de comportamien-

27 2.4. EROSIÓN ARQUITECTÓNICA 13 Figura 2.4: UCM de un problema de contención de recursos Figura 2.5: UCM de una posible situación de deadlock to sobre los detalles como la estructura de herencia también es eliminada por el hecho de que los UCMs son modelos independientes de las descripciones de clases. Los UCMs pueden ser derivados a partir de requerimientos informales o de casos de uso, si están disponibles. Las responsabilidades tienen que estar especificadas o ser inferidas de estos requerimientos. Se pueden crear casos de uso separados para funcionalidades individuales del sistema o inclusive para escenarios individuales. Muchas veces, la forma de modelar una interacción con UCMs depende de la intención del arquitecto. Sin embargo, el fuerte de esta notación reside principalmente en la integración de escenarios relacionados. En tales casos, los UCMs pueden usarse para ilustrar y razonar respecto a concurrencia, como por ejemplo en problemas de contención de recursos (múltiples paths usando un elemento, como se muestra en la Figura 2.4) o posibles situaciones de deadlock (dos paths en direcciones opuestas a través de al menos dos elementos en común, como se muestra en la Figura 2.5) Erosión arquitectónica En la sección se explicaron las razones principales por las que la documentación de una arquitectura es fundamental para el desarrollo de software. La documentación es la vía de comunicación entre desarrolladores, y permite que el sistema se diseñe, implemente, pruebe, instale y mantenga siguiendo a la arquitectura que lo sostiene. Por otro lado, asegurarse de que un sistema sea construido en conformidad con su diseño arquitectónico durante su desarrollo, evolución y mantenimiento es importante, ya que divergencias significativas entre arquitectura e implementación pueden comprometer la estructura, estilo y propiedades que han sido establecidas mediante cuidadoso análisis a nivel arquitectónico [1]. Durante las diferentes etapas del desarrollo de software, pueden producirse cambios en la documentación arquitectónica que luego no son reflejados en el código (Figura 2.6), o cambios en el código que no son apropiadamente acomodados en la documentación (Figura 2.7). Siendo la arquitectura una guía fundamental durante todo el ciclo de vida del sistema, el desfasaje entre documentación e implementación de una arquitectura se hará cada vez más difícil de remediar por sus desarrolladores, finalmente deteriorando la calidad del producto.

28 14 CAPÍTULO 2. CONTEXTO Figura 2.6: Cambio en la documentación arquitectónica no reflejado en el código. Figura 2.7: Cambio en el código no reflejado en la documentación arquitectónica.

29 2.5. CONCLUSIÓN 15 Durante la última década, han sido desarrollados y aplicados varios modelos y análisis de arquitecturas de software, para el estudio de la confiabilidad o la performance. Sin embargo, éstos análisis de propiedades arquitectónicas pueden predecir la calidad del sistema siempre y cuando éste haya sido implementado y mantenido de acuerdo a lo prescripto por la arquitectura. El desarrollo de un sistema de software confiable entonces necesita de la prevención y corrección de violaciones a las prescripciones arquitectónicas. Desafortunadamente, debido a la evolución natural del sistema, es probable que la arquitectura y la implementación pierdan consistencia. Una vez que el diseño arquitectónico está listo, típicamente todos los esfuerzos se focalizan en la implementación, y esto hace que la documentación se desactualice progresivamente. Por ejemplo, nuevos requerimientos pueden causar un rediseño de la arquitectura, con cambios consecuentes en algunas partes de la implementación; y por otro lado, algunas tareas de mantenimiento pueden producir cambios en el código que deberían ser reflejados en modificaciones de la arquitectura. Si bien es aceptable que exista temporalmente cierto desfasaje, normalmente los desarrolladores trabajan en la implementación sin mantener el modelo arquitectónico, el cual rápidamente queda desactualizado. En algunos casos, los desarrolladores pueden introducir sutiles diferencias estructurales que invalidan intenciones claves de la arquitectura. Por ejemplo, en un sistema estructurado en capas, es posible que un programador inadvertido genere dependencias no deseadas al saltear la capa inmediatamente inferior. Análogamente, en el desarrollo de sistemas web multibanda es común el error de invocar directamente a la base de datos desde la banda de presentación. Como resultado, los arquitectos a menudo deben lidiar en sus análisis con conocimiento incompleto e incorrecto debido a defectos en la documentación [2]. En estos casos, las relaciones de los componentes (en el nivel arquitectónico) con clases y métodos (en el nivel de implementación) ya no se mantienen, y los desarrolladores deben restablecer la consistencia manualmente. Éste fenómeno se conoce como corrimiento arquitectura-implementación [32] o erosión arquitectónica. Si no se maneja correctamente, revierte los beneficios del desarrollo centrado en la arquitectura, ya que se pierde la trazabilidad entre requerimientos, decisiones de diseño y artefactos de implementación. Hasta hoy en día, el problema ha sido atacado a través de enfoques basados en ingeniería reversa, con resultados dispares. La falta de herramientas de soporte adecuadas para generar código por medio de especificaciones arquitectónicas es todavía un problema para muchos proyectos de software Conclusión En este capítulo se introdujo el concepto de arquitectura de software, una disciplina que cumple un rol central en la toma de decisiones de diseño y en la comunicación entre todos los participantes del desarrollo de un producto de software. Como vehículo de comunicación, su documentación es fundamental, pues la falta de ella, o peor aún, el descuido al producirla y mantenerla, anulan o revierten todos los beneficios que el desarrollo centrado en la arquitectura puede aportar. Posteriormente se presentó la notación de UCMs, un modelo para la descripción de patrones de comportamiento y algunos aspectos estructurales en un alto nivel de abstracción y granularidad. Esta notación es especialmente útil para la documentación de comportamiento a nivel arquitectónico, ya que permite expresar, analizar y comunicar las trazas causa-efecto que proyectan los casos de uso sobre el sistema, dejando de lado los detalles contextualmente irrelevantes. En último lugar se ofreció una breve descripción al problema de erosión arqui-

30 16 CAPÍTULO 2. CONTEXTO tectónica. Debido a la evolución natural de un sistema de software, es muy probable que la arquitectura documentada y su implementación pierdan consistencia, lo que puede perjudicar todos los beneficios del desarrollo centrado en la arquitectura. Éste problema ha motivado la creación de herramientas que, mediante diversos enfoques, intentan mantener la consistencia documentación-implementación. El capítulo siguiente se centra precisamente en estas herramientas.

31 Capítulo 3 Trabajos relacionados El problema de la erosión arquitectónica junto con la necesidad de prevenir o minimizar sus consecuencias han sido reconocidos en el capítulo anterior como motivadores principales de este trabajo. El desarrollo de software centrado en la arquitectura es una práctica relativamente nueva que ha demostrado claramente sus beneficios cuando se pone en práctica; principalmente en pos de la calidad del software en su ciclo de vida completo. Sin embargo, aprovechar sus ventajas demanda un costo: mantener la documentación de la arquitectura consistente con su implementación [42]. Un desarrollo de software que pretenda basarse en una arquitectura sin propagar apropiadamente los cambios al resto de los modelos, en particular de su especificación arquitectónica, corre mayores riesgos de deteriorarse e incluso fracasar. En este capítulo intentaremos brindar una visión mas amplia sobre los distintos aportes existentes relacionados con la erosión arquitectónica, destacando los rasgos principales de cada enfoque Aportes relacionados El problema de erosión arquitectónica ha sido tratado de diferentes maneras. Básicamente, podemos reconocer dos grupos de enfoques: uno centrado en la recuperación de la arquitectura a través de técnicas de ingeniería reversa [34, 36, 38, 8, 18, 25, 44], y otro usando lenguajes de descripción arquitectónica (ADLs) como soporte [2, 27]. Podríamos ver ambas técnicas como enfoques correctivos y preventivos respectivamente. Las soluciones basadas en la ingeniería reversa pretenden reconstruir parcialmente una arquitectura en función de su código fuente o implementación para compararla posteriormente con la propuesta inicial del arquitecto. Suponiendo que un analizador de código fuente fuera capaz de realizar el proceso inverso de abstraer y especificar una arquitectura que represente fielmente lo que su materialización implica, se estaría solucionando el problema de inconsistencia entre ambos modelos, lo que significa tener a cada instante una arquitectura que refleja las propiedades principales del sistema. En otras palabras, podría controlarse la evolución de la arquitectura permitiendo detectar erosiones en zonas no deseadas. Este es un posible camino para atacar el problema de la erosión arquitectónica. Por otro lado, es viable también tomar una postura conservadora, en el sentido de evitar torcer las restricciones impuestas por una arquitectura desde su concepción. Siendo fundamental en el desarrollo centrado en arquitectura que toda etapa de implementación sea precedida por otra de diseño arquitectónico [7], sea este un ciclo de desarrollo en cascada, evolutivo o iterativo; podría optarse por impedir, de alguna manera, que la implementación viole o erosione, su arquitectura maestra. 17

32 18 CAPÍTULO 3. TRABAJOS RELACIONADOS Lamentablemente ambas soluciones poseen inconvenientes. La técnica está limitada por la inherente diferencia entre estructuras estáticas (basadas en código, como clases y paquetes) y las estructuras en tiempo de ejecución, que son la esencia de la mayoría de las descripciones arquitectónicas. Las estructuras pueden ser incluso desconocidas hasta que el programa se ejecuta: clientes y servidores pueden aparecer y desaparecer dinámicamente; componentes (por ejemplo, DLLs) fuera del control directo de los implementadores pueden cargarse dinámicamente, y así podrían enumerarse otros ejemplos [44]. También existe información semántica que se pierde cuando una arquitectura es implementada mediante clases y métodos, haciendo imposible su recuperación mediante ingeniería reversa. Las representaciones generadas utilizando esta técnica pueden aplicar información adicional provista por estándares como patrones, estilos arquitectónicos o incluso heurísticas para abstraer la información contenida en el código, sin embargo esta representación puede no ser necesariamente la pretendida por el arquitecto. Por otro lado, forzar el cumplimiento de las restricciones impuestas por la arquitectura tampoco es la solución definitiva para la erosión arquitectónica, pues para dictar tales restricciones a una implementación es necesario un lenguaje de especificación suficientemente rico en semántica y por lo tanto, de carácter mas formal, algo que en muchos proyectos puede resultar impracticable. Además, como veremos más adelante, las técnicas basadas en ADLs suelen ser poco útiles cuando los cambios se producen en la implementación antes que en la descripción arquitectónica Estrategias basadas en ingeniería reversa Los enfoques propuestos en [34, 36, 38], definen un conjunto de reglas que especifican la intención del arquitecto, definiendo las relaciones permitidas y prohibidas entre los componentes de software. Estas reglas pueden entonces ser usadas en cualquier momento para realizar análisis estático y/o dinámico sobre el código fuente para detectar lugares donde las prescripciones arquitectónicas no son respetadas. Sangal et.al. [36], por citar un ejemplo de esta clase, basan su enfoque en dos elementos clave de la arquitectura de software: la descomposición jerárquica de componentes estructurales de un sistema y el control explícito sobre las dependencias habilitadas y deshabilitadas entre ellos. En base a tales elementos, el arquitecto construye una Matriz de Dependencia Estructural (DSM) para representar la arquitectura de software como un grafo de dependencias, indicando cuáles son posibles y cuáles son prohibidas. Una matriz de ejemplo extraída del trabajo puede observarse en la Figura 3.1. Esta representación es informal y por otro lado, se representan exclusivamente los aspectos de interés para la sincronización. Claramente este enfoque solo considera el aspecto estructural de una arquitectura. Las unidades atómicas de estos componentes son las clases Java y la abstracción de éstos se simplifica en función de la estructura jerárquica de paquetes Java del proyecto, representando el paquete raíz al sistema completo, ésta es sin dudas una clara simplificación del mapeo entre arquitectura y código. Un posterior análisis estático de código fuente detectará las dependencias existentes entre estos componentes, para comparar la matriz DSM resultante con la especificada de antemano por el arquitecto. Las dependencias etiquetadas como prohibidas por el diseñador permiten a esta herramienta alertarlo ante estados durante el desarrollo donde la implementación no respete estas restricciones. Así, en caso de descubrirse relaciones de estas características en el análisis estático, el equipo de desarrollo tendría la oportunidad de saberlo y por tanto, de tomar acciones correctivas.

33 3.1. APORTES RELACIONADOS 19 Figura 3.1: Matriz de dependencia entre componentes de una arquitectura de capas. Los números indican la intensidad de la dependencia, calculada en función del número de referencias encontradas mediante el análisis estático de clases en cada paquete Java. Richner [34] y Sefika et.al. [38] proveen mayor flexibilidad en ese aspecto, brindándole libertad al usuario para definir tanto la política de clustering para los componentes como las estrategias de análisis para diferentes tipos de relaciones por medio de reglas Prolog [40]. En el caso de Sefika et.al. [38], se utilizan modelos concretos como prácticas recomendadas de codificación o diagramas de flujo de control, modelos arquitectónicos expresados como patrones de diseño y modelos heurísticos como cohesión alta y bajo acoplamiento. La herramienta propuesta analiza, por ejemplo, una implementación respecto al estilo arquitectónico o al patrón de diseño señalado por el usuario; pero no es capaz de descubrir tales estilos o patrones. Se supone que el arquitecto conoce claramente los patrones que aplicó durante el diseño y es por ello que ahora podría necesitar contrastar su trabajo con la implementación. Este primer análisis es de carácter estático, sobre código C++ y de manera similar al trabajo anterior, detecta relaciones entre distintas clases. Sin embargo, en este caso las dependencias son comparadas respecto a las que deberían existir según los roles que cada clase toma dentro de un patrón de diseño específico. Tales dependencias son modeladas mediante una serie de reglas Prolog. Guiado por los resultados del análisis estático, la herramienta permite instrumentar la aplicación aunque solamente dentro de un framework desarrollado especialmente, llamado µchoices, con el propósito de visualizar la conformidad con las mismas restricciones estructurales en tiempo de ejecución, otorgando por ende, un relativo control dinámico de la aplicación. Como desventajas podemos señalar la necesidad de indicar explícitamente los patrones de diseño aplicados, la dificultad impuesta para agregar nuevas reglas de análisis en lenguaje Prolog, la incapacidad de trabajar con niveles altos de abstracción y el limitado aprovechamiento en el análisis dinámico. Respecto a esta última observación, el chequeo en tiempo de ejecución es contrastado exclusivamente con aspectos estructurales de la arquitectura. No se analiza el comportamiento de la arquitectura ante diferentes escenarios funcionales pues éstos nunca son especificados por el arquitecto. La herramienta tampoco ofrece la opción de sincronizar las posibles diferencias encontradas, es decir, no se modifica en consecuencia ninguno de los dos modelos: ni la arquitectura (estructura), ni el código fuente. El enfoque tampoco soporta integralmente el concepto de componente arquitectónico, sino que se centra en las clases C++ y en las relaciones existentes entre ellas. Otros enfoques de recuperación de arquitecturas tales como [8, 18, 25] intentan extraer la arquitectura del sistema directamente desde su código fuente. Quizás el en-

34 20 CAPÍTULO 3. TRABAJOS RELACIONADOS foque más completo es el discutido por Medvidovic et.al.[25], donde las actividades de extracción no solo se basan en el código fuente sino que además son complementadas con requerimientos y estilos arquitectónicos. Más recientemente, Yan et.al. [44] han desarrollado una herramienta llamada DiscoTect que mapea eventos de bajo nivel del sistema a operaciones arquitectónicas abstractas; interpretadas luego por un motor especial que finalmente construye la estructura arquitectónica del sistema en tiempo de ejecución como una descripción ACME [21]. La idea principal de este trabajo es traducir estilos de implementación a estilos arquitectónicos. La traducción se define conceptualmente como una red de Petri coloreada [22], empleada durante la ejecución para interpretar los eventos de bajo nivel y traducirlos cuando corresponda a eventos arquitectónicos, como por ejemplo: creación de componentes, establecimiento de conexiones entre ellos, etc. Los eventos de bajo nivel son instrucciones Java ejecutadas sobre una máquina virtual y se obtienen instrumentando el programa mediante AspectJ [23]. La arquitectura de DiscoTect puede observarse en la Figura 3.2. La red de Petri coloreada se obtiene como resultado de la compilación de una especificación escrita en un lenguaje especial llamado DiscoStep. DiscoStep fue diseñado para permitir traducir la ejecución de instrucciones Java a eventos arquitectónicamente significativos, considerando que la aridad de esta relación entre ambos tipos es n-m y que normalmente los eventos de alto nivel pueden ocurrir simultáneamente cuando el sistema bajo análisis posee varios procesos o hilos de ejecución concurrentes. Para que esta especificación DiscoStep sea efectiva, el programador debe seguir estrictamente los estilos de implementación que permitirán construir correctamente la red de Petri coloreada. Por ejemplo, si el sistema respeta el estilo arquitectónico cliente-servidor [13], el programador deberá codificar las clases Java significativas para este estilo como cliente, servidor y conexión cliente-servidor con alguna convención que ayude a la red de Petri a detectar estos eventos. Si la especificación DiscoStep espera que el servidor sea representado por un socket TCP con el sufijo ServerSocket, el programador deberá seguir este estándar para que el mecanismo sea efectivo. Los autores de esta herramienta aseguran bajo la condición de que las implementaciones respeten siempre los mismos estilos, que DiscoTect puede monitorear diferentes sistemas sin que sea necesario modificar la especificación del mapeo entre eventos de bajo nivel y eventos de alto nivel, es decir, el código DiscoStep. Aunque este enfoque es interesante para visualizar la evolución de una arquitectura durante la ejecución de su implementación, es importante hacer notar que esta evolución se representa en términos estructurales de la arquitectura, en otras palabras, como los componentes y sus conectores se reconfiguran entre si de acuerdo a las distintas situaciones que pueden ocurrir en el sistema. Los autores de DiscoTect han reportado dos casos de estudio de sistemas legados, en los que recuperaron tanto un estilo pipe-and-filter como uno cliente-servidor. La herramienta todavía necesita ser evaluada con estilos arquitectónicos más complejos, donde los mapeos a código no son necesariamente directos. Lamentablemente, al igual que en los trabajos anteriores, la herramienta no persigue como objetivo principal la sincronización de los modelos arquitectura - implementación, sino descubrir y alertar posibles inconsistencias; por consiguiente, esta labor debe ser realizada manualmente por el desarrollador. Además, ninguno de estos enfoques han considerado las extracciones de paths de funcionalidad, tales como los UCMs. Focus [26] es el fruto de un enfoque también basado en ingeniería reversa. Su objetivo último es extraer una descripción estructural de la arquitectura en función de la información provista por su implementación y el desarrollador. El código fuente de una aplicación es analizado estáticamente para obtener un diagrama de clases UML

35 3.1. APORTES RELACIONADOS 21 Figura 3.2: Arquitectura de la herramienta DiscoTect y luego las clases interrelacionadas son agrupadas en componentes. Este enfoque mantiene los mapeos entre arquitectura e implementación durante la evolución aplicando el proceso de descubrimiento incrementalmente sobre las porciones de código fuente modificadas. Los mapeos definen a los componentes como un grupo de clases relacionadas. El proceso de clustering para determinar los componentes utiliza diferentes políticas, principalmente basadas en las relaciones de dependencia entre clases Java. Los casos de uso son especificados por el arquitecto y luego chequeados parcialmente en base a la inspección de código fuente. La Figura 3.3 ilustra las principales actividades ordenadas parcialmente realizadas por Focus para recuperar una arquitectura. El enfoque es interesante para propagar cambios desde la implementación hacia la arquitectura. La virtud principal, radica en refinar progresivamente la vista arquitectónica en función de los cambios sucesivos del código, en lugar de intentar recuperarla íntegramente con un único análisis exhaustivo. Como contras, se puede mencionar la escasa automatización (las abstracciones deben ser realizadas por el usuario, por ejemplo) y nuevamente, la falta de soporte para aspectos comportamentales de la arquitectura como es el caso de las representaciones UCM. Un enfoque que aborda la especificación UCM y emplea mecanismos de ingeniería reversa es el propuesto por Amyot et. al. [5] bajo el nombre de KLOCwork s Architecture Excavation method (KAE). Aunque el trabajo no tiene como objetivo directo la sincronización de una vista arquitectónica con su correspondiente implementación, algunas de sus características lo acercan hacia este grupo de herramientas. KAE, extrae escenarios UCM a partir del análisis estático de código C++. Su finalidad es ayudar al nuevo desarrollador a comprender la arquitectura escondida detrás de una implementación preexistente. KAE utiliza una técnica híbrida basada en entrevistas (interviews) y etiquetado (tagging). Las entrevistas permiten obtener escenarios iniciales en base a charlas con desarrolladores involucrados y también mediante la inspección del código, por esta razón, esta técnica es completamente manual. El etiquetado, también de carácter manual, es un proceso donde el desarrollador asocia etiquetas semánticas a diferentes porciones del código fuente; mas tarde estas etiquetas representarán responsabilidades de distintos componentes de la arquitectura. KAE aproxima los casos de uso iniciales, en forma de trayectorias a través de las diferentes etiquetas colocadas en el código fuente. La herramienta ofrece un compilador para generar un modelo estructural rudimentario de la arquitectura. Este modelo será transformado iterativamente para incrementar el nivel de abstracción y para eliminar cualquier dependencia íntercomponente accidental. La estructura estática de la arquitectura es representada por medio de diagramas

36 22 CAPÍTULO 3. TRABAJOS RELACIONADOS Figura 3.3: Actividades principales del proceso de recuperación de arquitecturas de Focus de paquete UML: los paquetes simbolizan componentes y las dependencias entre ellos, sus conexiones. Las conexiones entre componentes se detectan analizando las dependencias entre clases C++ pertenecientes a diferentes paquetes. La abstracción subsiguiente del modelo queda a cargo del usuario, quien tiene a su disposición para este propósito, dos operaciones: agregación y ajuste. La agregación permite seleccionar distintos bloques y agruparlos creando un nuevo nivel en la jerarquía. El ajuste es otra operación visual donde se mueven bloques para eliminar dependencias entre paquetes de niveles mas altos que fueron introducidos por emplazamientos accidentales de funcionalidad a nivel de archivo. Como las etiquetas se aplicaron antes al código fuente y éste ya ha sido abstraído en componentes, la herramienta ahora es capaz de generar Use Case Maps como trayectorias a través de las distintas etiquetas colocadas en distintos puntos dentro de los paquetes (que ahora son vistos como componentes). Aunque éste es uno de los pocos enfoques que trabaja con las especificaciones UCM, se realizan demasiadas tareas manuales y otras tantas aplicando simplificaciones gruesas, que introducen errores extra, como es el caso de suponer que existe una división de componentes que coincide perfectamente con la estructura jerárquica de paquetes del proyecto, o crear trayectorias UCM en base al análisis estático del código, cuando en realidad la especificación es inherentemente comportamental. Además, es el usuario quien determina en todo momento cuáles son las responsabilidades y las trayectorias de los distintos escenarios, limitando considerablemente la extracción de información Estrategias basadas en ADLs Entre las soluciones a la erosión arquitectónica basadas en lenguajes de descripción arquitectónicos, podemos mencionar el de Abi-Antoun et.al. [2], donde una especificación arquitectónica en el ADL ACME [21] es mantenida en sincronía con una contraparte implementada en ArchJava [3], aprovechando el hecho de que tanto en ACME como en ArchJava los componentes y conectores son entidades de primera

37 3.1. APORTES RELACIONADOS 23 Figura 3.4: Comparación de estructuras jerárquicas de componentes ACME (arquitectura) y ArchJava (implementación) clase. Ambas vistas la especificación arquitectónica y la implementación son transformadas en instancias de una estructura de árbol en común, que es luego comparada para detectar cambios tales como inserciones, modificaciones y eliminaciones de nodos, como puede apreciarse en la Figura 3.4. Una de las principales ventajas mencionadas por sus autores es no solo la posibilidad de propagar los cambios desde la implementación ArchJava hacia la descripción ACME, sino también al revés, aunque en este caso, el script que concilia las diferencias solo es capaz de generar un esqueleto ArchJava. Los scripts de edición que la herramienta produce para sincronizar ambas vistas deben ser complementados manualmente por el arquitecto pues existen diferencias entre la representación componente-conector (C&C) de cada modelo, como por ejemplo, tipos arquitectónicos, ausentes en ArchJava. Desafortunadamente, esta sincronización no aborda el dinamismo arquitectónico ni la correspondencia de comportamiento entre la arquitectura y la implementación. Además, debe tenerse en cuenta que si bien ArchJava es similar a Java, no es estrictamente un lenguaje de programación orientado a objetos ni mucho menos, un lenguaje empleado corrientemente por los equipos de desarrollo, dificultando así la aplicabilidad en la industria. Un trabajo pasado de Medvidovic et. al. [27] describe un ambiente basado en componentes llamado DRADEL focalizado en el estilo C2 [24] que permite modelado, análisis y evolución de arquitecturas basándose en un ADL que fue específicamente diseñado para estas tareas (C2SADEL). La contribución principal del trabajo es permitir la evolución de componentes empleando subtipado heterogéneo, soportado por C2SADEL, la separación de funcionalidad provista y requerida por medio de una especificación formal, análisis de consistencia de una arquitectura, generación de esqueletos para la implementación de la arquitectura en base a su especificación y la flexibilidad para soportar otros ADLs y otros estilos arquitectónicos. A pesar de estos aportes, el trabajo no pretende sincronizar una implementación preexistente con su arquitectura sino garantizar la correctitud de la especificación, facilitar su evolución y definir las estructuras básicas para guiar a los programadores hacia una imple-

38 24 CAPÍTULO 3. TRABAJOS RELACIONADOS mentación en conformidad con la arquitectura. Claramente, el enfoque es top-down, útil cuando todos los cambios se aplican por primera vez sobre la arquitectura y a su vez, cuando la complejidad del sistema amerita el empleo de un lenguaje de especificación mas rico semánticamente y por lo tanto, mas formal. Desafortunadamente, el escenario más común sucede de manera contraria: se dedican mas esfuerzos a la implementación, y la documentación suele ser pobre y desactualizada. Tampoco es clara la capacidad de la herramienta para propagar cambios hacia la implementación cuando ésta ya existe Estrategias basadas en SCM Aunque esta familia de técnicas es relativamente nueva, entre los enfoques o- rientados a SCM (Software Configuration Management) podemos encontrar algunos trabajos como ArchEvol [30], MAE [35], y MolhadoArch [29] entre otros, que proveen una herramienta de soporte para el versionado de las relaciones entre arquitectura e implementación a lo largo del diseño, implementación y deployment. En el caso de ArchEvol, la herramienta presentada por Nistor et.al. [30]; se integran en el entorno de desarrollo Eclipse [17] un módulo de versionado de proyectos (Subversion [33]) y un módulo de desarrollo guiado por arquitectura basado en C2 (ArchStudio [41]). El esquema de ArchEvol puede verse en la Figura 3.5. El punto central consiste en tomar las ventajas ofrecidas por las herramientas de versionado y trabajo concurrente sobre archivos, para hacer sistemático el proceso de introducción de cambios en un sistema. ArchEvol propone un mecanismo donde la única forma de introducir un cambio (en la arquitectura o en la implementación) es obteniendo la versión del componente arquitectónico que se desea modificar, lo que a su vez impone al desarrollador la necesidad de adquirir la versión de la implementación asociada para finalmente colocar bajo administración de configuración los elementos modificados. La solución en este caso aborda el problema de mantener varias versiones paralelas de especificaciones arquitectónicas consistentes en relación con su implementación. De esta forma se permite la evolución de la relación entre los componentes de la arquitectura y el código fuente, lo que comúnmente se conoce como mapeo, pero es el desarrollador quien debe actualizar manualmente ambas especificaciones. Un escenario de ejemplo ha sido representado en la Figura 3.6. La herramienta no es capaz, por ejemplo, de descubrir que la modificación de un componente de la arquitectura afecta a un subconjunto particular de las clases Java involucradas en el mapeo, sino que lo asiste colocando automáticamente en su espacio de trabajo los elementos de la implementación que potencialmente deberían modificarse para ser coherentes con los cambios en el componente arquitectónico en cuestión. Las excelentes características de soporte y agregado de plug-ins de Eclipse, entorno donde funciona ArchEvol, permiten que la herramienta cuente con la colaboración de componentes populares como son Subversion y ArchStudio, y presentan un escenario favorable para el desarrollador respecto a otros enfoques, evitando que éste deba migrar a un entorno desconocido, experimental y con escaso soporte ante la intención de aprovechar las ventajas específicas de sincronización. En el caso de MAE [35], el enfoque es interesante desde el punto de vista de SCM para versionar arquitecturas de software teniendo en cuenta sus particularidades, pero no soporta integralmente la evolución de la implementación ni el mapeo de arquitectura a código fuente. MolhadoArch [29] posee características similares a las de ArchEvol. Ofrece capacidades de versionado tanto para la arquitectura como para los componentes individuales de ésta. Su mapeo arquitectura - implementación comparte algunas características de ArchEvol pero es específico del entorno Molhado. La información arqui-

39 3.1. APORTES RELACIONADOS 25 Figura 3.5: Componentes principales del sistema ArchEvol Figura 3.6: Ejemplo de un escenario de actualización arquitectura-implementación asistido por ArchEvol

40 26 CAPÍTULO 3. TRABAJOS RELACIONADOS tectónica puede importarse desde un archivo xadl, pero al realizarse, ésta pasa a convertirse al formato interno de representación de Molhado, impidiendo que a partir de ese momento la arquitectura pueda editarse desde otras aplicaciones Resumen de características principales En la sección 3.1 se analizaron individualmente las propuestas de los diferentes enfoques existentes para resolver en mayor o menor grado el problema de la erosión arquitectónica. Buscando ofrecer una mayor claridad al análisis de alternativas vinculadas con el desarrollo de nuestro trabajo, se resumirán las características mas sobresalientes de cada aporte y las desventajas detrás de cada uno. Para tal propósito, el cuadro 3.1 presenta dichos aspectos, los que serán explicados y discutidos mas adelante. Las propiedades de cada enfoque resumidas en esta sección son las siguientes: Tipo: se refiere a la naturaleza del enfoque a grandes rasgos, como fueron presentados en la sección 3.1: basados en ingeniería reversa, en ADLs o en SCM. Análisis de la implementación: se refiere al tipo de análisis (si existe) que se realiza sobre la implementación del sistema. Este puede ser estático, cuando se inspecciona (de manera automática o manual) el código fuente correspondiente, o bien dinámico, en el caso donde la aplicación es observada durante su ejecución empleando algún mecanismo de instrumentación. Lenguaje de implementación: se refiere al lenguaje de programación en el que se espera que esté codificado el sistema analizado por la herramienta. Lenguaje arquitectónico: se refiere al lenguaje de descripción de la arquitectura con el que trabaja la herramienta. Entorno: se refiere al ambiente especial necesario para el funcionamiento de la herramienta en cuestión, sin considerar compiladores o máquinas virtuales requeridos por el lenguaje de implementación. Este atributo es de interés a la hora de evaluar la practicidad de la herramienta en situaciones normales de desarrollo. Aridad del mapeo entre arquitectura e implementación: se refiere a la aridad que existe entre un componente de la arquitectura considerada y un elemento de la implementación. Normalmente los elementos de la implementación suelen ser clases de objetos. Este atributo es importante en ciertos casos para analizar las simplificaciones impuestas por el enfoque en cuestión. Estrategia de análisis: da un breve resumen de las técnicas empleadas para detectar diferencias entre arquitectura e implementación. Aspecto a sincronizar: aspecto principal de la arquitectura considerada en el contexto de la erosión arquitectónica. El aspecto considerado con mayor frecuencia, como se notará, es el estructural. Dirección de los cambios: describe la habilidad del enfoque para propagar la información desde un nivel de especificación hacia otro para buscar la consistencia. Los niveles de especificación considerados son el arquitectónico y el de implementación.

41 3.2. RESUMEN DE CARACTERÍSTICAS PRINCIPALES 27 Análisis implementación Nombre Tipo Leng. Entorno arquitectónico Aridad mapeo Estrategia análisis arq.-impl. Aspecto a sincronizar Dirección Especif. mapeo cambios ingeniería LSM[36] estático Java DSM Indep. 1 - n Violación dependencias Estructura - Matriz DSM No reversa Sefika et. al.[38] ingeniería reversa estático y C++ Class diag. µchoices 1-1 dinámico Modelos concretos, patrones, estilos Estructura - arquitectónicos, heurísticos Debe conocerla el No arquitecto Discotect [44] ingeniería dinámico Java Acme Indep. n - m reversa Traducción eventos implementación - eventos arquitectónicos Estructura dinámica (en - DiscoStep No tiempo de ejecución) ingeniería KAE [5] estático C++ UCM Indep. 1 - n reversa Etiquetado, agregación, ajuste Escenarios funcionales arquitectónicos código - Etiquetado No arquitectura Abi-Antoun ADL estático ArchJava Acme Indep. 1-1 et. al. [2] Comparación jerarquía Estructura bidireccional ArchJava Si componentes DRADEL ADL - Java C2SADEL Indep. 1-1 [27] Anaĺısis C2 basado en Estructura Teoría de Tipos Arquitectura C2SADEL No hacia código Eclipse, ArchEvol [30] SCM - Java C2 ArchStudio, 1 - m - Estructura bidireccional Subversion Component No Projects ingeniería Focus [26] estático Java UML Indep. 1 - m reversa Clustering clases, análisis incremental Estructura asistido por el usuario Código hacia arquitectura Leng. implementación Sincronizacion automática Clustering semiautomático Si Cuadro 3.1: Características principales de los distintos enfoques

42 28 CAPÍTULO 3. TRABAJOS RELACIONADOS Especificación del mapeo: indica cuál es el recurso que emplea la herramienta para relacionar elementos de una arquitectura con su correspondiente implementación. Sincronización automática: indica si la herramienta posee características de automatización (completa o parcial) para propagar las diferencias de un modelo hacia el otro. Como observaciones de esta comparación de características, puede remarcarse el predominio de enfoques que deciden tomar a Java como lenguaje para la implementación que se pretende comparar con la arquitectura. De los dos trabajos que optan por tomar C++ como lenguaje de programación, el de Sefika et. al. [38] utiliza un entorno de propósito especial para permitir la instrumentación, mientras que KAE [5] no ofrece análisis dinámico; necesario para extraer use case maps. La tercer herramienta no 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 extensión de Java con la capacidad de representar entidades arquitectónicas. Esta característica común, es decir, el lenguaje de implementación bajo análisis, puede sugerir la conveniencia de optar Java por sus características conocidas de portabilidad y a su vez, el enorme soporte de la comunidad de desarrolladores y la disponibilidad de herramientas de múltiples propósitos escritos para trabajar con este lenguaje, como es el caso del entorno Eclipse. Solo dos trabajos han decidido encaminar el análisis de la implementación en tiempo de ejecución, en otras palabras, instrumentando la aplicación. Sin embargo DiscoTect explota mejor la información que puede extraerse como consecuencia y es capaz de traducirlo a eventos arquitectónicos, algo que seguramente resultará crucial para el enfoque ArchSync. Notar, en relación a la observación anterior, que para esta herramienta se opta por utilizar Java en la implementación a causa del creciente número de frameworks que soportan la instrumentación de aplicaciones escritas en este lenguaje. Los lenguajes de especificación arquitectónica mas utilizados han sido ACME y C2, probablemente por ser muy difundidos, poseer las características principales de un ADL y a su vez, no resultar excesivamente complejos como consecuencia de su formalidad, en especial ACME. Respecto al aspecto a sincronizar, se nota una escasa cantidad de trabajos dedicados al aspecto comportamental de una arquitectura de software. De ellos podemos destacar solo dos: DiscoTect [44] y KAE [5]. Aún así, DiscoTect lo hace parcialmente, pues su objetivo continúa siendo la estructura de la arquitectura, excepto que en este caso el interés está puesto en la evolución a través del tiempo, a medida que la aplicación se ejecuta. En el caso de KAE se aborda la especificación UCM, pero se hace por medio de un análisis estático del código y con una dominante intervención del usuario. La dirección de propagación de cambios entre modelos de arquitectura e implementación, en los casos donde la herramienta la soporta, tiende a ser del código hacia el nivel arquitectónico cuando la estrategia es la ingeniería reversa mientras que los orientados a los ADL normalmente lo hacen al revés, excepto el caso de Abi-Antoun et. al., donde es posible hacerlo en ambas direcciones. Cabe notar que esta familia de trabajos posee una capacidad limitada para sincronizar, en el sentido de crear o modificar una implementación; en realidad la sincronización es manual pero se obtiene información para guiar al desarrollador que debería hacerla, o bien se generan esqueletos incompletos de la implementación para que el programador pueda realizar su trabajo minimizando los riesgos de violar restricciones estructurales arqui-

43 3.3. CONCLUSIONES 29 tectónicas. En el caso de ArchEvol, orientado al SCM, la dirección de los cambios es bidireccional pero es el arquitecto quien debe analizar qué elementos del subconjunto sugerido deben modificarse. ArchEvol no sincroniza, sino que brinda la infraestructura y asiste al desarrollador en la tarea. También es notable la escasa capacidad de sincronización automática o semi automática ofrecida por las distintas herramientas. Solo dos se encuentran en condiciones de hacerlo: el enfoque de Abi-Antoun et. al. y Focus. El primero basado en ArchJava y el segundo en Java; ambos dedicados al aspecto estructural de la arquitectura Conclusiones En este capítulo se han presentado los trabajos relacionados mas importantes que tratan la minimización de la erosión arquitectónica como objetivo principal. En especial se han discernido tres grandes grupos de soluciones, aquellas que recurren a la ingeniería reversa para reconstruir la arquitectura subyacente, los que sujetan la implementación a las restricciones impuestas por las especificaciones arquitectónicas escritas en algún ADL y finalmente aquellas que aprovechan las herramientas de SCM como vía para controlar las modificaciones en uno u otro modelo (el arquitectónico y el de implementación). Se ofreció una breve referencia a los trabajos mas importantes, con sus características principales, ventajas y desventajas con respecto a la motivación principal del trabajo, enunciada en la sección 1.1. Finalmente se compararon los atributos clave de cada enfoque de forma conjunta para obtener las conclusiones que guiarán al análisis del enfoque ArchSync, presentado a continuación, en el capítulo 4.

44 30 CAPÍTULO 3. TRABAJOS RELACIONADOS

45 Capítulo 4 El enfoque ArchSync En este capítulo se presenta el enfoque ArchSync, que propone la creación de una herramienta de soporte para la actualización semiautomática de UCMs, usando para ello información de versionado de archivos de código fuente, junto con mapeos entre regiones de código y elementos arquitectónicos. El resto del capítulo se encuentra organizado de la siguiente forma. En la sección 4.1 se presenta un breve análisis del problema y de los trabajos relacionados que dieron origen al conjunto de requerimientos para la creación de ArchSync. Luego, la sección 4.3 presenta el modelo conceptual de ArchSync, junto con una breve descripción de cada uno de los elementos que interactúan para alcanzar la funcionalidad propuesta. A continuación, en la sección 4.4 se muestra un ejemplo concreto de funcionamiento de ArchSync. Finalmente, en la sección 4.5 se presentan las conclusiones del capítulo Análisis El objetivo principal de ArchSync es encontrar diferencias entre una descripción realizada en UCM y su correspondiente código fuente dado como entrada, generando como salida una nueva versión del UCM donde esas diferencias han sido resueltas. Como bien se detalló en el capítulo anterior, existen actualmente varios enfoques para tratar el problema de erosión arquitectónica. Si bien no se centran específicamente en documentación de comportamiento, su análisis detallado de cada uno nos permitió detectar tanto características no deseables, como también mecanismos y abstracciones aplicables al caso específico de UCMs. El análisis del problema en sí y de los trabajos relacionados puso a la luz algunas características que hacen difícil la incorporación de ciertos mecanismos dentro de un proceso de desarrollo de software. Para evitar estos inconvenientes, además de la actualización de UCM se plantearon los siguientes objetivos secundarios: Limitar la información requerida del usuario a UCMs, código fuente y mapeo responsabilidad-código. Toda información adicional deberá ser derivable a partir del análisis automático de estos tres elementos dados como entrada. El uso de la herramienta no deberá imponer el uso de un lenguaje de programación de propósito específico, ni un estilo o un conjunto de convenciones de implementación en particular. De esta forma será posible la aplicación del enfoque a sistemas legados. Tampoco se deberá imponer un proceso demasiado estricto para la modificación tanto de la arquitectura como del código. Así, el desarrollador tendrá el control 31

46 32 CAPÍTULO 4. EL ENFOQUE ARCHSYNC de cuándo y cómo sincronizar los UCMs con la implementación. Como principales influencias para la concepción de ArchSync se deben mencionar los trabajos de Yan et.al. [44], Abi-Antoun et.al. [2] y Nistor et.al. [30]. Si bien los objetivos del enfoque son distintos, el análisis de eventos de bajo nivel mediante instrumentación de código presentado en [44] fue un importante ejemplo de (a) cuánta información útil se puede extraer de la ejecución de una aplicación y (b) que la aplicación del enfoque no necesariamente debe requerir el uso de un lenguaje de programación para ese propósito específico. Por otro lado, en [2] se plantea un modelo de actualización incremental en el que se supone un diseño arquitectónico y una implementación inicial. Éste enfoque, en contraste con la extracción completa de un nuevo modelo arquitectónico a partir del código, posee la ventaja de mantener el estilo de especificación del arquitecto, ya que modifica la especificación original solamente en las partes donde se producen divergencias con la implementación. Finalmente, el trabajo presentado en [30] ilustra las ventajas de integrar un enfoque para el tratamiento de erosión arquitectónica con sistemas de software configuration management Ejemplo: MVC Como se mencionó antes, una de las decisiones principales del enfoque ArchSync ha sido centrarse en las vistas comportamentales de una arquitectura, en particular, especificadas como UCMs. Para ayudar a comprender el enfoque en general que se explica en este capítulo, volvemos al ejemplo de la Sección 2.3.2, basado en una arquitectura que respeta el estilo definido en el Graphical Editing Framework (GEF) 1 de Eclipse, un patrón derivado del Model-View-Controller (MVC) [13]. El patrón MVC se aplica en el contexto de aplicaciones interactivas que demandan un alto grado de interacción con el usuario. Estos sistemas normalmente requieren un alto grado de flexibilidad, en especial sobre la interfaz de usuario, que debe adaptarse a las necesidades, muchas veces conflictivas, de los diferentes usuarios. En particular, MVC apunta a satisfacer las siguientes necesidades: La misma información debe ser presentada de manera diferente La representación gráfica y el comportamiento de la aplicación debe reflejar la manipulación de datos inmediatamente Cambios en la interfaz de usuario deben ser fáciles de introducir, incluso, en tiempo de ejecución El núcleo de la aplicación (modelo) debe verse inalterado por el cambio de estilos o interfaces gráficas 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 responsable de administrar las entradas del usuario, realizando cambios en el modelo cuando corresponda y refrescando a la vista. En muchas implementaciones, las interfaces de los modelos son diseñados específicamente para la vista. Cuando la vista se dibuja, se comunica fuertemente con el modelo. Esto permite muchas optimizaciones, pero hace difícil el uso del par vista-modelo para situaciones que escapen al predefinido 1 Eclipse GEF Project page:

47 4.2. EJEMPLO: MVC 33 Figura 4.1: Diagrama de componentes para el ejemplo Model-View-Controller de GEF por el diseñador. Normalmente, el cliente de tales interfaces gráficas siempre tiene que 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. Esto significa que casi cualquier vista puede ser empleada para mostrar casi cualquier modelo. No existe la necesidad de adaptar el modelo para que sea compatible con otra interfaz gráfica. Aquí el mapeo vista-modelo puede no ser 1 a 1. En la Figura 4.1 se presenta un diagrama con los tres componentes principales de este patrón arquitectónico, detallando en cada uno de ellos las responsabilidades asociadas: Modelo Representa los datos y la funcionalidad principal de la aplicación. Provee un mecanismo de registración para los controladores. De este modo, permite la notificación de los cambios sufridos manteniendo la independencia del modelo con sus diferentes vistas. Vista Provee información al usuario de manera visual y obtiene información del usuario mediante eventos (por ejemplo, clicks o movimientos de mouse, teclas, etc.). Obtiene sus datos del modelo. Cada vista posee un controlador. Una vista puede ser una composición de varios elementos visuales y es trabajo del controlador construirlos y coordinarlos. Controlador Traduce los eventos recibidos por la vista en operaciones sobre el modelo o la vista. Recibe notificaciones de cambio del modelo y es el encargado de actualizar las vistas. En la Figura 4.2 se vuelve a introducir el escenario en forma de UCM. Se puede observar cómo esta notación complementa a la vista estructural de componentes, ya que documenta sus roles e interacciones para cumplir con un caso de uso en particular. Mapeo UCM - implementación Antes de proseguir con el ejemplo MVC es importante introducir el concepto de mapeo entre la documentación arquitectónica y su correspondiente implementación. Como se explicó en la sección 2.3.2, el comportamiento especificado a nivel arquitectónico toma distancia de los detalles de interacción como las llamadas o mensajes entre componentes. En el lenguaje UCM, el comportamiento se representa en términos secuencias causa-efecto entre responsabilidades de los componentes. Las responsabilidades pueden ser de mayor granularidad que las llamadas y mensajes para reducir el nivel de compromiso con los detalles, por este motivo, una responsabilidad (función de la que es responsable un componente) puede ser materializada por varios métodos e incluso clases de objeto a nivel implementación. Por otro lado, una misma clase o un método particular de ésta puede contribuir con la materialización de diferentes responsabilidades.

48 34 CAPÍTULO 4. EL ENFOQUE ARCHSYNC 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 de comportamiento a nivel arquitectónico, como lo es una responsabilidad UCM, y una unidad de comportamiento a nivel implementación, como lo son los métodos de una clase. Tal relación se denomina mapeo responsabilidad - código y es información que debe proveer casi siempre el desarrollador a medida que implementa los componentes. El mapeo permite la trazabilidad entre la responsabilidad UCM de un componente y su implementación. ArchSync depende en gran medida de esta información para realizar las distintas operaciones que se describirán oportunamente en este capítulo. En la Figura 4.3 y la Figura 4.4 se muestra la correspondencia de la documentación arquitectónica del caso de referencia y su implementación en Java mediante tales mapeos. Si bien en este ejemplo las correspondencias clase-componente y métodoresponsabilidad son directas, es posible especificar casos más complejos. Figura 4.4: Mapeos método - responsabilidad

49 4.3. MODELO CONCEPTUAL 35 Continuando con el ejemplo de la arquitectura MVC, supondremos que en una etapa posterior del desarrollo (por ejemplo, durante el mantenimiento), llega un nuevo requerimiento, y ahora todas las operaciones efectuadas sobre el modelo deben ser mostradas en un panel de historial de modificaciones. Ahora consideremos que un desarrollador que no está al tanto del diseño arquitectónico es asignado al requerimiento, y que inadvertidamente implementa una llamada al panel directamente dentro del modelo de usuario. El Algoritmo 1 ilustra una posible implementación del requerimiento. En vez de hacer uso del mecanismo de notificación del modelo, se introduce una dependencia en el modelo hacia el panel. Claramente, ésto viola las prescripciones impuestas por el estilo MVC al producir un acoplamiento perjudicial entre Model y View. A menos que hayan revisiones de código estrictas, este cambio (y otros similares) podrían pasar desapercibidos por el resto de los desarrolladores. Algoritmo 1 Violación al estilo Model-View-Controller a nivel de código. La divergencia 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 cambio notifymodelobservers(...); }... } 4.3. Modelo conceptual Para lograr la funcionalidad propuesta, ArchSync hace uso de un sistema de control de versiones y un conjunto de logs de ejecución de la aplicación. El sistema de control de versiones provee información acerca de las regiones de código que han sido cambiadas desde la última actualización del UCM, mientras que los logs de ejecución representan las trazas reales de ejecución de la aplicación en su estado actual. En la Figura 4.5 se presenta una vista general de ArchSync. Aquí, el source code se refiere a los cambios en el código, el UCM Φ es la descripción arquitectónica original, y el UCM Φ + es la descripción arquitectónica después de la sincronización, en correspondencia con el estado actual del código fuente. Internamente, ArchSync está equipado con una red de filtros que implementan diferentes tipos de procesamiento. La operación de algunos de estos filtros requiere intervención del usuario. A continuación se da una breve descripción de los filtros y de la información que toman como entrada y producen como salida: Source Code Representa los cambios sufridos por el código fuente desde la última actualización. Al ser una representación abstracta que identifica elementos agregados, modificados y eliminados, es fácilmente adaptable al modelo de código fuente provisto por cualquier entorno de desarrollo con el que se integre el enfoque. A su vez, permite el análisis de varios lenguajes de programación. UCM Φ Representa la versión desactualizada de la especificación UCM, que además contiene mapeos responsabilidad-código. La notación UCM es independiente del lenguaje de programación, y al igual que en source code, la representación

50 36 CAPÍTULO 4. EL ENFOQUE ARCHSYNC Figura 4.5: Vista general de ArchSync utilizada para los mapeos responsabilidad-código es adaptable a varios lenguajes de programación. Diff Mapper Analiza el source code para detectar un conjunto de paths potencialmente modificados. Este filtro cuenta con una interfaz abstracta bien definida: toma un source code y un UCM Φ como entrada y como resultado identifica el conjunto de paths que pueden verse alterados por los cambios en el código. Ésto permite aprovechar todas las características del lenguaje de programación que lleven a un análisis más exhaustivo sin que el enfoque pierda generalidad, ya que el filtro puede ser reemplazado sin afectar al resto de la implementación. Potentially Changed Paths Es el conjunto de paths potencialmente modificados desde la última actualización. Adicionalmente, en este conjunto de paths se mantiene la trazabilidad con los elementos de source code que ocasionaron la identificación de cambios en las responsabilidades. Execution Logger Registra los eventos de bajo nivel que ocurren en la aplicación mientras el usuario la ejercita con los casos de uso correspondientes a los paths identificados. Execution Logs Son registros de las trazas reales de ejecución de la aplicación en su estado actual. Contienen información de bajo nivel, como llamadas a métodos, threads, creaciones de objetos, etc. Log Analyzer Transforma la información de bajo nivel contenida en las trazas de ejecución en secuencias de responsabilidades, con ayuda de la información de mapeo responsabilidad-código presente en UCM Φ. Estos últimos tres elementos del enfoque son dependientes del lenguaje de programación de la aplicación analizada. Sin embargo, tanto la entrada de Execution Logger como la salida de Log Analyzer son abstractas. Por lo tanto, reemplazándolos en conjunto se

51 4.3. MODELO CONCEPTUAL 37 findmodifiedcode executeusecase el: ExecutionLogger createexecutionlog dm: DiffMapper mapcodetopaths findmappedresponsibilities la: LogAnalyzer createresponsibilitysequence matchpathwithlog plm: PathLogMatcher createupdatescript selectupdatescript s: Synchronizer applyupdatescript Figura 4.6: UCM representando el comportamiento de ArchSync. puede adaptar el enfoque a cualquier lenguaje de programación que permita instrumentación de código. Responsibility Sequence Representa una secuencia lineal de activación de responsabilidades. Cada activación contiene información de trazabilidad hacia los eventos de bajo nivel originales. Path-Log Matcher Compara las secuencias de activación de responsabilidades con sus correspondientes paths, poniendo en evidencia los puntos donde hay diferencias y proponiendo acciones correctivas. Durante la exploración de alternativas de conciliación, se pueden aplicar reglas heurísticas que aprovechen la información de bajo nivel para descartar algunas opciones. Update Scripts Corresponde a las secuencias de operaciones de transformación atómicas que, aplicadas al path viejo, producen un nuevo UCM que corresponde al estado actual de la implementación. Synchronizer Aplica un update script seleccionado por el usuario sobre el UCM Φ. Use Case Map: UCM Diagram UCM Φ + Representa la nueva versión del UCM que se corresponde con la versión actual del código fuente. Surge de aplicar un update script sobre UCM Φ. La Figura 4.6 resume el funcionamiento de ArchSync mediante un UCM. Como se mencionó previamente, el UCM Φ tiene mapeos a código, pero muchos de los mapeos pueden estar desactualizados en el source code. Basado en esta información de mapeo entre elementos arquitectónicos y regiones de código fuente, el filtro Diff Mapper está a cargo de detectar todos los potenciales paths del UCM que pueden haber sido afectados por los cambios en el código. Dicha detección se realiza en varias etapas. Primero se identifican los archivos que han cambiado desde la última actualización del UCM, para luego comparar la última versión de cada uno de ellos con la versión correspondiente a UCM Φ. Durante esta comparación se analiza el

52 38 CAPÍTULO 4. EL ENFOQUE ARCHSYNC Acción remove(targetnode) insertbetween(node1, node2, newnode) insertafter(targetnode, newnode) transform(targetnode, newtype) Descripción Elimina targetnode del path ellas Inserta newnode después de targetnode en el path Transforma el tipo de targetnode a newtype Cuadro 4.1: Operaciones atómicas de actualización de UCMs código y se identifican los elementos a nivel de implementación (métodos y clases) que han sido eliminados, agregados y/o modificados. A partir de este punto, se utiliza la información de mapeo entre responsabilidades y código para detectar el conjunto de responsabilidades que tienen relación con el código cambiado. Finalmente, todos los paths en los que aparece alguna de las responsabilidades relacionadas con los cambios son marcados como potencialmente cambiados. Una vez que ha sido identificado el conjunto de paths sospechosos, los casos de uso correspondientes a cada uno de ellos son usados como casos de test para ejercitar el sistema y recolectar información acerca de su ejecución. Asumiendo que el código ha sido de alguna forma instrumentado, el filtro Execution Logger construye un conjunto de logs de ejecución, que representan trazas de ejecución del comportamiento real del sistema con respecto a los paths potencialmente cambiados. La instrumentación está a cargo de capturar diversos eventos de bajo nivel, tales como: llamadas a métodos, creaciones de objetos, threads, excepciones, etc. En este punto es imprescindible la intervención manual del usuario ya que es necesario guiar la ejecución de la aplicación, interactuando con ella de manera que se ejercite exactamente el caso de uso correspondiente al path que está siendo analizado. Los mapeos a código de UCM Φ son tomados por el filtro Log Analyzer, que usa esta información para traducir los eventos de bajo nivel en una secuencia lineal de activaciones de responsabilidades. A continuación, el filtro Path-Log Matcher toma cada secuencia de responsabilidades y la compara con su path desactualizado correspondiente. A medida que el filtro realiza las comparaciones, éste expone las diferencias entre el UCM Φ y el source code creando un conjunto de scripts de actualización. Un script de actualización es una secuencia de acciones atómicas que permiten 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 comportamiento del sistema con UCMs. Es por esto que el Path-Log Matcher produce un conjunto de scripts alternativos en vez de una única actualización. Estos scripts son priorizados basándose en la cantidad de cambios sobre el viejo UCM que cada uno aplica, suponiendo que los scripts cortos son mejores que los que tienen mayor número de operaciones 2. Entonces, el desarrollador es libre de seleccionar el script que encuentra más apropiado para el caso específico de diseño arquitectónico. En este punto, el filtro Synchronizer puede aplicar el script de actualización que seleccione el usuario sobre el UCM Φ para producir finalmente el UCM Φ +. De esta manera, los UCMs pueden ser puestos en correspondencia con los cambios en el código fuente. 2 Esta suposición se basa en que, intuitivamente, el resultado de aplicar un script pequeño, al realizar menos cambios sobre el UCM original, va a estar más cerca del estilo de especificación del arquitecto que el de uno más grande.

53 4.3. MODELO CONCEPTUAL Path-Log Matcher Siendo la parte principal del enfoque ArchSync, en esta sección se explica en detalle el funcionamiento del filtro Path-Log Matcher. El filtro toma como entrada un path potencialmente cambiado y una secuencia de activación de responsabilidades (log o traza de nivel arquitectónico). El Algoritmo 2 correlaciona ambas entradas, realizando los cambios necesarios sobre el path desactualizado para que coincida con el log. Cada uno de los cambios realizados sobre el path es registrado en un script de actualización, 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 Ø cursor := seleccionarcursor(cursores) entradalog := log.primero if cursor.responsabilidad / entradalog.responsabilidades accioncorrectiva := seleccionaraccion(path, cursor, entradalog) script := script + accioncorrectiva path := corregirpath(path, accioncorrectiva) cursores := corregircursores(path, cursores, accioncorrectiva) else cursores := avanzarcursor(cursor, cursores) log := eliminarprimero(log) end if end while if cursores Ø script := script + eliminarsiguientes(cursores) end if return script end path-log-match El algoritmo se maneja alrededor de un conjunto de cursores, que marcan hasta qué punto se ha avanzado sobre la correlación y corrección del path desactualizado. Cada cursor apunta a una responsabilidad en el path que aún no ha sido correlacionada con una entrada en el log, e implica que todas las responsabilidades anteriores en la secuencia causal ya han sido correlacionadas o corregidas. El script de actualización comienza vacío, mientras que el conjunto de cursores iniciales tiene un único elemento que apunta a la responsabilidad inicial del path. Luego de la inicialización, se toman las entradas del log una a una. Por cada una de ellas, se selecciona un cursor y se busca la responsabilidad apuntada por él entre las responsabilidades candidatas. Si la responsabilidad no está entre las candidatas, ésto quiere decir que, en la traza real de ejecución de la aplicación, se ha activado una responsabilidad que no está contemplada por el path en su estado actual, y que es necesario tomar una acción correctiva. Las acciones correctivas posibles son: Eliminar responsabilidad Elimina la responsabilidad actual, ya que es posible encontrar la responsabilidad esperada entre las siguientes en el path. Insertar responsabilidad Inserta una de las responsabilidades candidatas entre la responsabilidad indicada por el cursor y la anterior en el path, de esta manera permitiendo la correspondencia inmediata entre el log y el path.

54 40 CAPÍTULO 4. EL ENFOQUE ARCHSYNC Transformar responsabilidad Transforma la responsabilidad anterior a la indicada por el cursor en un and fork e inserta una de las responsabilidades candidatas en una nueva rama del path, también permitiendo correspondencia inmediata. Por otro lado, si la responsabilidad apuntada por el cursor está entre las responsabilidades candidatas, se considera que el path y el log están correlacionados en ese punto y por lo tanto se avanza el cursor y se elimina la entrada actual del log. El procedimiento para avanzar un cursor es diferente según el caso: Responsabilidad simple: el cursor avanza hacia la responsabilidad siguiente en el path. And Fork: el cursor es dividido en tantos cursores como ramas salientes tenga el path en ese punto, que son posicionados en la primera responsabilidad de cada una de ellas. Or Fork: se avanza hacia la primera responsabilidad de solamente una de las ramas salientes del path en ese punto. And Join: cada cursor que llega a un And-Join debe esperar ahí hasta que lleguen los cursores de las demás ramas concurrentes. Una vez que han llegado todos, éstos se fusionan en un sólo cursor que avanza a la siguiente responsabilidad de la rama saliente. Or Join: el cursor avanza normalmente. Si se llega al mismo Or-Join desde varias ramas concurrentes, el path original posee un error semántico y se informa al usuario que debe corregirlo. El algoritmo repite estas operaciones hasta vaciar el log, y finalmente, si los cursores no han llegado al final del path, elimina todas las responsabilidades restantes. En este punto, el script generado es uno que transforma el path dado como entrada en uno que corresponde correctamente a la secuencia de activación de responsabilidades. Es importante destacar que el script generado es solamente uno de los posibles scripts que pueden poner al UCM en correspondencia con la traza de ejecución dada. Para generar exhaustivamente todos los posibles scripts hay que reevaluar el algoritmo tomando diferentes alternativas en los puntos de elección no-determinística que fueron marcados en el algoritmo con cursiva y que se detallan a continuación. seleccionarcursor: Cuando se analizan ramas concurrentes de un path puede haber más de un cursor disponible en el conjunto y por lo tanto más de una opción. En el caso de un And-Join la opción se descarta hasta que los cursores de todas sus ramas hayan llegado. seleccionaracción: En este punto es donde más opciones se presentan. Por un lado, hay que elegir entre alguna de las tres acciones correctivas presentadas anteriormente, mientras que por otro, en los casos en los que hay que insertar una responsabilidad en el path, cualquiera de las responsabilidades candidatas es una opción. avanzarcursor: En el caso de un Or-Fork se debe tomar solamente una de las ramas salientes. El no-determinismo está en cual de ellas tomar. En el capítulo siguiente se explican algunas heurísticas que se aplicaron para evitar la prueba exhaustiva de todas las alternativas, tratando de encontrar primero los scripts más cortos.

55 4.4. RESOLUCIÓN DEL EJEMPLO MVC 41 Figura 4.7: Identificación de responsabilidades afectadas por cambios en el código fuente Figura 4.8: Log de ejecución transformado en una secuencia de activación de responsabilidades 4.4. Resolución del ejemplo MVC Volvamos al caso de referencia de la Sección 4.2 para ver el funcionamiento de ArchSync ante el problema planteado antes. Para tratar con este caso de desactualización de documentación de diseño, ArchSync trabaja como se describe a continuación. Primero, la herramienta es notificada de un cambio en el archivo User.java, que es analizado en detalle para detectar que en realidad la modificación fue sobre el método setname(). Ya que este método 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 implementación actual del sistema, produciendo un log de ejecución. Este log de ejecución es, a su vez, procesado por el filtro Log Analyzer, que genera una secuencia de activación de responsabilidades como la presentada en la Figura 4.8. Los detalles del procesamiento para obtener esta secuencia implican la utilización del mapeo entre elementos de bajo nivel y elementos arquitectónicos, cuya implementación se presenta en el capítulo siguiente. Una vez generada esta secuencia de activación de responsabilidades, el filtro Path-Log Matcher la compara con el UCM desactualizado. A continuación se detallan los pasos de esta comparación. 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, ambos cursores avanzan. 2. Cursor de log = handlewidgetevent, cursor de path = handlewidgetevent (Figura 4.10). Ambos cursores avanzan.

56 42 CAPÍTULO 4. EL ENFOQUE ARCHSYNC Figura 4.9: Path-Log Matcher (paso #1). Ambos cursores coinciden. Figura 4.10: Path-Log Matcher (paso #2). Ambos cursores coinciden. 3. Cursor de log = setproperty, cursor de path = setproperty (Figura 4.11). Ambos cursores avanzan. 4. Cursor de log = addlogentry, cursor de path = notifymodelobservers (Figura 4.12). El algoritmo registra la diferencia, y evalúa alternativas de conciliación secuenciales y paralelas entre el path y el log. Avanza solamente el cursor de log. 5. Cursor de log = notifymodelobservers, cursor de path = notifymodelobservers (Figura 4.13). Ambos cursores avanzan. 6. Cursor de log = handlemodelchangedevent, cursor de path = handlemodelchangedevent (Figura 4.14). Ambos cursores avanzan. 7. Cursor de log = updateview, cursor de path = updateview (Figura 4.15). Finaliza el análisis. Figura 4.11: Path-Log Matcher (paso #3). Ambos cursores coinciden.

57 4.4. RESOLUCIÓN DEL EJEMPLO MVC 43 Figura 4.12: Path-Log Matcher (paso #4). Los cursores no coinciden. Figura 4.13: Path-Log Matcher (paso #5). Ambos cursores coinciden. Figura 4.14: Path-Log Matcher (paso #6). Ambos cursores coinciden. Figura 4.15: Path-Log Matcher (paso #7). Ambos cursores coinciden.

58 44 CAPÍTULO 4. EL ENFOQUE ARCHSYNC Update script A: Update script B: insertbetween(setusername, \\ notifymodelobserver, addlogentry) transform(setproperty, andfork) insertafter(setproperty, addlogentry) Figura 4.16: Alternativas de Actualización del UCM Al finalizar la comparación, Path-Log Matcher sugiere una lista de scripts de actualización. Algunos scripts aplicables al UCM desactualizado se muestran en la Figura El primer script de actualización sugerido está compuesto por una única operación, en este caso insertbetween. Esta instrucción inserta la responsabilidad addlog- Entry entre dos responsabilidades existentes en el path (setusername y notifymodel- Obsevers). El segundo, en cambio, está conformado por dos operaciones: transform e insert- After. La primera transforma la responsabilidad setusername en un nodo de tipo andfork. La última operación inserta la responsabilidad addlogentry después del nodo setproperty, que fue transformado en el paso anterior. El resultado de esta secuencia de operaciones equivale a agregar un nuevo path paralelo al existente en el punto donde se detectó la divergencia. En este punto, se debe destacar que las dos soluciones propuestas por ArchSync corresponden correctamente con la implementación. En general, las variaciones en las soluciones son debidas al hecho de que los UCMs son una notación bastante abstracta, y por lo tanto dan una paleta de opciones para para representar el mismo caso de uso conceptual. Es por esto que, incluso cuando todas las soluciones generadas por Arch- Sync se consideran correctas, el arquitecto es responsable de elegir la solución que es más apropiada para el contexto real de diseño. Otra aclaración relacionada es que las soluciones a menudo sugieren cambios sobre los UCMs que comprometen la integridad del modelo arquitectónico. Por ejemplo, los scripts de actualización mostrados en la Figura 4.16 revelan un estilo de implementación que viola el patrón arquitectónico MVC. En estos casos, el criterio del arquitecto juega de nuevo un rol fundamental. El arquitecto puede elegir entre, por un lado, proceder aplicando la solución propuesta por ArchSync y, por otro, decidir que el requerimiento que originó la inconsistencia debe ser reimplementado de una forma acorde al estilo arquitectónico.

59 4.5. CONCLUSIONES Conclusiones En este capitulo se presentó el enfoque ArchSync, que permite mantener la documentación arquitectónica, representada en forma de UCMs, actualizada a lo largo del desarrollo, evolución y mantenimiento de una aplicación. El enfoque utiliza información de mapeo entre elementos arquitectónicos y regiones de código fuente para traducir los eventos de bajo nivel que aparecen en las trazas de ejecución en activaciones de responsabilidades. Esa información se utiliza para analizar los paths desactualizados, finalmente produciendo una nueva versión del UCM en la que las diferencias con el comportamiento real del sistema en desarrollo han sido eliminadas. ArchSync es integrable con entornos de desarrollo que sean capaces de proveer información de versionado de archivos de código fuente. Su modelo flexible de sincronización permite al desarrollador tener el control de cuándo y cómo actualizar la documentación arquitectónica. Por lo tanto, su utilización facilita la adopción de un proceso de desarrollo centrado en la arquitectura, disminuyendo tiempo y recursos a ser desviados de implementación a documentación. Además ArchSync no impone restricciones de utilización de un lenguaje o convenciones de implementación de propósito específico: el uso del lenguaje de programación Java permite la aplicación del enfoque en muchos sistemas existentes. En el siguiente capítulo se muestran en detalle algunos aspectos de la implementación.

60 46 CAPÍTULO 4. EL ENFOQUE ARCHSYNC

61 Capítulo 5 Diseño e implementación El presente capítulo está dedicado a la descripción del diseño e implementación de ArchSync. Para ello, su estructura y funcionamiento serán descriptos mediante diagramas de paquetes y de descomposición de módulos a nivel arquitectónico y, a nivel de diseño detallado, mediante diagramas de clases y de interacción en notación UML (Unified Modeling Language) [12], presentando los aspectos más importantes de su implementación. El resto del capítulo se encuentra organizado de la siguiente manera. En la sección 5.1 se presenta la arquitectura de ArchSync. Luego, en las secciones 5.2, 5.3, 5.4 y 5.5 se explican en detalle cómo fueron diseñados e implementados los componentes Diff Mapper, Execution Logger, Log Analyzer y Path-Log Matcher, respectivamente. Finalmente, en la sección 5.6 se presentan las conclusiones del capítulo Arquitectura Como ya se explicó en los capítulos anteriores, ArchSync es una herramienta de natural integración con entornos de desarrollo Java con soporte para control de versiones. ArchSync fue implementado como un plug-in de la plataforma Eclipse [17], aprovechando su arquitectura extensible, su funcionalidad expuesta de control de versiones y su modelo para análisis estático de código fuente Java. Además, ésto permitió aprovechar el editor gráfico de UCMs y el instrumentador de bytecode del proyecto FLABot, ya que ambos también fueron implementados como plug-ins [31]. El diseño de ArchSync está muy influenciado por la arquitectura ya definida por Eclipse. Esencialmente, Eclipse (ver Apéndice A.1) es una plataforma diseñada para construir herramientas de desarrollo. Si bien la plataforma por sí misma no provee mucha funcionalidad al usuario final, facilita el rápido desarrollo de herramientas con características integradas. Así, la organización de estas herramientas alrededor de un espacio de trabajo común es un principio de diseño central, tanto para Eclipse como para ArchSync. En el caso particular de este trabajo, es necesario un cierto nivel de integración para aprovechar los componentes existentes de FLABot y la infraestructura básica de Eclipse. Por estas razones, la arquitectura de FLABot ha sido organizada mayormente alrededor de un estilo data-centered (centrado en los datos) [6]. La imposición de este estilo ayuda a soportar los niveles de integración antes mencionados y además permite una evolución casi independiente de las herramientas. La figura 5.1 ilustra el contexto de operación de ArchSync. En la Figura 5.2 se ilustra, mediante un diagrama de paquetes UML, cómo fue organizado ArchSync en diferentes unidades de implementación. Los cuatro paquetes centrales de la figura son los que fueron desarrollados en este trabajo. Además, el diagrama especifica las relaciones de los paquetes propios de ArchSync con los pa- 47

62 48 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN Figura 5.1: Estilo data-centered para ArchSync en Eclipse quetes existentes que fueron reutilizados. El origen del resto de los paquetes se indica mediante estereotipos: < <eclipse> > para la plataforma Eclipse, < <flabot> > para FLABot y < <javalog> > para JavaLog. La funcionalidad propia de ArchSync se encuentra organizada alrededor de un estilo pipes and filters [6], donde los pipes se utilizan para conectar filtros y cada filtro transforma a su salida la información recibida como entrada. El filtro Diff Mapper emplea el metamodelo Java (JDT) y la historia local de Eclipse (Local History) para determinar los paths de la especificación UCM que pueden haberse visto afectados en función de las modificaciones producidas en la implementación del sistema. Los escenarios marcados como sospechosos son tomados como entrada para el filtro Execution Logger, que luego registra los eventos de bajo nivel (llamadas a métodos, creación de objetos, etc.) que ocurren en la aplicación en funcionamiento durante su ejecución. Execution Logger emplea los servicios del Bytecode Instrumentor de FLABot para poder monitorear la ejecución de la aplicación en las regiones que correspondan. Esta información se registra en un log de ejecución, representado por un Trace Model, que luego es tomado como entrada por el siguiente filtro: Log Analyzer. Éste se encarga de traducir las instrucciones ejecutadas por la máquina virtual Java en una secuencia de activación de responsabilidades UCM. Finalmente, el filtro Path-Log Matcher toma como entrada las salidas de los filtros Diff Mapper (paths posiblemente desactualizados) y Log Analyzer (secuencia de responsabilidades), y emplea un intérprete Prolog (Prolog Interpreter) para la ejecución de un algoritmo de comparación entre ambas. Como salida de este filtro se produce un conjunto de scripts de actualización, donde cada uno de ellos representa una alternativa de conciliación entre la especificación UCM desactualizada y el estado actual del código fuente. Todos los componentes dependen de la información de mapeo encontrada en el UCM Model, que representa a la especificación que se intenta sincronizar. En la Figura 4.6 del capítulo anterior se puede ver un UCM que resume la funcionalidad descripta.

63 5.2. DIFF MAPPER 49 Figura 5.2: Diagrama de paquetes de ArchSync 5.2. Diff Mapper En el capítulo 4 se presentó brevemente al componente Diff Mapper como responsable de analizar el source code para detectar un conjunto de paths potencialmente modificados. Diff Mapper debe procesar los cambios recientes producidos por un desarrollador en la implementación, y utilizar esta información para analizar los UCMs existentes en búsqueda de paths funcionales que puedan haber perdido consistencia como consecuencia de tales cambios Source code La entrada principal para Diff Mapper son los cambios que han aparecido como consecuencia del desarrollo en el código fuente; en nuestro caso, proyectos Java. En la implementación inicial de ArchSync se optó por controlar exclusivamente los cambios directos en la implementación del sistema. Esto se debe a que la implementación de ArchSync depende de FLABot y éste, solo permite el mapeo de métodos Java. Las clases compiladas se excluyen también del análisis de Diff Mapper para simplificar su implementación. ArchSync considerará como unidades de cambio, aquellos métodos Java que hayan sido agregados, modificados o eliminados de una implementación. Dicho de otro modo, la diferencia entre una implementación Java en un tiempo t1 y esa misma implementación en un tiempo posterior t2 es el conjunto de métodos que se han agregado, modificado o eliminado del proyecto. Tal modelo de representación de una diferencia entre implementaciones es llamado source code y puede verse reflejado en el diagrama de clase de la Figura 5.3. Diff Mapper tomará como entradas para determinar el source code, el último momento en que se sincronizó la implementación con su representación UCM, y por otro lado, el conjunto de proyectos sobre los que se aplicará la sincronización, es decir, el lugar donde ArchSync deberá buscar métodos agregados, modificados o cambiados. Para construir la representación source code, Diff Mapper realiza el trabajo en dos etapas diferentes (Figura 5.4): primero detecta las clases afectadas por los cambios (interfaz IJavaClassDiffStrategy) y luego las analiza para descubrir los métodos

64 50 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN 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 módulo Local History de Eclipse, que permite recuperar las versiones anteriores de todos los archivos del espacio de trabajo. Analizando la historia del proyecto a partir de la última fecha en que se sincronizó la implementación con su representación UCM es posible descubrir fácilmente qué clases han sido cambiadas, creadas o eliminadas. En vistas de la necesidad de independencia del análisis de código fuente del origen de los datos, se emplea aquí el patrón de diseño Strategy [19]. La independencia de este algoritmo de su interfaz pública permite que futuras implementaciones puedan utilizar otros módulos o recursos, por ejemplo, inspeccionando un repositorio CVS. Durante la segunda fase, las clases descubiertas como modificadas por el algoritmo anterior son procesadas por la implementación correspondiente a la interfaz IJavaSourceDiffStrategy. Su función es detectar cuáles de los métodos que conforman la clase han sido modificados, eliminados o agregados respecto a la última versión sincronizada. En el caso de las clases eliminadas, todos sus métodos son marcados como eliminados; de forma análoga ocurre con las clases agregadas. La implementación actual, también independizada mediante el uso del patrón de diseño Strategy, utiliza la funcionalidad provista por el plug-in de Eclipse JDT, específicamente, se especializa la clase org.eclipse.jdt.core.dom.astvisitor. Esta implementación se realizó sobre la clase ASTMethodDeclarationVisitor, que especializa la clase anterior, basada en el patrón de diseño Visitor [19]. ASTMethodDeclarationVisitor recorre el árbol de parsing de una clase Java permitiendo procesar diferentes algoritmos según el tipo de nodo que se esté visitando. En particular, el interés de esta clase son todos los métodos y constructores del árbol de parsing que está siendo comparado. Por cada método encontrado en una versión del código fuente, se busca su contraparte en la versión posterior y de encontarse, se descubren modificaciones que puedan haberse realizado en su cuerpo IDiffMapper La segunda fase del análisis estático realizado por Diff Mapper es realizada por la implementación correspondiente a la interfaz IDiffMapper (Figura 5.5). La funcionalidad principal es descubrir los paths UCM que han sido potencialmente alterados por el source code construido en la fase previa. La implementación actual inspecciona cada uno de los paths que conforman el UCM y siguiendo su mapeo al código fuente, detecta si alguno de los métodos que materializan las responsabilidades es afectado directa o indirectamente por el source code. Para ser mas precisos, una responsabilidad es afectada directamente cuando alguno de los métodos que la materializan ha sido eliminado o modificado, en otras palabras, si se encuentra en el source code. Por otro lado, una responsabilidad se considera afectada indirectamente si alguno de los métodos que la materializan se relaciona mediante la jerarquía de llamados

65 5.3. EXECUTION LOGGER 51 Figura 5.4: Diagrama de secuencia para la detección de source code Figura 5.5: Diagrama de secuencia para la detección de paths posiblemente cambiados con un método encontrado en el source code. La implementación actual solo considera aquellos métodos que llaman o son llamados por alguno de los métodos del source code. Como resultado del análisis estático de Diff Mapper, se obtiene una lista de paths posiblemente afectados por los cambios en el código fuente, los que serán procesados en las subsiguientes etapas. El diagrama de clase del componente puede apreciarse en la Figura Execution Logger Como se expuso brevemente en el capítulo anterior, este componente registra los eventos de bajo nivel que ocurren en la aplicación mientras el usuario la ejercita con los casos de uso correspondientes a los paths posiblemente cambiados. Para ello, se utilizó la infraestructura de instrumentación de código de FLABot (apéndice A, sección A.2), ya que define un punto de extensión para la configuración de los eventos que deben ser registrados en tiempo de ejecución.

66 52 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN org.isistan.flabot.core model.path <<<<detects>>>> 0..n <<<<searches on>>>> IDiffMapper getpotentiallychangeducmpaths... <<parameter>> org.isistan.flabot.javamodel.jbehavior org.isistan.flabot.coremod el.coremodel IDelta<JBehavior> 0..n 1 <<detects>> <<detects>> IJavaSourceDiffStrategy <<compares>> 1 2 org.eclipse.jdt.core.icompilationunit getdelta... JavaClassDiffStrategy <<implements>> <<uses>> rundif... org.eclipse.jdt.core.dom.astparser org.eclipse.core.resourc es.ifilestate <<uses>> LocalHistoryJavaSource DiffStrategy <<implements>> <<uses>> ASTMethodDeclarationVisitor <<uses>> org.eclipse.jdt.core.dom.astmatcher <<uses>> org.eclipse.jdt.core.dom.ast Figura 5.6: Diagrama de clases del componente Diff Mapper Básicamente, para la ejecución de una aplicación instrumentada es necesario (a) crear una nueva configuración de ejecución en Eclipse (launch configuration, Figura 5.7) y (b) iniciar la ejecución de esta configuración. FLABot permite la especialización de la funcionalidad del módulo de instumentación mediante el punto de extensión org.isistan.flabot.traceconfigurationprovider, que consiste en la definición de dos interfaces abstractas: TraceConfigurationTab y TraceConfigurationProvider, responsables de los puntos (a) y (b) respectivamente. Las implementaciones de la primera interfaz se encargan de permitir al usuario configurar de manera gráfica la información necesaria para la creación del log de ejecución (ubicación el archivo de salida, tipos de eventos a registrar, etc.), mientras que las de la segunda proveen esta información al módulo de instrumentación. La relación entre ArchSync y FLABot por medio de puntos de extensión se resume en la Figura 5.8. Una vez definida la extensión, la interacción entre FLABot y ArchSync es relativamente simple. Cuando la aplicación a instrumentar está a punto de ser ejecutada, se crea una instancia de ArchSyncTraceConfigurationProvider a la que se le interroga acerca de qué eventos deben ser registrados durante la ejecución. A su vez, el objeto utiliza los mapeos del UCM desactualizado y el resultado del análisis realizado por Diff Mapper, para indicar que debe ser registrada la ejecución de tanto los métodos asociados directamente a alguna responsabilidad como los métodos agregados o modificados que afectan indirectamente. Esta interacción se detalla de manera gráfica en el diagrama de secuencia de la Figura 5.9. Una vez provisto de la información necesaria, FlabotInstumentationLaucher se encarga de ejecutar la aplicación instrumentada y de registrar los eventos necesarios en el archivo que fue indicado durante la configuración.

67 5.3. EXECUTION LOGGER 53 Figura 5.7: Configuración de ejecución en Eclipse Figura 5.8: Relación entre ArchSync y FLABot mediante puntos de extensión Figura 5.9: Interacción entre ArchSync y FLABot previa a la instrumentación

68 54 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN 5.4. Log Analyzer Figura 5.10: Diagrama de clases de Log Analyzer Una vez que fue creado un log de ejecución para un caso de uso en particular, Log Analyzer se encarga de interpretar los eventos de bajo nivel contenidos en el log para transformarlo en una secuencia de activación de responsabilidades. El proceso de transformación fue abstraído mediante una interfaz abstracta para permitir la prueba con diferentes heurísticas sin que los cambios se propaguen en el resto del sistema, como se muestra en la Figura Para hacer esta transformación, el componente utiliza la información de mapeo entre responsabilidades y métodos como se muestra en el Algoritmo 3. Algoritmo 3 Algoritmo Log Analyzer log-analyzer(log: Log, mappings: Mappings) secuenciaactivaciones := Ø ultimaactivacion := null for entradalog in log responsabilidades = mappings.getcandidatas(entradalog) if (ultimaactivacion null) and (responsabilidades ultimaactivacion.responsabilidades Ø) ultimaactivacion.responsabilidades := responsabilidades ultimaactivacion.responsabilidades else ultimaactivacion = new Activacion ultimaactivacion.responsabilidades := responsabilidades secuenciaactivaciones := secuenciaactivaciones + ultimaactivacion end if end for return secuenciaactivaciones end log-analyzer El algoritmo recorre el log de ejecución, tomando sus entradas (ejecuciones de métodos) una a una. Dado que el mapeo responsabilidades-métodos es N:N, cada entrada puede corresponder a un conjunto de responsabilidades candidatas. Una vez que obtuvo este conjunto, verifica si su intersección con la última activación (entrada de log de alto nivel) no es vacía. Si esto es así, actualiza la activación con la intersección. Si la intersección es vacía, crea una nueva activación y pasa a la entrada siguiente. A modo de ejemplo, supongamos el log de ejecución del Cuadro 5.1. En la primera iteración del algoritmo, se crea una nueva activación con las responsabilidades {r1, r2, r3}. Luego, esta misma activación se reduce al conjunto {r1, r3}. En la tercera

69 5.5. PATH-LOG MATCHER 55 Método ejecutado Responsabilidades candidatas a() {r1, r2, r3} b() {r1, r3, r4} c() {r2} d() {r2, r3} Cuadro 5.1: Ejemplo de log de ejecución iteración, se crea una nueva activación con el conjunto {r2}, que en la iteración final no es modificada. La secuencia de activaciones resultante es {{r1, r3}, {r2}}, y se interpreta de la siguiente manera: primero se activó r1 o r3, luego se activó r Path-Log Matcher El módulo Path-Log Matcher es la parte central del enfoque ArchSync. Éste toma como entradas un UCM desactualizado y una secuencia de activación de responsabilidades, realiza una comparación entre ambas y finalmente, si encuentra diferencias, produce como salida un conjunto de alternativas de conciliación. Como se explicó en el capítulo anterior, el algoritmo Path-Log Matcher posee varios puntos cuyo comportamiento está gobernado por reglas: el procedimiento para avanzar un cursor según el tipo de nodo, las acciones correctivas posibles según el tipo de inconsistencia, la elección del cursor a comparar, etc. Además, en cada punto donde las reglas presenten más de una alternativa válida es necesario reevaluar cada una de ellas hasta alcanzar una solución. Por otro lado, al tratarse de un prototipo, era sabido de antemano que sería necesario experimentar con diferentes reglas de comportamiento hasta encontrar un conjunto relativamente estable. Path-Log Matcher fue implementado usando JavaLog [4], una integración de Java y Prolog. Ésto permitió la especificación del algoritmo en Prolog, un lenguaje en el que resulta más natural la programación de reglas y la reevaluación de alternativas. Además, al ser un lenguaje interpretado, fue posible probar diferentes combinaciones de reglas con diferentes prioridades sin necesidad de recompilar y reiniciar el prototipo. En la Figura 5.11 se muestra un diagrama de clases que ilustra cómo fue estructurado el módulo: PathLogMatcher: actúa como fachada del módulo, utilizando el patrón de diseño Façade [19]. Posee un método pathlogmatch que recibe un path y una secuencia de activación de responsabilidades como parámetros y devuelve un conjunto de scripts de actualización. JavalogConverter: se encarga de convertir los parámetros de entrada en estructuras Javalog (ver Figura 5.12). Para realizar esta tarea, abstrae la creación de los distintos tipos de estructuras por medio de la utilización del patrón de diseño Abstract Factory [19]. Una vez resuelto el algoritmo, convierte las estructuras Javalog generadas en scripts de actualización. ArchSyncJavalogEngine: es responsable de interactuar directamente con Javalog para obtener los resultados. Suministra el conjunto de reglas prolog definidas en pathlogmatch.pl y los parámetros recibidos como entrada a Javalog, para luego interrogarlo hasta obtener todas las alternativas de conciliación.

70 56 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN Figura 5.11: Diagrama de clases de Path-Log Matcher Path: Representación 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: Representación de paths en Prolog Brain: actúa como fachada de Javalog, también según el patrón Façade [19]. Simplifica la tarea de cargar y eliminar reglas de la base de datos, realizar queries y obtener resultados ofreciendo los métodos necesarios en su interfaz. Cuando se invoca a Path-Log Matcher, el componente actúa como se muestra en el diagrama de secuencia de la Figura Primero, PathLogMatcher convierte los parámetros recibidos como entrada en estructuras Javalog mediante JavalogConverter. Luego, invoca a ArchSyncJavalogEngine, que carga las reglas contenidas en pathlogmatch.pl y las agrega a la base de datos de Brain. Una vez que las reglas están cargadas, se reevalúa el query principal del algoritmo hasta que este falla, de esta forma obteniendo de manera exhaustiva todas las alternativas de conciliación. Finalmente, PathLogMatcher utiliza a JavalogConverter para convertir las estructuras Javalog obtenidas como resultado en scripts de actualización Conclusiones En éste capítulo se describieron los aspectos más importantes acerca de la arquitectura, diseño detallado e implementación de ArchSync. La herramienta requiere la colaboración de componentes pertenecientes a otros sistemas, mas específicamente Eclipse, FLABot y JavaLog. Eclipse fue seleccionado principalmente por ser el entorno de desarrollo Java más popular en la actualidad y además, por brindar una arquitectura preparada para la integración de herramientas mediante extensiones. En segundo lugar, Eclipse ofrece un metamodelo del lenguaje Java idóneo para la manipulación de información de

71 5.6. CONCLUSIONES 57 Figura 5.13: Diagrama de secuencia de Path-Log Matcher código fuente. Las estrategias definidas en el módulo Diff Mapper hacen uso de esta infraestructura para detectar clases eliminadas y modificadas, así como para la comparación de versiones diferentes de clases Java. Aunque la versión actual de Diff Mapper emplea la historia local de Eclipse como repositorio de clases modificadas y eliminadas, se tomaron las precauciones necesarias para que pueda hacerlo utilizando otros recursos, como repositorios CVS, Subversion, etc. FLABot, por otro lado, se emplea por dos razones centrales: ofrece un editor UCM con soporte para mapeo responsabilidad-código y además incluye soporte para instrumentar aplicaciones. El motor de instrumentación de aplicaciones FLABot genera un log de bajo nivel que es procesado por el componente Log Analyzer para construir un registro de responsabilidades activadas. El algoritmo Path-Log Matcher se materializó en Prolog, por resultar el paradigma de la programación lógica mucho mas natural a la hora de especificar la comparación entre el UCM desactualizado y la secuencia de activación de responsabilidades. Sin embargo, en vistas de que la mayor parte de ArchSync se implementó en Java, fue necesario integrar este paradigma con el de la programación orientada a objetos. Para tal fin, JavaLog resultó ideal pues ha sido concebido con tales objetivos. De esta forma, si el equipo de desarrollo pretende incorporar la nueva tarea de sincronización entre implementación y especificación UCM a sus tareas rutinarias, podrá hacerlo incluyendo únicamente el plug-in ArchSync para Eclipse y sus dependencias, es decir: FLABot y JavaLog. En la mayoría de los casos, este requerimiento implica que los programadores no necesitarán nuevas herramientas de desarrollo, ni siquiera repositorios para el control formal de versiones. En el próximo capítulo se analizará el desempeño de ArchSync ante dos sistemas reales en desarrollo: G2 y FLABot. Tales casos de estudio permitirán evaluar mejor la conveniencia de las decisiones de diseño explicadas en este capítulo.

72 58 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN

73 Capítulo 6 Casos de estudio Este capítulo describe una serie de casos de estudio que realizamos para verificar si las suposiciones hechas a nivel conceptual pueden ser corroboradas en la práctica. Los casos de estudio presentados aquí apuntan primero a demostrar que el enfoque ArchSync puede ser aplicable a la sincronización de UCMs con implementación, y segundo, a ilustrar cómo se usó la herramienta en diferentes proyectos, para poder investigar los puntos fuertes y débiles del enfoque. En particular, en este capítulo se pretende analizar la utilidad, precisión y validez de la herramienta frente a modificaciones del código fuente y UCMs de diferente complejidad. En cada caso de estudio se medirán (a) la cantidad de trabajo que le fue ahorrado al arquitecto en el análisis de los cambios y en la sincronización de la documentación como indicadores de utilidad, (b) la cantidad de soluciones diferentes propuestas por la herramienta como indicador inverso a la precisión y (c) si la solucion esperada por el arquitecto estaba entre las alternativas como indicador de validez. La selección de los casos de estudio estuvo organizada de acuerdo con una estrategia incremental. Inicialmente, se probó la herramienta con ejemplos simples como los presentados en los capítulos anteriores. Ésto permitió ajustar el funcionamiento del prototipo hasta obtener resultados aceptables. Una vez alcanzada una versión relativamente estable del prototipo, se tomaron las especificaciones UCM y el historial de código fuente de un proyecto comercial de tamaño mediano, llamado G2. En esta etapa, se probó el desempeño de la herramienta frente a cambios en el código fuente de un sistema real. Finalmente, analizamos los cambios en el código frente a la especificación en UCMs de FLABot, un proyecto de investigación de mayor envergadura. En esta etapa, hicimos pruebas de mayor complejidad, evaluando la herramienta frente a casos en los que un mismo cambio en el código afecta varios paths. A su vez, esta etapa fue útil como una forma de auto-validación, ya que se trata del mismo proyecto al cual ArchSync se integra. El capítulo se encuentra organizado de la siguiente manera. Primero se presentan los casos de G2 en la sección 6.1. A continuación, en la sección 6.2, se presentan los resultados de las pruebas con FLABot. Finalmente, en la sección 6.3, se comparan los resultados de ambos experimentos mediante un breve análisis 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 interactúa por medio de un browser y envía solicitudes que son interceptadas por un servidor web para ser delegadas al servidor G2, en la segunda banda correspondiente a la lógica del negocio, por intermedio del componente GateKeeper. Esta banda fue implementada mediante la instanciación 59

74 60 CAPÍTULO 6. CASOS DE ESTUDIO Figura 6.1: Arquitectura de G2 de un framework basado en invocación implícita llamado Bubble [14], donde la funcionalidad se encuentra organizada en tareas que son asignadas a diferentes agentes reactivos. GateKeeper traduce cada solicitud para activar a los agentes encargados de ejecutar las tareas correspondientes. Las tareas relacionadas con la administración del modelo del negocio normalmente interactúan con el componente de persistencia para consultar o alterar los datos relevantes del repositorio de datos, en la tercer banda. Los siguientes casos de estudio sobre el sistema G2 se efectuaron sobre el componente de la segunda banda del modelo three-tier, por ser éste el subsistema mas complejo y donde se concentró el trabajo de desarrollo Caso 1 Un escenario donde puede verse en acción el modelo típico del sistema G2 es el caso de uso removeuser presentado en el path la Figura 6.2. Aquí un usuario administrador envía por medio de su browser la solicitud de eliminar a otro usuario del sistema, siempre que sus permisos lo permitan. Cuando esta solicitud llega al sistema por medio del GateKeeper, se activan los agentes encargados de eliminar a un usuario del modelo. Una vez que el agente asignado detecta esta señal, invoca a la tarea de eliminación, representada por la responsabilidad UCM removeuser. Mas adelante, se eliminan los registros relacionados del repositorio de datos, como lo indica la responsabilidad UCM deleteuserfromdb y finalmente se le retorna una página con el listado actualizado de usuarios; representado por la secuencia de activación de responsabilidades listusers, generatehtmlresponse y sendresponse. A pesar de que el escenario es sencillo y concuerda con lo que puede esperarse de la funcionalidad de borrado, durante el desarrollo se reportó la necesidad no solo de dar de baja al usuario del sistema, sino también de cerrarle su sesión en caso de que éste se encontrara utilizando el sistema al mismo tiempo que es eliminado. Aunque las modificaciones realizadas para soportar este requerimiento fueron pocas, el caso de análisis propuesto es interesante por la relativa complejidad de la arquitectura: un sistema basado en agentes reactivos por invocación implícita, cada uno con su propio thread. Por otro lado, el intervalo entre la última sincronización y el momento en que se realizaron los cambios fue de seis días, caracterizados por un

75 6.1. G2 61 Figura 6.2: UCM para la acción eliminar usuario Figura 6.3: Análisis estático de código fuente durante la detección de paths potencialmente modificados trabajo intensivo dedicado a cerrar un nuevo release del producto. En otras palabras, los cambios en el código fuente desde la última sincronización fueron numerosos y el análisis de ArchSync (Figura 6.3) señaló, como se esperaba, que el path removeuser y logout, podrían haber sido afectados por estas modificaciones sobre la implementación (Figura 6.4). La Figura 6.5 muestra la interfaz gráfica del sistema G2 durante su ejecución instrumentada, lista para proceder con la eliminación de un usuario. A su vez puede observarse un panel de control que el arquitecto emplea para decidir el momento en que las acciones instrumentadas deben registrarse en el log de ejecución. Luego de reproducido el escenario sobre el sistema instrumentado, Path-Log Matcher analizó la traza de ejecución (ver Figura 6.6) y sugirió (ver diálogo Path-Log Matcher Result en fig. 6.7) el script de actualización reproducido en la Figura 6.9. Aquí ArchSync indica 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 según el análisis estático de código fuente

76 62 CAPÍTULO 6. CASOS DE ESTUDIO Figura 6.5: Instrumentación de la aplicación G2 durante el caso de uso eliminar usuario Figura 6.6: Selección de traza de ejecución para analizar

77 6.1. G2 63 Figura 6.7: Diálogo Path-Log Matcher Result responsabilidad y dos responsabilidades existentes en el UCM logout, ilustrado en la Figura En resumen, el script sugiere la inserción secuencial de tres nuevas responsabilidades en el path: GateKeeperImplementation.getUserAgents(...): La primer inserción, listada en la Figura 6.8 correspondiente a una responsabilidad candidata, surge luego de que ArchSync detectara la ejecución de un método que no tiene mapeo directo en el caso de uso, pero que tampoco debería ser descartado porque podría alterar el path. El comando de corrección en este caso es de tipo insert- Between, es decir, sugiere agregar un nuevo nodo entre dos existentes, especificados en los dos primeros argumentos: deleteuserfromdb y listusers. El nuevo nodo que sugiere ArchSync se especifica en la estructura definida como tercer argumento del comando de actualización. Este nuevo nodo, cuyo identificador asignado es newnode1, está formado por la responsabilidad candidata getuseragents(int):java.util.vector, identificada así en base al método detectado como posible alterador del path; mapeada al componente potencial com.delsatgroup.g2.kernel.gatekeeperimplementation, sugerido en función de la clase que contiene al método anterior, con un rol no determinado y tipo de nodo asociado simple (es decir que no se trata de un nodo fork o un join). En este caso, el método sugerido como potencial responsabilidad permite el acceso a los usuarios logueados en el sistema y no se considera relevante arquitectónicamente, por lo tanto, la experiencia del desarrollador debería determinar que esa inserción sugerida puede descartarse. LoginManager.logoutUserAgent: La segunda sugerencia, también de tipo de tipo insertbetween, aparece como consecuencia de la activación de métodos mapeados al UCM logout, que se analizará mas adelante. Aquí se descubre la acción de desloguear al agente asociado al usuario que se está eliminando. GateKeeper.invalidateSession: Mas adelante, en el mismo escenario, ArchSync detectó la activación de otra responsabilidad existente en el UCM logout, en este caso se trata de la invalidación de sesión del usuario eliminado del sistema, como indica el mapeo a la responsabilidad invalidatesession. Las últimas dos sugerencias reflejan correctamente en el UCM los cambios ejercidos en su implementación y por lo tanto, son aplicados, dando como resultado el UCM ilustrado en la Figura Caso 2 El segundo caso de estudio relacionado con el sistema G2 se enfoca sobre el escenario logout, reflejado en al Figura Este caso de uso es muy conocido por

78 64 CAPÍTULO 6. CASOS DE ESTUDIO insertbetween(deleteuserfromdb, listusers, node(newnode1, getuseragents(int):java.util.vector, com.delsatgroup.g2.kernel.gatekeeperimplementation,?role, simple ) ) Figura 6.8: Primer sugerencia de inserción de la responsabilidad candidata getuser- Agents(int):java.util.Vector. En este caso, no se considera relevante arquitectónicamente. insertbetween(deleteuserfromdb, listusers, node(newnode1, getuseragents(int):java.util.vector, com.delsatgroup.g2.kernel.gatekeeperimplementation,?role, simple ) ), insertbetween(newnode1, listusers, node(newnode2, logoutuseragent, LoginManager, loginmanager, simple ) ), insertbetween(newnode2, listusers, node(newnode3, invalidatesession, GateKeeper, gatekeeper, simple ) ) Figura 6.10: UCM actualizado para la acción eliminar usuario Figura 6.9: Script de actualización para el path eliminar usuario

79 6.1. G2 65 Figura 6.11: UCM para la acción salir del sistema la mayoría de los usuarios de aplicaciones web, pues se trata de la funcionalidad que permite a un usuario identificado, cerrar su sesión de trabajo dentro del sistema. Dentro del servidor G2, la partida de un usuario implica a grandes rasgos dos caminos, identificados a partir de la responsabilidad de tipo AND Fork, llamada dologoutrequest. Una secuencia es la que elimina efectivamente la instancia que representa al usuario dentro del servidor, la otra es la encargada de retornar una página de respuesta, informando que se ha salido del sistema. Uno de los requerimientos de modificación del sistema, también implementado durante el mismo período que el analizado en la subsección 6.1.1, fue la serialización de las operaciones requeridas para despedir a un usuario del sistema. Anteriormente se invocaba implícitamente la generación de la respuesta y luego se invalidaba su sesión, pero la característica asíncrona de la primer invocación no aseguraba que la sesión se invalidara antes de que se remitiera la respuesta, generando páginas de error en el browser del usuario. La nueva modificación empleó invocación síncrona para generar la respuesta, evitando el problema anterior. La detección de cambios efectuada por ArchSync informó que este path podría haber sido afectado por los últimos trabajos de implementación, 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 en que se ejecutaban los dos paths posteriores. Una vez ejecutado el escenario, el análisis de trazas de ArchSync sugirió varios scripts alternativos. El primero indicaba que el path de ejecución concordaba con la implementación, y por consiguiente, que no era necesaria la actualización del UCM. Tal afirmación es válida porque la bifurcación tipo AND Fork de caminos es lógica, o sea, indica que conceptualmente los caminos son paralelos porque pueden ejecutarse en cualquier orden, independientemente de que su implementación sea secuencial, dentro de un único hilo de ejecución o en threads o procesos diferentes. Sin embargo, aquí nuevamente entra en juego el criterio del usuario para determinar si esta sugerencia refleja nuestra intención o no. Puntualmente para esta situación, la sugerencia no es la mas apropiada, pues conceptualmente, una cadena de activación debe seguirse estrictamente antes que la otra, para evitar los problemas que motivaron los cambios en el código fuente. A pesar de que la primer sugerencia no es la ideal, ArchSync ofrece otra alternativa, planteada en la Figura Aquí se sugieren dos inserciones y una secuencia de eliminaciones. Las responsabilidades que se sugieren agregar a continuación de la

80 66 insertafter(sendresponse, node(newnode1, logoutuseragent, LoginManager, loginmanager, simple ) ), insertafter(newnode1, node(newnode2, invalidatesession, GateKeeper, gatekeeper, simple ) ), removeallfrom(logoutuseragent) Figura 6.12: Script de actualización alternativo para el UCM salir del sistema CAPÍTULO 6. CASOS DE ESTUDIO Figura 6.13: UCM actualizado para la acción salir del sistema existente sendresponse son las siguientes: LoginManager.logoutUserAgent: Esta responsabilidad es la que elimina al agente asociado al usuario en cuestión y es insertada luego de que se le remite la página de despedida al usuario. Notar que este nodo ya existe en el otro subpath paralelo, aunque será eliminado mas tarde de allí. GateKeeper.invalidateSession: La acción asociada con esta responsabilidad es invalidar la sesión 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 responsabilidades después de logoutuseragent, inclusive. En otras palabras, se eliminan de un subpath las responsabilidades que acaban de insertarse en el otro, acción equivalente a mover la secuencia (logoutuseragent, invalidatesession) al final del envío de la página de respuesta, transformando implícitamente la responsabilidad de tipo AND Fork (dologoutrequest) en una responsabilidad simple y al UCM resultante en un único camino secuencial. Tal script refleja los cambios en la implementación y por lo tanto es aplicado, transformando el UCM en el de la Figura FLABot Como se explica en la sección A.2, FLABot es una herramienta de debugging y localización de fallas para plug-ins de Eclipse, que se basa en información arquitectónica, expresada en forma de UCMs, para aproximar las regiones de código donde es más probable que se hayan originado las fallas. En este caso de estudio, nos enfocamos sobre el editor de UCMs provisto por FLABot. En particular, analizamos tres paths correspondientes a acciones de edición activadas a través del menú contextual: insertar fork, rotar fork e insertar responsabilidad (Figura 6.14). Como se puede ver en la figura, los tres paths son muy similares: todos comienzan con la activación de la acción de menú contextual (X Action), siguen con la creación del comando correspondiente (X Command), para

81 6.2. FLABOT 67 Figura 6.14: UCMs para la acciones insertar fork, rotar fork e insertar responsabilidad. Figura 6.15: Vista de ArchSync en Eclipse, mostrando el conjunto de paths de FLABot identificados 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 terminó de implementar un nuevo requerimiento, que consistía en la inserción de un mediador entre las acciones y la pila de comandos, nos pusimos en el rol de arquitectos de FLABot y usuarios de ArchSync. Entonces, decidimos controlar la nueva versión del proyecto, para detectar si los cambios en la implementación afectan alguno de los UCMs actuales, y si así fuera, cuáles son los artefactos de implementación modificados que lo hacen. El análisis detectó que los UCMs presentados podrían estar afectados por los cambios (Figura 6.15). A partir de este punto, se fueron tomando estos paths uno a uno para generar sus correspondientes trazas de ejecución, compararlas con el modelo desactualizado y finalmente aplicar o no algún script de actualización. A continuación, se muestran los resultados obtenidos para cada uno de los paths afectados: 1. Insertar fork La comparación del path insertar fork con su correspondiente traza de eje-

82 68 CAPÍTULO 6. CASOS DE ESTUDIO insertbetween( createinsertforkcommand, stackexecutecommand, node(newnode1, executecommand(command,...), FlabotGraphicalEditor,?role, simple)), insertafter( executeinsertfork3, node(newnode2, markdirty, FlabotMultiPageEditor,?role, simple)) Figura 6.16: Script de actualización para el path insertar fork Figura 6.17: UCM actualizado para la acción insertar fork cución, produjo como resultado el script de actualización que se muestra en la Figura El script sugiere la inserción de dos nuevas responsabilidades en el path: FlabotGraphicalEditor.executeCommand(...): La primera operación sugerida advierte la ejecución del método executecommand(...) de la clase FlabotGraphicalEditor entre las responsabilidades createinsertfork- Command y stackexecutecommand. Teniendo en cuenta el requerimiento que originó el cambio, identificamos a la clase sugerida como una implementación del mediador entre acciones y pila de comandos (al que llamamos CommandExecutor). Asimismo, identificamos al método sugerido como la implementación de la responsabilidad del mediador encargada de la ejecución de comandos (a la que llamamos executorexecutecommand, para diferenciarla de otra responsabilidad existente). La aplicación de esta operación del script, entonces, implica la creación de un nuevo componente y una nueva responsabilidad, respectivamente mapeados a la clase y el método sugeridos. FlabotMultipageEditor.markDirty: En contraste, la segunda operación advierte la ejecución de un método que realiza una operación irrelevante en el contexto de este path: poner un flag de sucio en el editor en valor verdadero para saber que, cuando se cierre, es necesario pedir confirmación al usuario. Por lo tanto, como usuarios de la herramienta decidimos no aplicar el segundo cambio. El UCM resultante se muestra en la Figura Rotar fork Luego de actualizar el path anterior, se creó una nueva traza de ejecución para comparar con el path desactualizado rotar fork. Terminada la comparación, el diálogo Path-Log Matcher Result (Figura 6.18) propuso el script de actualización de la Figura Al analizar el script se puede notar que sugiere la inserción de responsabilidades y componentes; el script anterior, en contraste, sugirió clases y métodos. Ésto se debe a que durante la actualización del path anterior se crearon elementos arquitectónicos mapeados a estos elementos de

83 6.2. FLABOT 69 Figura 6.18: Diálogo Path-Log Matcher Result. insertbetween( createrotateforkcommand, stackexecutecommand, node(newnode1, executorexecutecommand, CommandExecutor, newcommandexecutor, simple)) Figura 6.19: Script de actualización para el path rotar fork Figura 6.20: UCM actualizado para la acción rotar fork bajo nivel, y ArchSync ha incorporado esta información para el análisis del path actual. El path resultante de la aplicación del script se puede ver en la Figura Insertar responsabilidad Finalmente, se comparó el path insertar responsabilidad con su correspondiente traza de ejecución. Como resultado, se produjo el script de la Figura De manera similar al caso anterior, ArchSync propone otra vez la inserción de la nueva responsabilidad. En la Figura 6.22 se muestra el UCM luego de la actualización. Desde la perspectiva de ArchSync, éste resultó ser un cambio relativamente complejo: insertbetween( createinsertresponsibilitycommand, stackexecutecommand, node(newnode1, executorexecutecommand, CommandExecutor, newcommandexecutor, simple)) Figura 6.21: Script de actualización para el path insertar responsabilidad Figura 6.22: UCM actualizado para la acción insertar responsabilidad

84 70 CAPÍTULO 6. CASOS DE ESTUDIO fue necesario detectar la creación de un nuevo componente y una nueva responsabilidad. Además de la detección de los nuevos elementos arquitectónicos, ArchSync identificó correctamente todos los paths afectados por el cambio y sugirió las actualizaciones apropiadas para reflejar la inserción de un intermediario entre acciones y pila de comandos Análisis de resultados Los casos de prueba desarrollados en el presente capítulo ponen bajo análisis dos sistemas de proporciones diferentes. Por un lado, G2, un proyecto mediano de aproximadamente 900 clases, especificado parcialmente a nivel arquitectónico por 34 escenarios UCM. Por otro lado, FLABot, un proyecto casi tres veces mayor en tamaño, conformado por mas de 2500 clases java y especificado también parcialmente por 122 UCMs. Si bien es importante tener en cuenta la cantidad de clases como medida de tamaño de un sistema, en nuestro caso es importante determinar cuáles de estas clases juegan un papel importante en la materialización de la arquitectura. En otras palabras, cuáles contribuyen a la materialización de las responsabilidades asignadas a los diferentes componentes de la arquitectura del sistema. En el caso de G2, de las 900 clases, solo 98 podían considerarse relevantes arquitectónicamente, mientras que en FLABot este número fue de 270. Claramente estos valores indican una proporción muy baja de clases relevantes, hecho que pone bajo duda la razón de existencia de tan elevado número de clases que aparentemente no contribuyen con los aspectos elementales de la arquitectura propuesta. Para entender esta relación, es importante aclarar que este número se presupone mucho mayor, pero siendo que la especificación UCM de ambos sistemas es incompleta, es decir que solamente cubre un subconjunto de toda la funcionalidad, solo una porción pequeña de la implementación es mapeada a los paths UCM. Por esta razón, varias clases han quedado sin su correspondiente mapeo, pasando implícitamente a la categoría de clase no relevante arquitectónicamente. Esta diferencia en el volumen de ambos proyectos puede notarse en el número de clases y paths afectados descubiertos por ArchSync, como se refleja en la Figura Estado de los proyectos ante cambios en la implementación En el caso de G2, ArchSync determinó que el source code de prueba estaba conformado por 20 clases modificadas. Sin embargo, solamente 2 de ellas tenían mapeos arquitectónicos. En otras palabras, ArchSync redujo el espacio de búsqueda en un 90 %. Estas 2 clases representan el 2,04 % del total de clases con importancia arquitectónica, y los dos paths detectados por ArchSync como potencialmente modificados representan el 5,88 % de todos los paths de la especificación UCM. Esto significó un ahorro significativo en el esfuerzo del arquitecto, ya que evitó revisar un 97,96 % de las clases relevantes y un 94,12 % de los paths. Por otro lado, en el caso del proyecto FLABot, el source code del caso de estudio estaba constituido por un total de 91 clases modificadas, de las cuales solo 15 afectaban algún flujo de control en la especificación UCM. Al detectar esto, ArchSync redujo el espacio de búsqueda en un 83,52 %. Esas 15 clases representan el 5,56 % del total de clases relevantes arquitectónicamente, y ArchSync detectó que 11,48 % de los paths (14 de 122) habían sido cambiados. Esto evitó revisar un 94,44 % de las clases relevantes y un 88,52 % de los paths. Un resumen de estos índices puede verse en el Cuadro 6.1.

85 6.3. ANÁLISIS DE RESULTADOS 71 G2 FLABot # total de clases # clases con mapeo # clases en # 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 implementación Figura 6.23: Clases con mapeo cambiadas vs. paths afectados La primer conclusión que puede derivarse de estos valores es la utilidad de Arch- Sync para reducir el espacio de búsqueda ante los cambios sufridos durante el desarrollo en la implementación. Como se justificó antes, la detección y exposición de los cambios brinda al arquitecto la oportunidad de descubrir potenciales violaciones a las restricciones impuestas por la arquitectura, pero si el espacio de búsqueda, es decir, la cantidad de clases sospechosas se mantiene demasiado alto, este trabajo deja nuevamente de ser trivial, de aquí que la drástica reducción en este espacio es una característica beneficiosa. Por otro lado, descubrimos que mientras más clases relevantes arquitectónicamente sean afectadas, mayor es la cantidad de paths a corregir y por lo tanto es más trabajo para el arquitecto. Esta consecuencia es inevitable y razonable: si los cambios en la implementación son importantes y numerosos, mas comprometida se verá la especificación UCM y por lo tanto, mayor será la cantidad de trabajo a sincronizar Propuesta de solución de ArchSync Antes de proceder con el análisis de las soluciones propuestas por ArchSync ante los distintos casos de estudio, vale la pena explicar brevemente una medida de complejidad de los paths UCM que se utilizará aquí. Tomamos como medida de complejidad de los paths a la cantidad de responsabilidades que intervienen en el escenario multiplicada por la cantidad de bifurcaciones (AND fork y OR fork) cuando exista

86 72 CAPÍTULO 6. CASOS DE ESTUDIO G2.1 G2.2 FLABot.1 FLABot.2 FLABot.3 complejidad del path # alternativas # 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 conciliación al menos alguna en el path. La razón de esta métrica se fundamenta en que cada bifurcación puede considerarse como un nuevo path y por lo tanto, la cantidad de alternativas a evaluar crece proporcionalmente con este número, aumentando entonces su complejidad intrínseca. Para el primer caso de análisis del sistema G2 (UCM removeuser) la complejidad del path es de 6 y la cantidad de soluciones alternativas de 3. Por otro lado, el segundo caso (UCM logoutuser) se determinó de complejidad 12 por contener una bifurcación de tipo AND, con 10 scripts alternativos para corregir el UCM desactualizado. En cualquiera de los casos de estudio sobre FLABot la complejidad es de 4 mientras que la cantidad de scripts alternativos fue de 2. Respecto a la característica de las soluciones propiamente dichas, dado que en el caso de estudio G2 los cambios en el código fueron mas profundos (es decir, afectaban en mayor grado el flujo de control y datos de los paths relacionados), se obtuvieron scripts con un número promedio de operaciones de 3,1 y 4,2 respectivamente. En FLABot, en cambio, si bien se afectó un número mayor de paths, el cambio en cada uno de ellos fue más simple y por lo tanto el número de operaciones promedio por script fue de 2,2. Estos valores pueden verse resumidos en el Cuadro 6.2. Aquí la conclusión principal que puede extraerse es que el número de posibles soluciones aumenta a medida que lo hace la complejidad de los paths. Este aumento en el número de opciones para sincronizar el UCM puede verse como una disminución en la precisión, al requerir mayor atención por parte del arquitecto quien debe analizar cada una para escoger la mas apropiada. La Figura 6.24 muestra el crecimiento en la cantidad de alternativas a medida que la complejidad también aumenta. Además es importante destacar que a veces los cambios en el código representan una violación de las prescripciones impuestas por la arquitectura. En estos casos no es necesario actualizar los UCMs, sino recodificar las partes de la implementación correspondientes.

87 6.3. ANÁLISIS DE RESULTADOS 73 También se desprende de estos casos de estudio que la complejidad de los scripts, medido en función del número de operaciones, aumenta cuanto más profundo es el cambio introducido en la implementación. La profundidad de un cambio en el código puede verse como la variación en el flujo de control y de datos representado en el UCM, tal cual lo alteraría un arquitecto manualmente en la documentación. El haber utilizado JavaLog para la implementación de Path-Log Matcher, si bien brinda flexibilidad a la hora de agregar o modificar reglas, acarrea los problemas típicos en los lenguajes interpretados. Por otro lado, la ejecución de una aplicación instrumentada es cada vez más lenta a medida que crece la cantidad de puntos que están siendo inspeccionados. Asimismo, la memoria y el procesamiento requeridos para el análisis de los logs de bajo nivel crece según la naturaleza del caso de uso que esta siendo analizado. En resumen, las pruebas realizadas sobre ambos proyectos revelaron la importante asistencia que significa el uso de ArchSync en proyectos de desarrollo. El espacio de búsqueda, tal como debería ser analizado por un arquitecto para descubrir los cambios, se reduce notablemente en comparación con el total de clases relevantes arquitectónicamente y aún así, el registro de trazas de ejecución del sistema evita que estas clases deban ser inspeccionadas. Por otro lado, la precisión de la herramienta se ve comprometida por la complejidad de los paths y por la profundidad de los cambios. Éste último índice irá en aumento a medida que el intervalo entre sincronizaciones aumente, confirmando la suposición de que de ArchSync debe utilizarse frecuentemente para minimizar la cantidad de cambios importantes sobre los paths UCM.

88 74 CAPÍTULO 6. CASOS DE ESTUDIO

89 Capítulo 7 Conclusiones y trabajos futuros En los capítulos previos de este trabajo se presentó ArchSync, un enfoque para la sincronización de documentación de diseño en forma de UCMs con su implementación. Mediante el uso de información de mapeo entre elementos arquitectónicos y código fuente, ArchSync permite la modificación semiautomática de las partes de la documentación que han quedado desactualizadas para ponerlas en correspondencia con el estado actual de la implementación. Las opciones de actualización propuestas por el enfoque se obtienen como producto de la comparación de los paths descriptos por la documentación con las trazas de ejecución capturadas durante el ejercicio de la aplicación. El prototipo de ArchSync fue implementado como plug-in de Eclipse, aprovechando su infraestructura de historial de archivos y su metamodelo Java para el análisis de código fuente. A su vez, ésto permitió aprovechar los editores de UCM y el módulo de instrumentación de código de FLABot. Adicionalmente, la integración con el entorno de desarrollo facilita la adopción del enfoque dentro del proceso de desarrollo de un sistema, ya que permite la ejecución del proceso de sincronización como una tarea más del desarrollador. Como aporte principal, ArchSync permite actualizar los UCMs arquitectónicos con respecto a su implementación. Al mismo tiempo, el enfoque revela violaciones a las reglas de comportamiento impuestas por el estilo arquitectónico a un nivel de abstracción apropiado para hacerlas evidentes. Por lo tanto, el análisis realizado por la herramienta también puede ser usado por el arquitecto para decidir la recodificación de algunas partes de la implementación de acuerdo con las prescripciones arquitectónicas. Por otro lado, el enfoque se basa en ciertas suposiciones y tiene algunas limitaciones. Primero, cuando ocurre un cambio en el código fuente, suponemos que es posible conocer los mapeos previos entre UCMs e implementación. Esto significa que la implementación anterior a los cambios era consistente con los escenarios descriptos en los UCMs. Estos mapeos deberían ser especificados cuando el arquitecto crea los UCMs por primera vez y luego procede a implementarlos. En segundo lugar, el enfoque asume que las sincronizaciones entre UCMs e implementación se realizan con una frecuencia acorde al ritmo de desarrollo del sistema, para asegurar que los cambios entre las diferentes versiones del código fuente presenten pocas variaciones. Si esto no es así, el reconocimiento de las activaciones de responsabilidades basado en los eventos de los logs de ejecución se puede volver computacionalmente inmanejable. La desventaja principal del enfoque radica en la distancia entre un UCM dado y las muchas implementaciones posibles para los paths de responsabilidades. La herramienta trata de reconstruir los paths de responsabilidades usando un análisis bidireccional, que combina ingeniería reversa de los logs de ejecución con informa- 75

90 76 CAPÍTULO 7. CONCLUSIONES Y TRABAJOS FUTUROS ción semántica proveniente de los UCMs desactualizados. Sin embargo, este procesamiento está lejos de ser automático, porque requiere una cantidad considerable de conocimiento semántico que debe ser proporcionado por el arquitecto. El arquitecto interactúa con la herramienta en dos puntos: para proveer los logs de ejecución correctos y para seleccionar entre las opciones de conciliación. Además, si bien la herramienta proporciona indicios de la aparición de nuevas responsabilidades, tanto éstas como sus correspondientes mapeos deben ser especificados de manera manual. La notación UCM da una noción de la estructura del sistema mediante componentes y responsabilidades, que es reforzada mediante los mapeos componente-clase y responsabilidad-método. Sin embargo, esta información no puede considerarse una documentación completa de la estructura de un sistema a nivel arquitectónico, ya que no define de manera explícita las relaciones entre estos elementos (por ejemplo, la estructura de herencia en una vista estática o los puertos y conectores en tiempo de ejecución). Otra debilidad que detectamos en nuestro enfoque es que su análisis es puramente sintáctico: no considera la semántica de las prescripciones ni los estilos arquitectónicos. Finalmente, es necesario mencionar algunas desventajas inherentes a las técnicas de instrumentación de código y análisis de logs de ejecución, que fueron acarreadas por este trabajo. El módulo de instrumentación de FLABot se encuentra estable y ha sido utilizado exitosamente en un gran número de aplicaciones. Sin embargo, justamente al modificar el código existente, es imposible garantizar que el comportamiento de la aplicación no se ve modificado respecto a su versión sin instrumentar. Por otro lado, la elección de los puntos a inspeccionar para generar un log de ejecución implica un tradeoff importante. En teoría, sería posible registrar la ejecución de cada línea de código y el estado de todos los objetos en cada instante. De esta manera, se podría realizar un análisis más preciso y exhaustivo, ya que se contaría con absolutamente toda la información posible acerca de la ejecución de la aplicación. Sin embargo, la cantidad de información almacenada se volvería inmanejable y la aplicación analizada.se vería extremadamente afectada en su rendimiento, ya que por cada línea ejecutada se activaría el mecanismo de publicación y subscripción de eventos del instrumentador Trabajos futuros La elaboración de este trabajo, junto con la implementación del prototipo, puso en evidencia nuevas posibilidades para investigaciones futuras, como así también algunas posibles mejoras a la implementación existente. En esta sección se describen algunas de ellas Integración con aspectos estructurales Si bien ArchSync produjo buenos resultados en la sincronización de UCMs con implementación, está claro que hay muchas partes de la documentación de una arquitectura para las que esta notación no es apropiada. Para abarcar una mayor proporción de la documentación, es necesario tener en cuenta los aspectos estructurales de la arquitectura, generalmente especificados mediante diagramas de descomposición de módulos para una vista estática, de componentes y conectores para vistas que representan la estructura en tiempo de ejecución y de deployment para mostrar cómo se relaciona el sistema con los elementos de su ambiente que no son software. Creemos que la integración de algunos de los enfoques estructurales basados en ingeniería reversa, presentados en la Sección 3.1.1, con el concepto de sincronización incremental presentado en este trabajo puede ser beneficiosa por varias razones. Prin-

91 7.1. TRABAJOS FUTUROS 77 cipalmente, mejoraría el desempeño de ArchSync al permitir una sincronización más completa de la documentación de diseño. Además, al aprovechar la documentación existente que no ha sido afectada por los cambios en el código, se reduce la cantidad de información semántica que se requiere y, por lo tanto, la necesidad de intervención del arquitecto en el proceso Trazabilidad en métodos de diseño Los artefactos producidos durante el desarrollo de software tales como descripciones de modelos, diagramas, especificaciones formales abstractas y código fuente están altamente interrelacionados, ya que los cambios en algunos de ellos afectan a otros. La falta de información acerca de estas relaciones o la incerteza acerca de la información existente limita la utilidad de los modelos de software durante el desarrollo. ArchSync ataca el problema particular de sincronización de relaciones entre código fuente y UCMs. Sin embargo, la perspectiva práctica tomada en el desarrollo de este trabajo nos hace creer posible su extensión para soportar la sincronización de otro tipo de relaciones entre elementos de los modelos Mapeo de paths con casos de test Una vez que la aplicación que está siendo analizada se ha puesto en ejecución, el proceso de ejercitarla con los casos de uso correspondientes a los paths desactualizados se debe realizar de manera manual. En caso de tener que verificar un número considerable de paths, la tarea se puede volver muy tediosa, aumentando la probabilidad de introducir errores en el análisis por distracciones del usuario. Un posible trabajo futuro para mitigar esta debilidad del enfoque puede ser permitir el mapeo de UCMs con casos de test. Al contar la herramienta con información acerca de qué caso de test corresponde a cada path, sería posible la creación de los logs de ejecución necesarios sin intervención del usuario. Además, esto puede permitir un análisis de cobertura de los casos de test: si se detecta que un log de ejecución no cubre cierta porción de código que ha sido modificada, se puede advertir al usuario que es necesaria la creación de un nuevo caso o la modificación del existente Especialización del enfoque Durante la elaboración de este trabajo, se trató de mantener la generalidad del enfoque al no limitarlo a ningún estilo arquitectónico en particular o a algún conjunto de convenciones de implementación específico. Como objetivo de diseño, ésto tuvo un efecto positivo en el trabajo ya que permite el uso de la herramienta en cualquier sistema que haya sido implementado en Java. Sin embargo, creemos que los estilos arquitectónicos y las convenciones de implementación pueden aportar información valiosa al enfoque. Mediante la especialización de las reglas de análisis de Path-Log Matcher para algún estilo particular, se puede mejorar su precisión al eliminar algunas alternativas de conciliación que de antemano se sabe que no son válidas. Asimismo, se podrían introducir nuevas reglas en el componente Diff Mapper que, al aportar información acerca de las convenciones de implementación, permitan una mayor precisión en la detección de nuevas responsabilidades.

92 78 CAPÍTULO 7. CONCLUSIONES Y TRABAJOS FUTUROS

93 Apéndice A Eclipse y FLABot A.1. Plataforma Eclipse Eclipse es una comunidad open-source cuyos proyectos están orientados a proveer una plataforma de desarrollo extensible y frameworks de aplicaciones para construir software. Eclipse provee herramientas y frameworks extensibles que abarcan el ciclo de vida de desarrollo de software, incluyendo soporte para modelado, entornos de desarrollo para Java, C/C++ y otros lenguajes, testing y performance, business intelligence, aplicaciones de escritorio y desarrollo embebido. Un gran ecosistema de importantes empresas de software, universidades, institutos de investigación e individuos extienden, complementan y soportan la plataforma Eclipse [17]. Uno de los beneficios claves de la plataforma Eclipse aparece a través de su uso como un punto de integración. Al construir las herramientas o aplicaciones sobre la plataforma Eclipse, se les permite integrarse con otras herramientas también escritas usando la plataforma. De esta manera, la plataforma integra las herramientas individuales en un único producto, proveyendo una experiencia rica y consistente para los usuarios. El rol principal de la plataforma es brindar a los desarrolladores un conjunto de mecanismos y reglas para conducir a la integración simple y sistemática de herramientas. Éstos mecanismos son expuestos por medio de APIs (Application Programming Intefaces), clases y métodos bien definidos. La plataforma además provee bloques de construcción y frameworks muy útiles para facilitar el desarrollo de nuevas herramientas. En la Figura A.1 se muestra un esquema de los componentes principales de la arquitectura de plug-ins de Eclipse. A.1.1. Arquitectura de Plug-ins Un plug-in es la menor unidad de función de la plataforma Eclipse que puede ser desarrollada y entregada por separado. Por lo general, una herramienta pequeña se escribe como un solo plug-in, mientras que una herramienta compleja tiene su funcionalidad repartida entre varios plug-ins. Excepto por un pequeño kernel llamado Platform Runtime, toda la funcionalidad de la plataforma es provista en forma de plug-ins. La configuración de cada plug-in se describe a través de un par de archivos. El manifiesto declara información esencial acerca del plug-in, incluyendo nombre, versión y dependencias hacia otros plug-ins. El segundo archivo, plugin.xml, declara las interconexiones del plug-in con otros plug-ins. El modelo de interconexión es simple: un plug-in declara cualquier número de puntos de extensión, y cualquier 79

94 80 APÉNDICE A. ECLIPSE Y FLABOT Figura A.1: Arquitectura de Plug-ins de Eclipse Figura A.2: Comunicación entre Plug-ins de Eclipse número de extensiones a uno o más puntos de extensión en otros plug-ins. Los puntos de extensión pueden ser extendidos por otros plug-ins. Un punto de extensión puede tener una interfaz API correspondiente. Otros plugins contribuyen implementaciones de esta interfaz por medio de extensiones de este punto de extensión. Cualquier plug-in es libre de definir nuevos puntos de extensión y de proveer una nueva API para que usen otros plug-ins. En la Figura A.2 se ilustran los roles principales para la comunicación entre plug-ins. Al iniciar, la plataforma descubre el conjunto de plug-ins disponibles, lee sus archivos de manifiesto, y construye un registro de plug-ins en memoria. Al determinar el conjunto de plug-ins al principio, y al soportar un significativo intercambio de información entre plug-ins sin tener que activar ninguno de ellos, la plataforma puede proveer a cada plug-in de una rica fuente de información pertinente acerca del contexto en el que está corriendo. La plataforma corre en una única invocación de una máquina virtual Java estándar. A cada plug-in se le es asignado su propio class loader Java, que es responsable de cargar sus clases y recursos. Cada plug-in declara explícitamente su dependencia con otros plug-ins de los que espera acceder directamente a sus clases, y controla la visibilidad frente a los plug-ins dependientes de las clases e interfaces públicas en sus librerías. Ésta información se declara en el manifiesto, y las reglas de acceso son aplicadas en tiempo de ejecución por los class loaders de los plug-ins.

95 A.2. FLABOT 81 Figura A.3: Esquema de funcionamiento de FLABot A.2. FLABot FLABot 1 es una herramienta de soporte para la localización de fallas y debugging de plug-ins de Eclipse. El tipo de soporte que provee la herramienta no se trata de encontrar puntos de error específicos en el código, sino que se enfoca en el modelo arquitectónico de un plug-in y usa esa información para aproximar las regiones de código donde los errores se originan con mayor probabilidad. El proyecto fue inspirado por el enfoque propuesto en [39]. Básicamente, éste enfoque se basa en la noción de que usar modelos arquitectónicos permite al desarrollador razonar y resolver muchos problemas de debugging en un nivel que es razonablemente manejable, inclusive para sistemas complejos [6]. En la Figura A.3 se presenta un esquema del funcionamiento de FLABot. Para alcanzar la funcionalidad propuesta, la herramienta utiliza información de mapeo responsabilidad-código para configurar un instrumentador de bytecode Java, de esta manera generando registros de las trazas de ejecución problemáticas. Éstos registros o logs son tomados por el Asistente de Localización de Fallas para realizar un análisis exploratorio de los paths de funcionalidad descriptos en la especificación arquitectónica. Éste análisis combina información de ejecución de bajo nivel contenida en los logs con feedback del usuario, para así identificar la causa de la falla en un conjunto de responsabilidades. Una vez detectadas las causas del error, el conjunto de responsabilidades problemáticas es traducido en un conjunto de breakpoints en sus correspondientes regiones de código, una vez más utilizando la información de mapeo responsabilidad-código. Finalmente, el usuario es libre de utilizar técnicas de debugging tradicionales sobre este espacio de búsqueda reducido. La funcionalidad principal de FLABot se encuentra organizada básicamente en tres módulos: Editores de Especificaciones Arquitectónicas: Este módulo posee la funcionalidad necesaria para la especificación y manipulación de modelos de componentes UML y de UCMs de manera gráfica, como se muestra en las Figuras A.4 y A.5. Los editores permiten mapear cada componente UML a un conjunto de clases Java, para luego mapear cada responsabilidad a un subconjunto de los métodos de estas clases. Estos modelos son los vehículos principales para construir la información arquitectónica que los otros dos módulos necesitan para funcionar. Ambos editores fueron implementados como plug-ins de Eclipse, por lo que se integran completamente con la plataforma y tanto los editores mismos como sus correspondientes modelos pueden ser reutilizados por cualquier otro 1 FLABot homepage:

96 82 APÉNDICE A. ECLIPSE Y FLABOT Figura A.4: Editor de componentes UML de FLABot plug-in. Asistente para Localización de Fallas: Este módulo materializa las estrategias para localización de fallas guiada por la arquitectura, de acuerdo al enfoque descripto en [39]. Debugger Especializado: Este módulo añada el soporte para debugging en sí. El debugger especializado permite relacionar la salida del asistente con estructuras de código, insertando breakpoints en las que resulten apropiadas, para luego permitir al desarrollador aplicar técnicas tradicionales de debugging sobre el código de la aplicación. Además de estos tres módulos principales, para generar los logs de ejecución FLABot implementa un módulo de instrumentación de código estructurado en forma de capas. La capa superior recibe parámetros de configuración que indican el conjunto de clases y métodos que deben ser inspeccionados, es encargada de iniciar la ejecución de la aplicación instrumentada y produce como respuesta un log con las trazas de ejecución. En las capas inferiores se implementa la infraestructura de bajo nivel para la instrumentación en sí, que hace uso de un class loader especializado para analizar y modificar el bytecode de las clases en los puntos que deben ser inspeccionados. Cuando una clase está a punto de ser cargada dentro de la máquina virtual, el bytecode se analiza para detectar si en ella se produce alguno de los eventos indicados en los parámetros de configuración. Si esto es así, se utiliza la librería Javassist [15] para insertar llamadas en los puntos inspeccionados a un mecanismo de publicación y subscripción de eventos que se encarga de generar el log. Independientemente de sus detalles de implementación, para reutilizar el instrumentador de FLABot solamente hace falta comunicarse con la capa superior. Ésto se hace a través de un punto de extensión, definido en el instrumentador, al que es posible contribuir los parámetros de configuración necesarios para indicar tanto las

97 A.2. FLABOT 83 Figura A.5: Editor de UCM de FLABot clases y métodos a inspeccionar como la ubicación donde se debe guardar el log de ejecución.

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Arquitecturas de Software

Arquitecturas de Software Arquitecturas de Software Ingeniería del Universidad Rey Juan Carlos César Javier Acuña cjacunia@escet.urjc.es Índice Introducción Motivación Definición Pipes and Filters Tipos abstractos de datos y OO

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Fundamentos del diseño de software

Fundamentos del diseño de software Fundamentos del diseño de software El diseño es el primer paso de la fase de desarrollo de cualquier producto o sistema de ingeniería. Definición de diseño según Taylor Proceso de aplicar distintas técnicas

Más detalles

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación Liberando el sistema Ayudar a los usuarios a entender y usar el sistema Distintos tipos de usuarios Entrenamiento Documentación Solución de Problemas Conversión Instalación May-12 Ing. de Software Liberación

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Módulo Profesional 01: Bases de datos (código: 0484).

Módulo Profesional 01: Bases de datos (código: 0484). Módulo Profesional 01: Bases de datos (código: 0484). Actividades de enseñanza-aprendizaje que permiten alcanzar los objetivos del módulo. Interpretar diseños lógicos de bases de datos. Realizar el diseño

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software IX Contenidos Prólogo... XIX Prefacio... XXI Guía de lectura...xxiii Parte I - Introducción Capítulo 1 - Evolución 1.1 Introducción... 2 1.2 Los hitos en la evolución histórica del desarrollo de software...

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar MODELADO DE OBJETOS Bibiana ROSSI, Paola BRITOS y Ramón GARCIA MARTINEZ, CAPIS - Centro de Actualizacion Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. 0. INTRODUCCION {brossi,pbritos,rgm}@itba.edu.ar

Más detalles

La Arquitectura de las Máquinas Virtuales.

La Arquitectura de las Máquinas Virtuales. La Arquitectura de las Máquinas Virtuales. La virtualización se ha convertido en una importante herramienta en el diseño de sistemas de computación, las máquinas virtuales (VMs) son usadas en varias subdiciplinas,

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

Memoria Compartida Distribuida (DSM) Sistema de Archivos

Memoria Compartida Distribuida (DSM) Sistema de Archivos Memoria Compartida Distribuida (DSM) La memoria compartida distribuida es una abstracción que se propone como alternativa a la comunicación por mensajes. Memoria compartida basada en páginas: este esquema

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

Patrones de software y refactorización de código

Patrones de software y refactorización de código Patrones de software y refactorización de código Introducción y antecedentes de los patrones de software Los patrones permiten construir sobre la experiencia colectiva de ingenieros de software habilidosos.

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

BASES DE DATOS. 1.1 Funciones de un DBMS

BASES DE DATOS. 1.1 Funciones de un DBMS BASES DE DATOS Un DBMS, son programas denominados Sistemas Gestores de Base de Datos, abreviado SGBD, en inglés Data Base Management System (DBMS) que permiten almacenar y posteriormente acceder a los

Más detalles

Tema 3: Bases de datos en Entorno Web

Tema 3: Bases de datos en Entorno Web Tema 3: Bases de datos en Entorno Web 1. Introducción. Un sistema de bases de datos proporciona un control centralizado de los datos. Esto contrasta con la situación que prevalece actualmente, donde a

Más detalles

DISEÑO DE COMPONENTES DE SOFTWARE *

DISEÑO DE COMPONENTES DE SOFTWARE * DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP * Resumen del capítulo 10 de libro de [Pressman 2010] V:18-11-2008 (c) P. Gomez-Gil, INAOE.

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa.

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. BASES DE DATOS Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. La creación de una base de datos debe ser realizada cuidadosamente procurando

Más detalles

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos Tema 13 Metodologías en el desarrollo de Sistemas de Software Prof. Oscar Adolfo Vallejos Desarrollo de Sistemas de Software Objetivo Conceptos en el contexto más amplio de Software e Ingeniería de Software

Más detalles

Administración de Variabilidad en una línea de producto basada en modelos

Administración de Variabilidad en una línea de producto basada en modelos Administración de Variabilidad en una línea de producto basada en modelos Kelly Garcés Carlos Parra Hugo Arboleda Andres Yie Rubby Casallas Universidad de los Andes, Bogotá k-garces @uniandes.edu.co Universidad

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

Introducción a los Tipos Abstractos de Datos

Introducción a los Tipos Abstractos de Datos Página 1 de 8 Introducción a los Tipos Abstractos de Datos Introducción: Concepto de abstracción Abstracción funcional y abstracción de datos Construcción de tipos abstractos de datos Especificación de

Más detalles

Capítulo III. Análisis y diseño.

Capítulo III. Análisis y diseño. Capítulo III. Análisis y diseño. 3.1 Análisis. El análisis es el intermediario entre los requisitos del sistema y el diseño, esta sección definiremos el análisis con una serie de modelos técnicos del sistema,

Más detalles

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS 4.1 Diferencias entre análisis y diseño La división entre el análisis y diseño es poco clara, el trabajo de los dos se mezcla continuamente

Más detalles

CAPÍTULO 5. Hemos utilizado la técnica de programación orientado a objetos por su

CAPÍTULO 5. Hemos utilizado la técnica de programación orientado a objetos por su 88 CAPÍTULO 5 5. IMPLEMENTACIÓN 5.1 Modelo Utilizado en Programación. Hemos utilizado la técnica de programación orientado a objetos por su eficiencia y eficacia en el modelo mvc, ya que permite la reutilización

Más detalles

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 18 CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC297_2 Versión 5 Situación RD 1201/2007 Actualización

Más detalles

MODELADO DE OBJETOS DE DATOS

MODELADO DE OBJETOS DE DATOS Manual Página Web MODELADO DE OBJETOS DE DATOS MANUALES ESPECIALES Documento: Manual Páginas Web (SemanticWebBuilder). Fecha de Elaboración: Marzo de 2009. INFOTEC CONACYT FIDEICOMISO. Página i Glosario

Más detalles

Trabajo de Investigación

Trabajo de Investigación Escuela Técnica Superior de Ingeniería Informática Departamento: Ingeniería de Software y Sistemas Informáticos Trabajo de Investigación Arquitecturas Software: Gestión de los atributos de calidad de un

Más detalles

Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos

Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos 1. Introducción Curso académico 2009-2010 La práctica de Integración de Sistemas consiste en el diseño

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables.

Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables. Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables. Para obtener el grado de Maestro en Ciencias (Ciencias y Tecnologías de la Información) P R E S E N T A Lic.

Más detalles

2.1 Ingeniería de Software

2.1 Ingeniería de Software Capítulo 2 Marco Teórico Se pretende desarrollar un software que pueda ser aplicado como una herramienta útil para la administración de una empresa. Es necesario tener en cuenta que, en todo desarrollo

Más detalles

SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS

SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS Universidad de Carabobo Facultad Experimental de Ciencias y Tecnología Departamento de Computación Unidad Académica Base de Datos SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS Integrantes: Fidel Gil

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

Acoplamiento e interoperabilidad

Acoplamiento e interoperabilidad Máster Universitario en Ingeniería Informá3ca Acoplamiento e interoperabilidad Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA 2 Acoplamiento débil Tipos de acoplamiento Cabalgando el

Más detalles

PATRONES. Experto. Solución:

PATRONES. Experto. Solución: PATRONES. Experto. Asignar una responsabilidad a la clase que tiene la información necesaria para cumplirla. Cuál es el principio fundamental en virtud del cual asignaremos las responsabilidades a los

Más detalles

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción Dato: Hecho o valor a partir del cual se puede inferir una conclusión.

Más detalles

Enterprise Analyst: Taller de Bautizo

Enterprise Analyst: Taller de Bautizo Enterprise Analyst: Taller de Bautizo Metas Entender la Necesidad de Ejecutar los Modelos Desarrollar un caso usando UML tradicional Identificar los problemas de UML Conocer la Herramienta Enterprise Analyst

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Tabla de Contenidos PARTE I INTRODUCCIÓN Capítulo 1: Evolución Los hitos en la evolución histórica del Desarrollo de Software Problemas y soluciones... Fallas, malas estimaciones

Más detalles

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Interoperabilidad. Conferencia: Presente y futuro de las SMART GRIDS en México. Ing. Alfredo Espinosa Reza aer@iie.org.mx

Interoperabilidad. Conferencia: Presente y futuro de las SMART GRIDS en México. Ing. Alfredo Espinosa Reza aer@iie.org.mx Interoperabilidad Conferencia: Presente y futuro de las SMART GRIDS en México Ing. Alfredo Espinosa Reza aer@iie.org.mx 29 de Octubre de 2013 Contenido Introducción. Estrategias para modelado y acceso

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S4 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

Mejores prácticas para la evaluación dinámica

Mejores prácticas para la evaluación dinámica Mejores prácticas para la evaluación dinámica Disclaimer This document is a translation of the English-language AMTSO document Best Practices for Dynamic Testing (version 2008-10-31) at http://www.amtso.org/documents/doc_download/7-amtso-best-practices-for-dynamictesting.html.

Más detalles

Simulador de Protocolos de Red a tráves de WEB

Simulador de Protocolos de Red a tráves de WEB Simulador de Protocolos de Red a tráves de WEB Propuesta de Estudio 20071608 Director Ing. Francisco Antonio Polanco Montelongo Resumen Introducción Actualmente, el desarrollo tecnológico a alcanzado niveles

Más detalles

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO.

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. 0. Consideraciones iniciales. Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Por esta razón,

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Fundamentos de Redes LI. Unidad III Modelos de Comunicaciones 3.1 Modelo de referencia OSI.

Fundamentos de Redes LI. Unidad III Modelos de Comunicaciones 3.1 Modelo de referencia OSI. 3.1 Modelo de referencia OSI. Durante las últimas dos décadas ha habido un enorme crecimiento en la cantidad y tamaño de las redes. Muchas de ellas sin embargo, se desarrollaron utilizando implementaciones

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción El WWW es la mayor fuente de imágenes que día a día se va incrementando. Según una encuesta realizada por el Centro de Bibliotecas de Cómputo en Línea (OCLC) en Enero de 2005,

Más detalles

Capítulo 1. Introducción. 1.1. Antecedentes

Capítulo 1. Introducción. 1.1. Antecedentes Capítulo 1. Introducción En este capítulo se presenta una descripción general del problema a investigar y el enfoque con el que se aborda. Se establece la necesidad de incorporar técnicas de análisis novedosas

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

TEMA 1: INTRODUCCIÓN

TEMA 1: INTRODUCCIÓN 1 DISEÑO Y DESARROLLO DE COMPILADORES TEMA 1: INTRODUCCIÓN Qué es un Compilador? Un compilador no es más que un traductor, es decir, un programa que nos permite pasar información de un lenguaje a otro.

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

Procesos de Negocios

Procesos de Negocios Procesos de Negocios Procesos de negocios Como dijimos en el Tema 1: los sistemas de información y las organizaciones se influyen entre sí: Los SI deben proveer la información que la organización necesita.

Más detalles

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

BPMN BPMN BPMN. BPD Objetos de flujo - Actividades. BPD (Business Process Diagram) Notación de modelado de procesos de negocio BPD

BPMN BPMN BPMN. BPD Objetos de flujo - Actividades. BPD (Business Process Diagram) Notación de modelado de procesos de negocio BPD BPMN Notación de modelado de procesos de negocio BPMN Fue desarrollado por la BPMI (Business Process Management Initiative) Objetivos: Proveer una notación entendible para cualquiera desde el analista

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012 TFC J2EE Aplicación Web para la gestión de facturación de una empresa de cerrajería Sara Gutiérrez Melero ITIG Junio de 2012 Consultor: Jose Juan Rodriguez Índice 1. Introducción Objetivos Planificación

Más detalles

Documentando la arquitectura de software Principios básicos por Omar Gómez

Documentando la arquitectura de software Principios básicos por Omar Gómez Documentando la arquitectura de software Principios básicos por Omar Gómez En la actualidad, uno de los temas candentes que se habla dentro de la comunidad de desarrollo de software es el referente a las

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes. Definiciones

Más detalles

Antes de imprimir este documento piense en el medio ambiente!

Antes de imprimir este documento piense en el medio ambiente! Versión 1.0 Página 1 de 14 1. OBJETIVO: Suministrar la metodología que se aplicará para la estimación de esfuerzo para los desarrollos nuevos en el ICBF, para lo cual se detallan los aspectos a tener en

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

Más detalles

Unidad II. - Las técnicas en las que se basó, las categorías de análisis o ejes centrales que permiten guiar el proceso de investigación.

Unidad II. - Las técnicas en las que se basó, las categorías de análisis o ejes centrales que permiten guiar el proceso de investigación. Unidad II Metodología de Solución de Problemas 2.1 Descripción del problema (enunciado). Este aspecto nos indica describir de manera objetiva la realidad del problema que se esta investigando. En la descripción

Más detalles

TABLA DE CONTENIDO 1. REQUERIMIENTOS NO FUNCIONALES... 2

TABLA DE CONTENIDO 1. REQUERIMIENTOS NO FUNCIONALES... 2 TABLA DE CONTENIDO Pág. 1. REQUERIMIENTOS NO FUNCIONALES... 2 1.1 ATRIBUTOS DE CALIDAD DEL SISTEMA... 2 1.2 OTROS REQUERIMIENTOS NO FUNCIONALES... 4 1.3 REQUERIMIENTOS NO FUNCIONALES PARA HERRAMIENTAS

Más detalles

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

Análisis de Requisitos

Análisis de Requisitos Análisis de Requisitos Los requisitos determinan lo que hará el sistema y definen restricciones sobre su operación e implementación. El análisis de requisitos es el proceso del estudio de las necesidades

Más detalles

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

6.6 DISEÑO. [Proceso]

6.6 DISEÑO. [Proceso] 6.6 DISEÑO. [Proceso] Durante un Ciclo de Desarrollo iterativo es posible pasar a la Fase de Diseño una vez completada la documentación de la fase de Análisis. Durante esta etapa se desarrolla una solución

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES

BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES El modelo relacional se basa en dos ramas de las matemáticas: la teoría de conjuntos y la lógica de predicados de primer orden. El hecho de que

Más detalles

Estilos y Patrones Arquitectónicos

Estilos y Patrones Arquitectónicos Lic. Ariel Trellini Estilos y Patrones Arquitectónicos Llamando a las cosas por su nombre Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Arquitectura y Diseño de Sistemas

Más detalles

Brindar al alumno un marco teórico y práctico para el desarrollo de software bajo estándares de calidad.

Brindar al alumno un marco teórico y práctico para el desarrollo de software bajo estándares de calidad. Universidad Católica San Pablo Facultad de Ingeniería y Computación Programa Profesional de Ciencia de la Computación SILABO CS290T. Ingeniería de Software I (Obligatorio) 2012-2 1. DATOS GENERALES 1.1

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: ARQUITECTURA DEL SISTEMA DE SOFTWARE NIVELES DE DISEÑO DE LOS SISTEMAS DE SOFTWARE CUALIDADES DE LAS ARQUITECTURAS ESTILOS Y PATRONES - ESTILOS ARQUITECTÓNICO - PATRÓN ARQUITECTÓNICO FRAMEWORK

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

Estilos de Arquitectura y. Patrones de Diseño Arquitectónico. Patrones de Arquitectura

Estilos de Arquitectura y. Patrones de Diseño Arquitectónico. Patrones de Arquitectura Estilos de Arquitectura y Patrones de Diseño Arquitectónico Gastón Mousqués - AR 1 Patrones de Arquitectura Gastón Mousqués - AR 2 Principales Categorías de Patrones (Software) Patrones de Análisis Expresan

Más detalles

Tema 1. Arquitectura Cliente/Servidor

Tema 1. Arquitectura Cliente/Servidor Tema 1. Arquitectura Cliente/Servidor SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs 27 de septiembre de 2009 FJRP, FMBR [sistemas cliente-servidor] CCIA 1.1 Sistemas

Más detalles

Historia de revisiones

Historia de revisiones Proyecto Help-Desk Plan de Verificación y Validación Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 16/08/2005 1.0 Primera versión del documento Martín Boero Plan de Verificación y

Más detalles