Arquitectura de software dirigida por modelos (Model-Driven Architecture)

1. Arquitectura de software dirigida por modelos(Model-Driven Architecture) Liliana Favre UNCPBA 2006

2. Los ejemplos y gráficas son de : Tonella, P. Potrich, A. Reverse Engineering of Object-Oriented Code, Springer, 2005

3. Ingeniería inversa(reverse engineering) Ingeniería inversa estática + Ingeniería inversa dinámica Análisis estático Describe la estructura del software a partir del código (texto) Análisis dinámico Describe el comportamiento en ejecución del software. Extraer información en código OO es difícil (o imposible?) • Naturaleza dinámica de los lenguajes OO • Creación de objetos, garbage collector, dynamic binding,…

4. Ingeniería inversa estática OFG: representación básica para el análisis estático. Permite seguir el flujo de información de objetos desde su creación, a través de asignaciones a variables, su uso en invocaciones de métodos, almacenamiento en atributos de una clase,... El tipo de información que se propaga en el OFG depende del objetivo del análisis en el que se use. • Un lenguaje abstracto • Un algoritmo de propagación de flujo que es genérico en el tipo de información procesada

5. Ingeniería inversa estática Análisis estático sobre JAVA • Sensible al flujo de datos • Insensible al flujo de control • Representación por grafos de flujos de objetos basada en una versión abstracta, simplificada de JAVA que omite sentencias de control (condicionales, iteraciones, etc) • Evita conflictos de nombres (los identificadores son precedidos por un punto separados por la lista de packages, clases y métodos que los incluyen)

6. OFGLenguaje abstracto

7. OFGLenguaje abstracto

8. EjemploLenguaje abstracto-Sentencias 60-62 Library.borrowDocument.loan = new Loan(Library.borrowDocunent.user, Library.borrowDocument.doc); Library.borrowDocument.this. Library. addLoan(library.borrowDocument.loan)

9. EjemploLenguaje abstracto-Sentencias 42 Library.addLoan.user=Loan.getUser.return 43 Library.addLoan.doc = Loan.getDocument.return;

10. Generación del OFG OFG = (N, E) N: conjunto de nodos E: conjunto de arcos Para cada variable local, atributo o parámetro formal, se agrega un nodo a OFG. Por ejemplo, el OFG de la clase Library de eLib contiene: • Un nodo asociado al atributo loan rotulado Library.loans • Dos rótulos asociados con los parámetros formales del método borrowDocument rotulados Library.borrowDocument.user Library.borrowDocument.doc • La variable localloanasociada con el nodo rotulado Library.borrowDocument.loan • El objeto currenten BorrowDocumentestá asociado con un nodo rotulado Library.borrowDocument.this

11. Generación del OFG Los arcos se insertan de acuerdo a las siguientes reglas

12. Algoritmo Data-Flowforward

13. Desde JAVA a diagramas de interacción

14. Extracción de diagramas de interacción Se contemplan dos formas de diagramas de interacción: diagramas de colaboración y diagramas de secuencia. Un diagrama de secuencia muestra los objetos y actores que participan en una colaboración poniendo el énfasis en el ordenamiento en el tiempo de los mensajes. Un diagrama de colaboración pone el énfasis en la organización estructural de los objetos o roles que envían y reciben mensajes Los diagramas de interacción pueden obtenerse mediante un análisis estático que provee un superset conservativo de todas las posibles interacciones combinado con un análisis dinámico que provee una traza del comportamiento del programa durante una específica ejecución.

15. Extracción de diagramas de interacción Se contemplan dos formas de diagramas de interacción: diagramas de colaboración y diagramas de secuencia. Un diagrama de secuencia muestra los objetos y actores que participan en una colaboración poniendo el énfasis en el ordenamiento en el tiempo de los mensajes. Un diagrama de colaboración pone el énfasis en la organización estructural de los objetos que envían y reciben mensajes Los diagramas de interacción pueden obtenerse mediante un análisis estático que provee un superset conservativo de todas las posibles interacciones combinado con un análisis dinámico que provee una traza del comportamiento del programa durante una específica ejecución.

16. Extracción de diagramas de interacción La extracción de las interacciones entre objetos se realiza en dos pasos: • Primero, se infieren desde el código los objetos creados en el programa y accedidos a través de variables. • Luego, cada invocación a un método se resuelve en términos de posibles objetos source y target involucrados en intercambios de mensajes.

17. Extracción de diagramas de interacción Especialización del data-flow para determinar el conjunto de objetos asignados en el programa Cada punto de asignación de objetos en el programa se asocia a un identificador ci, donde c es el nombre de la clase. La propagación de los identificadores en el OFG permite asociar a cada variable con el conjunto de objetos que puede referenciar.

18. Especialización de data-flow

19. Algoritmo para la resolución estática de una invocación a un método

20. Algoritmo para la resolución estática de una invocación a un método • Si una cadena de accesos a atributos precede a la invocación a un método, como por ejemplo p.q.g(), el target se obtiene desde el último atributo involucrado out[B.q], donde B es la clase del atributo q, que se accede a través de p. • Si una invocación a otro método precede a otra, por ejemplo p. f().g(), return puede ser usador para determinar los targets de la invocación out[B.f.return]

21. EjemploOFG-Resolución de invocaciones

22. EjemploEl método addLoan

23. EjemploOFG-Resolución de invocaciones Library1

24. EjemploOFG-Resolución de invocaciones

25. EjemploEl método addLoan

26. EjemploDiagrama de secuencia

27. EjemploDiagrama de colaboración

28. Resolución de invocaciones parasistemas incompletos

29. Ejemplo-Resolución de invocacionesDiagrama de secuencia

30. Ejemplo-Resolución de invocacionesDiagrama de secuencia

31. Resolución de invocaciones parasistemas incompletos Supongamos que excluimos la clase Main. Cuando addLoan de la clase Library es analizado, el objeto fuente de las 4 invocaciones en 42,43,45,46 no es conocido. Para las 2 primeras llamadas es posible determinar el objeto target, Loan1, el objeto asignado en la línea 60, sin embargo esto no es posible para las otras dos llamadas. Los conjuntos target para 45 y 46 son vacíos (ningún objeto de las clases User o Document). Se introduce Library*,como objeto genérico fuente de las 4 invocaciones. User* y Document* se introducen para las invocaciones en 45 y 46.

32. Resolución de invocaciones parasistemas incompletos

33. Extracción de diagramas de interacción- Filtrado Para grandes sistemas el algoritmo puede aplicarse filtrando información relevante de dos maneras: • Resolviendo sólo las llamadas distribuidas desde el método de interés • Incluyendo sólo las clases interesantes en un sistema incompleto.

34. Extracción de diagramas de interacción-Filtrado Las invocaciones en diagramas de colaboración puede ser numerada de acuerdo a la notación de Dewey. Esta numeración puede ser utilizada para inducir orden temporal en diagramas de secuencia. Numeracón de invocaciones

35. Extracción de diagramas de interacción

36. Extracción de diagramas de interacción

37. Análisis dinámico Herramientas específicas -Soluciones ad-hoc que incluyan: • Identificadores de objetos, que serán calculados e incorporados a la traza de ejecución durante la ejecución de constructores • Ante una invocación a un método, agregar a la traza los identificadores del objeto actual y el target.Además incluir el nombre del método actual los objetos referenciados por el atributo • Generar marcas de tiempo cuando ocurren invocaciones.

38. Análisis diámico • Un procesamiento de la traza de ejecución provee un diagrama de interacción para cada test ejecutado. • Cada vez que se detecta una invocación en la traza, se dibuja una llamada en el diagram de interacción entre los objetos identificados en la traza. • El orden de los eventos se induce de las marcas de tiempo. • Produce un conjunto de diagramas de interacción, uno para cada test. • Depende de la calidad de los test

39. Extracción de diagramas de interacción- Análisis dinámico Un libro previamente prestado a un usuario normal de la biblioteca es devuelto y el préstamo cerrado.

40. Extracción de diagramas de interacción- Análisis dinámico Devolución de un libro disponible para préstamos

41. Desde JAVA a diagramas de estado

42. Diagramas de estado Describe el comportamiento que muestra un objeto de una clase. Es un autómata que consiste de estados, transiciones, eventos y actividades. La ingeniería reversa de diagramas de estado no puede ser totalmente automatizada. El primer paso para recuperar un diagrama de estado para una clase consiste en definir un dominio abstracto apropiado para sus atributos y ( posiblemente ) para las variables involucradas en las computaciones de atributos. Luego, la interpretación de los métodos de clase da las transiciones de estado a estado a ser representadas en el diagrama de estados.

43. Diagramas de estado

44. Ejemplo- Diagrama de estado. Clase Document

45. Ejemplo- Diagrama de estado. Clase Document

46. Ejemplo- Diagrama de estado. Clase User

47. Ejemplo- Diagramas de estado proyectados para Library

48. Ejemplo-Diagrama de estado combinado para Library

49. Otras propuestas Systa, Tarja. Static and Dynamic Reverse Engineering for Java Software Systems. Ph. D. University Tempere, Finland, 2000 Distingue ingeniería inversa estática y dinámica. La información estática consiste de artefactos y relaciones. La información dinámica contiene además de artefactos, información de trazas de eventos secuenciales, sobre concurrencia, administración de memoria, etc. La información estática se extrae del código y es vista en el entorno para ingeniería inversa RIGI. La información dinámica es generada ejecutando el software bajo un debugger y es vista como un diagrama de escenarios usando la herramienta SCED. Esta permite sintetizar diagramas de estado desde escenarios, pudiendo examinar el comportamiento de un objeto o método desconectado del resto del sistema.