Title: Arquitectura de software dirigida por modelos (Model-Driven Architecture)
1Arquitectura de software dirigida por
modelos(Model-Driven Architecture)
- Liliana Favre
- UNCPBA
- 2006
2- Técnicas de reingeniería y MDA
3Bibliografí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
4Ingeniería directa, inversa y reingenieía
5Ingenierí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.
6Otras 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.
7Otras 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 9Ingenierí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
10Ingenierí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,
11Ingenierí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
-
13Ingenierí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).
15Arquitectura general de una herramienta de
ingeniería inversa
16Ejemplo de modelo del lenguaje para JAVA
simplificado
17Ingenierí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
18Ingenierí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)
19Ingenierí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
20OFGLenguaje abstracto
21OFGLenguaje abstracto
22OFGLenguaje abstracto
return y this
23EjemploeLib- Diagrama de clases
24EjemploLenguaje abstracto-Declaraciones
Library.Library() Declaración de
constructor implícito
Library.loans Declaración de atributo loans
25EjemploLenguaje abstracto-Declaraciones
Library.borrowDocument(Library.borrowDocument.user
,
Library.borrowDocument.doc) Declaración de método
26EjemploLenguaje 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)
27EjemploLenguaje abstracto-Sentencias
42 Library.addLoan.userLoan.getUser.return 43 Lib
rary.addLoan.doc Loan.getDocument.return
28Generació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
29Generación del OFG
Los arcos se insertan de acuerdo a las siguientes
reglas
30Generación del OFG
Library.borrowDocument.loan new
Loan(Library.borrowDocument.user,
Library.borrowDocument.doc) Library.borrow
Document.this.Library.addLoan (Library.borrowDocum
ent.loan) genera los siguientes arcos
31Generación del OFG
genera los siguientes arcos
32Generació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
33Generación del OFGContainers
Library.loans Library.addLoan.loan
34Generació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
35Generación del OFGContainers
36Generació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
37Algoritmo Data-Flowforward
38Algoritmo 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
39OFG 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)
40OFGSensible a objetos
Asumiendo que dos objetos son creados Loan1 y
Loan2
41OFGSensible 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
42OFGData-flow
Insensible a objetos
43OFGData-Flow
Sensible a objetos
44OFGData-Flow
45OFGData-Flow
46OFGData-Flow
47OFGData-Flow
48OFGData-Flow
49OFGData-Flow
50- Desde JAVA a diagramas de clases
51Desde JAVA a diagramas de clase
- Los diagramas de clase resumen importantes
decisiones de - diseño sobre la organización del sistema.
- Elementos de un diagrama de clases
- Clases
- Interfaz, clases abstractas, clases
parametrizadas - Relaciones de dependencia, generalización y
asociación - Especificaciones OCL
52Desde JAVA a diagramas de clase
- Algoritmo basado en el análisis sintáctico del
código - Inconvenientes
- Las relaciones entre clases llevan información
semántica que no puede ser inferida del análisis
del código. - b) Los tipos declarados son una aproximación
de las clases instanciadas en el programa debido
a la presencia de relaciones de herencia y al uso
de interfaces. - Algoritmo basado en OFG para resolver a) y b)
53Extracción de clases
- La información mostrada en una clase (atributos,
- métodos, el tipo de los atributos, los parámetros
- de los métodos, su visibilidad y alcance) puede
- extraerse analizando la sintaxis.
54EjemploExtracción de clases
55EjemploExtracción de clases
56EjemploExtracción de clases
57EjemploExtracción de clases
58Extracción de relaciones
59EjemploExtracción de dependencias
Dependencia entre Library y User
60EjemploExtracción de dependencias
Dependencia entre Library y Document
61EjemploExtracción de asociaciones
Loan está asociada a User y Document
62Tipos actual vs. declarados
- Los tipos declarados de atributos, variables
locales y parámetros de - los métodos son usados para determinar la clase
target de - asociaciones y dependencias. Es bastante común
que el tipo - declarado sea la raíz de una jerarquía de
herencia o que sea una interfaz. - Ejemplo
InternalUser es una subclase de User. Book,
Journal, TechnicalReport son subclases de
Document Si la aplicación usa sólo una parte del
subárbol de herencia, el target de la asociación
o dependencia puede ser incorrecto. Por ejemplo
en una instancia específica una asociación
debería conectar Loan y Book en vez de Document.
63Tipos actuales vs. declarados
- Ejemplo
- Una aplicación puede contener una clase
BinaryTreeNode - con un atributo obj que almacena información
asociada con - cada nodo del árbol y su tipo declarado
Comparable, la - interfaz implementada para objetos que pueden
ordenarse - totalmente por el método compareTO. Esto
generaría la - asociación entre BinaryTreeNode a Comparable. Si
la - aplicación define a una clase Student que
implementa a - Comparable, el método propuesto no recupera la
asociación - entre BinaryTreeNode y Student
- El método propuesto no detecta que los tipos
declarados - pueden ser una superclase del tipo del objeto
actual o una - interfaz implementada para el objeto actual.
64Data-Flow
65Especialización para determinar el tipo de
objetos actuales
66EjemploÁrbol binario de búsqueda
67EjemploÁrbol binario de búsqueda
68Ejemplo-Árbol binario de búsquedaSintaxis
abstracta
69Ejemplo-Árbol binario de búsquedaOFG
70Ejemplo-Árbol binario de búsquedaOFG
Es detectada una asociación entre BinaryTreeNode
y Student
71Containers
- Clases que implementan estructuras de datos
- (Listas, árboles grafos, vectores, )
- Los containers débilmente tipados coleccionan
objetos - cuyos tipos no son declarados, por ejemplo,
Containers en - versiones de JAVA que no soportan genericidad.
- Esto dificulta la ingeniería inversa dado que la
- información acerca de las clases de los objetos
- contenidos no se encuentra disponible en el
código.
72Containers
Map y Collection son interfaces. Las clases que
las implementan son HashMap y LinkedList, dos
containers débilmente tipados, que son clases
de biblioteca y no serán explicitadas
73Ejemplo
74Data-Flow forward para Containers
75Data-Flow backward para Containers
76EjemploContainers
77EjemploContainers
78EjemploContainers- Sintaxis abstracta
79EjemploContainers- Sintaxis abstracta
80EjemploContainers- Sintaxis abstracta
81EjemploContainers- OFG
82- Desde JAVA a diagrama de objetos
83Ingeniería inversa de diagramas de objetos
- El diagrama de objetos muestra una instantánea
- de un conjunto de objetos y sus relaciones.
- Los elementos en este diagrama (objetos y
relaciones) - son instancias de los elementos (clases y
asociaciones) - en el diagrama de clases.
- El diagrama de objetos muestra explícitamente
- cómo diferentes instancias pueden desempeñar
- diferentes roles y estar involucradas en
diferentes - relaciones.
84Ingeniería inversa de diagrama de objetos
- Análisis estático análisis dinámico
- Un análisis estático del código basado en OFG
para aproximar estáticamente la creación de
objetos y sus interrelaciones. - Un análisis dinámico basado en trazas de
ejecución donde cada una de ellas está asociada
con un diagrama de objetos y las relaciones que
son instanciadas. - El análisis estático es seguro con respecto a los
objetos y - relaciones que representa, sin embargo, no provee
información - sobre multiplicidad y no permite detectar caminos
que no son - factibles
85Extracción de diagramas de objetos
- Los puntos de asignación (líneas de código que
contienen sentencias de asignación) son usados
para aproximar el conjunto de objetos creados por
un programa, mientras que el OFG es usado para
determinar las relaciones entre objetos. - Especialización de la propagación del flujo de
datos
86Extracción de diagramas de objetos
- Cada sitio de asignación ( 5) está asociado con
un único - identificador ci (el nombre de la clase c y un
entero - incrementado i).
- Cada identificador de objeto ci genera un nodo en
el - diagrama de objetos. Cada nodo en OFG asociado a
un - atributo, es decir con un prefijo c y sufijo a,
donde a es - un atributo de clase c, se tiene en cuenta cuando
se generan - asociaciones entre objetos.
- El conjunto out de tal nodo de OFG( es decir
outc.a) da el - conjunto de objetos alcanzables desde todos los
objetos ci de - clase c a lo largo de la asociación implementada
a través del - atributo a.
87EjemploÁrbol binario de búsqueda- JAVA
88EjemploÁrbol de búsqueda-Sintaxis abstracta
89EjemploÁrbol de búsqueda-Sintaxis abstracta
- Los objetos de tipo BinaryTreeNode se asignan
- en 3 puntos distintos del programa, originando 3
- identificadores BinaryTreeNode1,
- BinaryTreeNode2, BinaryTreeNode3, los que
- están incluidos en el conjunto gen de
- BinaryTree.root, BinaryTreeNode.addLeft.n,
- BinaryTreeNode.addRight.n respectivamente.
- Hay una única asignación para objetos BinaryTree,
- el único identificador es BinaryTree1, insertado
en el - gen de BinaryTree.main.bt
90EjemploÁrbol binario de búsqueda- OFG
91EjemploÁrbol binario de búsqueda - OFG
- Construcción del diagrama de objetos
- Cada identificador se convierte en un nodo en el
- diagrama.Los conjuntos out de los atributos de
- clase determinan las interelaciones
92EjemploÁrbol binario de búsqueda - OFG
93Extracción del diagrama de objetosAnálisis
sensible a objetos
- Un identificador de objeto ci se asocia a cada
punto de - asignación en el programa que se analiza.
- Una ubicación n originalmente alcanzada por una
clase c, - se asocia ahora a un conjunto de nodos n,
alcanzados por - identificadores de objetos ci. Específicamente,
para cada - identificador de un objeto ci, creado para la
clase c, una - réplica de la ubicación n alcanzada por ci se
inserta en el - OFG
94Análisis sensible a objetosReglas para la
construcción del OFG
95Extracción del diagrama de objetosEjemplo- Árbol
de búsqueda
96Extracción del diagrama de objetosEjemplo- Árbol
de búsqueda
97Ejemplo- Árbol de búsquedaOFG
98Ejemplo- Árbol de búsquedaOFG Sensible a objetos
99Ejemplo- Árbol de búsquedaOFG Sensible a objetos
100Ejemplo- Árbol de búsquedaOFG Sensible a objetos
101Ejemplo- Árbol de búsquedaOFG
Insensible a objetos
Sensible a objetos
102Ejemplo- Árbol de búsquedaOFG
- El análisis sensible a objetos da información
- precisa sobre los elementos de datos almacenado
- en los dos árboles binarios bt1 y bt2. El OFG
- indica que el primer árbol es usado para
- administrar objetos de clase A y el segundo
- de tipo B1. El análisis insensible es menos
- preciso y no distingue los elementos almacenados
- en los dos árboles
103Análisis dinámico
- Un análisis dinámico provee un conjunto de
- diagramas de objetos, cada uno asociado con un
- test. Las ejecuciones de un programa se asocian
- a una traza de ejecución de cuyo análisis surge
- un diagrama de objetos.
- Es parcial, está basado en un caso limitado de
- casos de prueba
104Ejemplo- Árbol de búsquedaAnálisis dinámico
- Asumamos que los elementos del árbol están
ordenados - de acuerdo a compareTo disponible para el
atributo object - (en la clase BinaryTreeNode) que implementa una
interfaz - Comparable.
- Un test puede consistir en la creación de 1 o más
objetos - BinaryTreeNode, con un String asignado al
atributo object - y la inserción de los nodos en el mismo árbol.
- Supongamos 3 cadenas(a, b, c) para test
TC1, TC2 - y TC3
105Análisis dinámico
106Análisis dinámico
107Ejemplo- Árbol de búsquedaAnálisis dinámico