Arquitectura de programming dirigida por modelos Model-Driven Architecture

0
0
1524 days ago, 589 views
PowerPoint PPT Presentation

Presentation Transcript

Slide 1

Arquitectura de programming dirigida por modelos (Model-Driven Architecture) Liliana Favre UNCPBA 2006

Slide 2

Técnicas de reingeniería y MDA

Slide 3

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

Slide 4

Ingeniería directa, inversa y reingenieía

Slide 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 chairman nivel de abstracción. Reingeniería Es el proceso que transforma una representación de bajo nivel en otra, mientras reconstituye artefactos de leader nivel de abstracción a lo largo del proceso. Es decir, transforma implementaciones concretas en otras concretas transformando al sistema en todos sus niveles.

Slide 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 an objetos Mantenimiento El proceso de modificación de un producto de programming para corregir fallas, mejorar la execution o adaptarlo an un cambio de entorno.

Slide 7

Otras definiciones relacionadas a reingeniería Evolución de programming La evolución de programming 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 programming ( mantenimiento correctivo ) agregar funcionalidad ( mantenimiento perfectivo ) adaptarlo an 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 programming es su código.

Slide 8

Ingeniería inversa

Slide 9

Ingeniería inversa (figuring out) Las técnicas de ingeniería inversa permiten analizar y representar programming en una forma abstracta a blade 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 chairman nivel de abstracción * Reverse Engineering and outline Recovery: A scientific categorization. IEEE Software, January 1990

Slide 10

Ingeniería inversa (figuring out) Ingeniería inversa estática + Ingeniería inversa dinámica Análisis estático Describe la estructura del programming a partir del código (texto) Análisis dinámico Describe el comportamiento en ejecución del programming. Extraer información en código OO es difícil (o imposible?) Naturaleza dinámica de los lenguajes OO Creación de objetos, junk jockey, dynamic authoritative,…

Slide 11

Ingeniería inversa Inconvenientes La única fuente confiable es el código que está poco (o nothing) 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.

Slide 12

Ingeniería inversa de programas OO

Slide 13

Ingeniería inversa de código OO Inconvenientes 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

Slide 14

Propuesta de : Tonella, P. Potrich, A. Figuring out 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 information stream basados en una estructura llamada OFG (Object Flow Graph).

Slide 15

Arquitectura general de una herramienta de ingeniería inversa

Slide 16

Ejemplo de modelo del lenguaje para JAVA simplificado

Slide 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 factors, 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 utilize. Un lenguaje abstracto Un algoritmo de propagación de flujo que es genérico en el tipo de información procesada

Slide 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, and so forth) Evita conflictos de nombres (los identificadores child precedidos por un punto separados por la lista de bundles, clases y métodos que los incluyen)

Slide 19

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

Slide 20

OFG Lenguaje abstracto

Slide 21

OFG Lenguaje abstracto

Slide 22

OFG Lenguaje abstracto return y this

Slide 23

Ejemplo eLib-Diagrama de clases

Slide 24

Ejemplo Lenguaje abstracto-Declaraciones Library.Library() Declaración de constructor implícito Library.loans Declaración de atributo credits

Slide 25

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

Slide 26

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

Slide 27

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

Slide 28

Generación del OFG = (N, E) N: conjunto de nodos E: conjunto de arcos Para cada variable neighborhood, atributo o parámetro formal, se agrega un nodo an OFG. Por ejemplo, el OFG de la clase Library de eLib contiene: Un nodo asociado al atributo credit 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 neighborhood advance asociada con el nodo rotulado Library.borrowDocument.loan El objeto current en BorrowDocument está asociado con un nodo rotulado Library.borrowDocument.this

Slide 29

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

Slide 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:

Slide 31

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

Slide 32

Generación del OFG Containers Si una función de librería present un flujo de dato de una variable x an 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 child los que serían introducidos en el OFG en presencia de las siguientes asignaciones (1) c = x (2) x = c

Slide 33

Generación del OFG Containers Library.loans = Library.addLoan.loan

Slide 34

Generación del OFG Containers 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 nearby advance

Slide 35

Generación del OFG Containers

Slide 36

Generación del OFG Containers - Un objeto client es insertado en el holder clients Library.users = Library.addUser.user - Un objeto client es extraído del compartment clients Library.getUser.return = Library.users

Slide 37

Algoritmo Data-Flow forward

Slide 38

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

Slide 39

OFG para análisis "sensible" an objetos En un análisis sensible an objetos los atributos de clase no estáticos y los métodos(incluyendo sus parámetros y factors regions) 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 child replicados. Construcción es más complicada ( se analizará más adelante)

Slide 40

OFG "Sensible" an objetos Asumiendo que dos objetos child creados Loan1 y Loan2

Slide 41

OFG "Sensible" an objetos Parte de código dentro del método fundamental de la clase Main 5 objetos child asignados en el fragmento de código: Us

SPONSORS