You are on page 1of 107

Arquitectura de software dirigida por modelos

(Model-Driven Architecture)
Liliana Favre UNCPBA 2006

Técnicas de reingeniería y MDA

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

Ingeniería directa. inversa y reingenieía .

. 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. Reingeniería Es el proceso que transforma una representación de bajo nivel en otra.Ingeniería directa. 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. 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.

. 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.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. mejorar la performance o adaptarlo a un cambio de entorno.

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

Ingeniería inversa .

reusabilidad y documentación. January 1990 . reingeniería. IEEE Software. que resumen aspectos relevantes de la computación ejecutada por las sentencias del programa. Proveen una manera de extraer vistas de alto nivel desde el código sistema.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. 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.

dynamic binding. Extraer información en código OO es difícil (o imposible?)  Naturaleza dinámica de los lenguajes OO  Creación de objetos.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.… . garbage collector.

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.

Ingeniería inversa de programas OO .

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

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

Arquitectura general de una herramienta de ingeniería inversa .

Ejemplo de modelo del lenguaje para JAVA simplificado .

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

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. iteraciones. simplificada de JAVA que omite sentencias de control (condicionales. clases y métodos que los incluyen) . etc)  Evita conflictos de nombres (los identificadores son precedidos por un punto separados por la lista de packages.

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

OFG Lenguaje abstracto .

OFG Lenguaje abstracto .

OFG Lenguaje abstracto return y this .

Diagrama de clases .Ejemplo eLib.

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

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

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

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

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

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

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

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

linkedList.y)  Clases que implementan la interfaz Collection (vector.)  Clases que interpretan la interfaz Map (Hashtable. HashMap.c) є E (2) x = c.insert(x) (x..extract() (c. HashSet.…) Los dos casos básicos (1) c. TreeSet.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 . TreeMap.. debería incluirse el arco (x.Generación del OFG Containers Si una función de librería introduce un flujo de dato de una variable x a otra y.

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

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

Generación del OFG Containers .

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

Algoritmo Data-Flow forward .

es imposible decidir estáticamente si un camino es factible o no. Análisis insensible a objetos .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.

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. 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) . Para cada punto de asignación.

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

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. Loan2 . Document2. Loan1. Document1.

OFG Data-flow Insensible a objetos .

OFG Data-Flow Sensible a objetos .

OFG Data-Flow .

OFG Data-Flow .

OFG Data-Flow .

OFG Data-Flow .

OFG Data-Flow .

OFG Data-Flow .

Desde JAVA a diagramas de clases .

Elementos de un diagrama de clases  Clases  Interfaz. clases abstractas. clases parametrizadas   Relaciones de dependencia. generalización y asociación Especificaciones OCL .Desde JAVA a diagramas de clase Los diagramas de clase resumen importantes decisiones de diseño sobre la organización del sistema.

Desde JAVA a diagramas de clase
Algoritmo basado en el análisis sintáctico del código Inconvenientes a) 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)

Extracció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.

Ejemplo Extracción de clases

Ejemplo Extracción de clases .

Ejemplo Extracción de clases .

Ejemplo Extracción de clases .

Extracción de relaciones .

Ejemplo Extracción de dependencias Dependencia entre Library y User .

Ejemplo Extracción de dependencias Dependencia entre Library y Document .

Ejemplo Extracción de asociaciones Loan está asociada a User y Document .

declarados Los tipos declarados de atributos. Ejemplo InternalUser es una subclase de User. Es bastante común que el tipo declarado sea la raíz de una jerarquía de herencia o que sea una interfaz. el target de la asociación o dependencia puede ser incorrecto. variables locales y parámetros de los métodos son usados para determinar la clase target de asociaciones y dependencias. Book. Journal. . Por ejemplo en una instancia específica una asociación debería conectar Loan y Book en vez de Document.Tipos actual vs. TechnicalReport son subclases de Document Si la aplicación usa sólo una parte del subárbol de herencia.

Esto generaría la asociación entre BinaryTreeNode a Comparable. 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. . Si la aplicación define a una clase Student que implementa a Comparable.Tipos actuales vs. 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.

Data-Flow .

Especialización para determinar el tipo de objetos actuales .

Ejemplo Árbol binario de búsqueda

Ejemplo Árbol binario de búsqueda

Ejemplo-Árbol binario de búsqueda Sintaxis abstracta

Ejemplo-Árbol binario de búsqueda OFG .

Ejemplo-Árbol binario de búsqueda OFG Es detectada una asociación entre BinaryTreeNode y Student .

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. vectores. …) Los containers débilmente tipados coleccionan objetos cuyos tipos no son declarados. árboles grafos. .Containers Clases que implementan estructuras de datos (Listas. por ejemplo.

Containers Map y Collection son interfaces. que son clases de biblioteca y no serán explicitadas . dos containers débilmente tipados. Las clases que las implementan son HashMap y LinkedList.

Ejemplo .

Data-Flow forward para Containers .

Data-Flow backward para Containers .

Ejemplo Containers .

Ejemplo Containers .

Ejemplo Containers.Sintaxis abstracta .

Sintaxis abstracta .Ejemplo Containers.

Sintaxis abstracta .Ejemplo Containers.

Ejemplo Containers.OFG .

Desde JAVA a diagrama de objetos .

El diagrama de objetos muestra explícitamente cómo diferentes instancias pueden desempeñar diferentes roles y estar involucradas en diferentes relaciones. Los elementos en este diagrama (objetos y relaciones) son instancias de los elementos (clases y asociaciones) en el diagrama de clases. .Ingeniería inversa de diagramas de objetos El diagrama de objetos muestra una “instantánea” de un conjunto de objetos y sus relaciones.

 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. no provee información sobre multiplicidad y no permite detectar caminos que no son factibles .Ingenierí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. sin embargo. El análisis estático es seguro con respecto a los objetos y relaciones que representa.

Extracció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. Especialización de la propagación del flujo de datos  . mientras que el OFG es usado para determinar las relaciones entre objetos.

Cada identificador de objeto ci genera un nodo en el diagrama de objetos. Cada nodo en OFG asociado a un atributo.Extracció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). se tiene en cuenta cuando se generan asociaciones entre objetos. El conjunto out de tal nodo de OFG( es decir out[c. es decir con un prefijo c y sufijo a. . donde a es un atributo de clase c.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.

JAVA .Ejemplo Árbol binario de búsqueda.

Ejemplo Árbol de búsqueda-Sintaxis abstracta .

addLeft. el único identificador es BinaryTree1. insertado en el gen de BinaryTree. BinaryTreeNode. originando 3 identificadores: BinaryTreeNode1.root.bt .n. Hay una única asignación para objetos BinaryTree.Ejemplo Árbol de búsqueda-Sintaxis abstracta Los objetos de tipo BinaryTreeNode se asignan en 3 puntos distintos del programa. los que están incluidos en el conjunto gen de BinaryTree. BinaryTreeNode3. BinaryTreeNode.n respectivamente.main.addRight. BinaryTreeNode2.

Ejemplo Árbol binario de búsqueda.OFG .

Ejemplo Á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 .

OFG .Ejemplo Árbol binario de búsqueda .

una réplica de la ubicación n alcanzada por ci se inserta en el OFG .Extracción del diagrama de objetos Aná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´. Específicamente. alcanzados por identificadores de objetos ci. creado para la clase c. para cada identificador de un objeto ci.

Análisis “sensible” a objetos Reglas para la construcción del OFG .

Árbol de búsqueda .Extracción del diagrama de objetos Ejemplo.

Extracción del diagrama de objetos Ejemplo.Árbol de búsqueda .

Árbol de búsqueda OFG .Ejemplo.

Árbol de búsqueda OFG Sensible a objetos .Ejemplo.

Árbol de búsqueda OFG Sensible a objetos .Ejemplo.

Ejemplo.Árbol de búsqueda OFG Sensible a objetos .

Ejemplo.Árbol de búsqueda OFG Insensible a objetos Sensible a objetos .

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 .Ejemplo.Árbol de búsqueda OFG El análisis “sensible” a objetos da información precisa sobre los elementos de datos almacenado en los dos árboles binarios bt1 y bt2.

Es parcial. está basado en un caso limitado de casos de prueba . cada uno asociado con un test.Análisis dinámico Un análisis dinámico provee un conjunto de diagramas de objetos. Las ejecuciones de un programa se asocian a una traza de ejecución de cuyo análisis surge un diagrama de objetos.

TC2 y TC3 . Supongamos 3 cadenas(“a”. Un test puede consistir en la creación de 1 o más objetos BinaryTreeNode. “c”) para test TC1.Ejemplo.Árbol de búsqueda Aná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. con un String asignado al atributo object y la inserción de los nodos en el mismo árbol. “b”.

Análisis dinámico .

Análisis dinámico .

Ejemplo.Árbol de búsqueda Análisis dinámico .