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

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

2. Técnicas de reingeniería y MDA

3. Bibliografía Las gráficas fueron extraídas de 1. Demeyer, S.; Ducasse, S.; Nierstrasz, O. Object-Oriented Reengineering Patterns, Morgan-Kaufmann Publishers, 2002 2. Systa, Tarja. Static and Dynamic Reverse Engineering for Java Software Systems. Ph. D. University Tempere, Finland, 2000 3. Tonella, P. Potrich, A. Reverse Engineering of Object-Oriented Code, Springer, 2005

4. Ingeniería directa, inversa y reingenieía

5. Ingeniería directa, inversa y reingeniería Ingeniería directa Es el proceso que transforma diseños en un alto nivel de abstracción a la implementación de un sistema. Ingeniería inversa Es el proceso que analiza un sistema para identificar sus componentes y sus interrelaciones y crea representaciones del sistema en otra forma o en un mayor nivel de abstracción. Reingeniería Es el proceso que transforma una representación de bajo nivel en otra, mientras reconstituye artefactos de mayor nivel de abstracción a lo largo del proceso. Es decir, transforma implementaciones concretas en otras concretas transformando al sistema en todos sus niveles.

6. Otras definiciones relacionadas a reingenieía Reestructuración Es el proceso de transformar una representación en otra en el mismo nivel de abstracción, preservando el comportamiento externo del sistema. Refactoring Es el proceso de reestructuración en un contexto orientado a objetos Mantenimiento El proceso de modificación de un producto de software para corregir fallas, mejorar la performance o adaptarlo a un cambio de entorno.

7. Otras definiciones relacionadas a reingeniería Evolución de software La evolución de software se caracteriza por la existencia de un código del sistema y la actividad típica es la implementación de un cambio que puede ser requerido para: • corregir el software ( mantenimiento correctivo) • agregar funcionalidad ( mantenimiento perfectivo) • adaptarlo a un cambio de ambiente ( mantenimiento adaptativo) • reestructurarlo para facilitar su futuro mantenimiento ( mantenimento preventivo) Durante la evolución, la descripción más precisa y confiable del software es su código.

8. Ingeniería inversa

9. Ingeniería inversa(reverse engineering) • Las técnicas de ingeniería inversa permiten analizar y representar software en una forma abstracta a fin de facilitar mantenimiento, reingeniería, reusabilidad y documentación. • Proveen una manera de extraer vistas de alto nivel desde el código sistema, que resumen aspectos relevantes de la computación ejecutada por las sentencias del programa. Chikofsky y Cross(*) definen a la ingeniería inversa como el proceso de analizar un sistema target con dos objetivos: • Identificar los componentes del sistema y sus interrelaciones • Crear representaciones del sistema en otra forma o en un mayor nivel de abstracción * Reverse Engineering and design Recovery: A taxonomy. IEEE Software, January 1990

10. 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,…

11. Ingeniería inversa Inconvenientes • La única fuente confiable es el código que está poco (o nada) documentado y se ha perdido contacto con los diseñadores y/o programadores. • Las herramientas CASE proveen buen soporte para análisis estático pero limitado para análisis dinámico.

12. Ingeniería inversa de programas OO

13. Ingeniería inversa de código OOInconvenientes Por ejemplo, las construcciones JAVA no se alinean con UML: Generalización/ especialización Agregación/composición Asociaciones Cuerpo de los métodos … UML JAVA

14. Propuesta de : Tonella, P. Potrich, A. Reverse Engineering of Object-Oriented Code. Springer, 2005 Describe ingeniería inversa de diagramas UML de clases, objetos, interacción, estados y paquetes. Propone especializaciones de algoritmos de data-flow basados en una estructura llamada OFG (Object Flow Graph).

15. Arquitectura general de una herramienta de ingeniería inversa

16. Ejemplo de modelo del lenguaje para JAVA simplificado

17. 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

18. 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)

19. Ingeniería inversa estática ¿Porqué el análisis es sensible al flujo de datos/ insensible al flujo de control? • Complejidad computacional • Naturaleza de LOO • Puede automatizarse

20. OFGLenguaje abstracto

21. OFGLenguaje abstracto

22. OFGLenguaje abstracto return y this

23. EjemploeLib- Diagrama de clases

24. EjemploLenguaje abstracto-Declaraciones Library.Library() Declaración de constructor implícito Library.loans Declaración de atributo loans

25. EjemploLenguaje abstracto-Declaraciones Library.borrowDocument(Library.borrowDocument.user, Library.borrowDocument.doc) Declaración de método

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

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

28. 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

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

30. Generación del OFG Library.borrowDocument.loan = new Loan(Library.borrowDocument.user, Library.borrowDocument.doc) Library.borrowDocument.this.Library.addLoan (Library.borrowDocument.loan) genera los siguientes arcos:

31. Generación del OFG x = y {(y,x) є E} genera los siguientes arcos

32. Generación del OFGContainers Si una función de librería introduce un flujo de dato de una variable x a otra y, debería incluirse el arco (x,y) • Clases que implementan la interfaz Collection (vector, linkedList, HashSet, TreeSet,..) • Clases que interpretan la interfaz Map (Hashtable, HashMap, TreeMap,…) Los dos casos básicos (1) c.insert(x) (x,c) є E (2) x = c.extract() (c,x) є E Los mismos arcos son los que serían introducidos en el OFG en presencia de las siguientes asignaciones (1) c = x (2) x = c

33. Generación del OFGContainers Library.loans = Library.addLoan.loan

34. Generación del OFGContainers Library.printAllLoans.i = Library.loans - el flujo desde el container(loans) al iterador i Libray.printAllLoans.loan =Library.printAllLoans.i; - El acceso al objeto contenido ( invocación de next) y la asignación a la variable local loan

35. Generación del OFGContainers

36. Generación del OFGContainers - Un objeto user es insertado en el container users Library.users = Library.addUser.user - Un objeto user es extraído del container users Library.getUser.return = Library.users

37. Algoritmo Data-Flowforward

38. Algoritmo Data-Flow forward La solución provista por el algoritmo es conservativa(segura), ningún flujo de datos que no esté contemplado ocurre. Sin embargo, es imposible decidir estáticamente si un camino es factible o no. Análisis insensible a objetos

39. OFG para análisis “sensible” a objetos En un análisis sensible a objetos los atributos de clase no estáticos y los métodos(incluyendo sus parámetros y variables locales) se replican para cada objeto identificado estáticamente. Para cada punto de asignación, se crea un identificador de objeto y todos los atributos y métodos en la clase son replicados. Construcción es más complicada ( se analizará más adelante)

40. OFG“Sensible” a objetos Asumiendo que dos objetos son creados Loan1 y Loan2

41. OFG“Sensible” a objetos Parte de código dentro del método main de la clase Main 5 objetos son asignados en el fragmento de código: User1, Document1, Loan1, Document2, Loan2

42. OFGData-flow Insensible a objetos

43. OFGData-Flow Sensible a objetos

44. OFGData-Flow

45. OFGData-Flow

46. OFGData-Flow

47. OFGData-Flow

48. OFGData-Flow

49. OFGData-Flow

50. Desde JAVA a diagramas de clases