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
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.
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.
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
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
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,…
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
Ingeniería inversa de código OOInconvenientes UML JAVA Por ejemplo, las construcciones JAVA no se alinean con UML: Generalización/ especialización Agregación/composición Asociaciones Cuerpo de los métodos …
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).
Arquitectura general de una herramienta de ingeniería inversa
Ejemplo de modelo del lenguaje para JAVA simplificado
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
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)
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
OFGLenguaje abstracto
OFGLenguaje abstracto
OFGLenguaje abstracto return y this
EjemploeLib- Diagrama de clases
EjemploLenguaje abstracto-Declaraciones Library.loans Declaración de atributo loans Library.Library() Declaración de constructor implícito
EjemploLenguaje abstracto-Declaraciones Library.borrowDocument(Library.borrowDocument.user, Library.borrowDocument.doc) Declaración de método
EjemploLenguaje abstracto-Sentencias 60-62 Library.borrowDocument.loan = new Loan(Library.borrowDocunent.user, Library.borrowDocument.doc); Library.borrowDocument.this. Library. addLoan(library.borrowDocument.loan)
EjemploLenguaje abstracto-Sentencias 42 Library.addLoan.user=Loan.getUser.return 43 Library.addLoan.doc = Loan.getDocument.return;
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
Generación del OFG Los arcos se insertan de acuerdo a las siguientes reglas
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:
Generación del OFG x = y {(y,x) ? E}
genera los siguientes arcos
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
Generación del OFGContainers Library.loans = Library.addLoan.loan
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
Generación del OFGContainers
Generación del OFGContainers – Un objeto user es extraído del container users Library.getUser.return = Library.users – Un objeto user es insertado en el container users Library.users = Library.addUser.user
Algoritmo Data-Flowforward
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
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)
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, Document1, Loan1, Document2, Loan2
OFGData-flow Insensible a objetos
OFGData-Flow Sensible a objetos
OFGData-Flow
OFGData-Flow
OFGData-Flow
OFGData-Flow
OFGData-Flow
OFGData-Flow
Desde JAVA a diagramas de clases
Desde 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
Desde 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)
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.
EjemploExtracción de clases
EjemploExtracción de clases
EjemploExtracción de clases
EjemploExtracción de clases
Extracción de relaciones
EjemploExtracción de dependencias Dependencia entre Library y User
EjemploExtracción de dependencias Dependencia entre Library y Document
EjemploExtracción de asociaciones Loan está asociada a User y Document
Tipos 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.
Tipos 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.
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úsquedaSintaxis abstracta
Ejemplo-Árbol binario de búsquedaOFG
Ejemplo-Árbol binario de búsquedaOFG Es detectada una asociación entre BinaryTreeNode y Student
Containers 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.
Containers 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
Ejemplo
Data-Flow forward para Containers
Data-Flow backward para Containers
EjemploContainers
EjemploContainers
EjemploContainers- Sintaxis abstracta
EjemploContainers- Sintaxis abstracta
EjemploContainers- Sintaxis abstracta
EjemploContainers- OFG
Desde JAVA a diagrama de objetos
Ingenierí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.
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. 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
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, mientras que el OFG es usado para determinar las relaciones entre objetos. Especialización de la propagación del flujo de datos
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). 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 out[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.
EjemploÁrbol binario de búsqueda- JAVA
EjemploÁrbol de búsqueda-Sintaxis abstracta
EjemploÁ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
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
EjemploÁrbol binario de búsqueda – OFG
Extracció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
Análisis “sensible” a objetosReglas para la construcción del OFG
Extracción del diagrama de objetosEjemplo- Árbol de búsqueda
Extracción del diagrama de objetosEjemplo- Árbol de búsqueda
Ejemplo- Árbol de búsquedaOFG
Ejemplo- Árbol de búsquedaOFG Sensible a objetos
Ejemplo- Árbol de búsquedaOFG Sensible a objetos
Ejemplo- Árbol de búsquedaOFG Sensible a objetos
Ejemplo- Árbol de búsquedaOFG Insensible a objetos Sensible a objetos
Ejemplo- Á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
Aná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
Ejemplo- Á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
Análisis dinámico
Análisis dinámico
Ejemplo- Árbol de búsquedaAnálisis dinámico