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

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.borrowDocumen
t.this. Library. addLoan(library.borrowDocument.l
oan)
9
EjemploLenguaje abstracto-Sentencias
42 Library.addLoan.userLoan.getUser.return 43 Lib
rary.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 local loan asociada con el nodo
  rotulado
• Library.borrowDocument.loan
• El objeto current en BorrowDocument está 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
• outB.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
  outB.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.