Ingeniería inversa de eventos GUI en aplicaciones RAD mediante MDD Óscar Sánchez Ramón Jesús Sánchez Cuadrado Jesús García Molina Facultad de Informática Facultad de Informática Facultad de Informática Universidad de Murcia Universidad de Murcia Universidad de Murcia osanchez@um.es jesusc@um.es jmolina@um.es Resumen La migración del código de manejo de eventos de la interfaz gráca de usuario (GUI) es uno de los retos que deben afrontarse cuando se aborda la modernización de un sistema heredado desarrollado con un entorno Rapid Application Development (RAD). Esta tarea conlleva varias dicultades, pues frecuentemente implica un cambio de lenguaje de programación o tecnología, y un cambio en la arquitectura del sistema, dado que las aplicaciones desarrolladas en entornos RAD no contemplan una separación de la arquitectura en capas. En este trabajo proponemos una aproximación MDD para realizar ingeniería inversa de los eventos GUI de aplicaciones RAD, con el objetivo de obtener información acerca del código original que sea de utilidad para un posterior proceso de rediseño e ingeniería directa. 1. Introducción En la actualidad existe un gran número de aplicaciones heredadas que fueron construidas con entornos RAD (Rapid Application Development), tales como Oracle Forms 6 o Borland Delphi 5, y que están siendo migradas a plataformas más modernas. Estas migraciones son realizadas manualmente en la mayoría de los casos. Recientemente ha emergido la Modernización Dirigida por Modelos, como forma de conseguir automatizar las tareas propias de los procesos de evolución de software a través de la aplicación de las técnicas básicas del Desarrollo Dirigido por Modelos (Model Driven Development, MDD). Cuando se realiza una migración entre plataformas, es necesario considerar todos los componentes de la arquitectura software de la aplicación existente. El componente relacionado con interfaz gráca de usuario (GUI) es fundamental en la mayoría de arquitecturas, y su migración requiere considerar varios aspectos, como la disposición de los controles grácos (layout) y el manejo de eventos. El primer aspecto se ha tratado en un trabajo previo [1], y este trabajo se centrará en el segundo aspecto en el contexto de la migración de aplicaciones RAD. Las tecnologías de desarrollo de GUI utilizan modelos de eventos para permitir la interacción del usuario con la aplicación (por ejemplo, en Java la librería Swing usa el Modelo de Delegación de Eventos). En el caso de la tecnología RAD, el modelo de eventos es simple y normalmente y los manejadores de evento se asocian directamente a los componentes. Sin embargo, cada entorno dene un conjunto de eventos propios, y el lenguaje y las facilidades de que se dispone para denir las acciones asociadas son dependientes de la tecnología. Una característica de los entornos RAD es que el código de los eventos puede interaccionar directamente con una base de datos, sin necesidad de invocar a funciones de la lógica de negocio que se encarguen de dicha tarea. Esto supone un problema cuando pretendemos abordar la modernización de este código, dado que hoy en día es una práctica habitual separar las aplicaciones en capas con el n de facilitar el mantenimiento, legibilidad y extensibilidad de la aplicación.
DECLARE DECL n Number; DECL val VARCHAR2(50); BEGIN n := 1; SELECT value INTO val FROM mappings Refinamiento DECLARE DECL n Number; DECL val VARCHAR2(50); BEGIN n := 1; SELECT value INTO val FROM mappings M2M Código Fuente (PL/SQL) T2M Modelo de Código (PL/SQL) M2M Modelo Abstracto de Eventos Usuario Patrones conformes al DSL Repositorio de patrones (patrones Forms) M2M Figura 1: Arquitectura para realizar ingeniería inversa de eventos de GUI Es deseable, por tanto, analizar los eventos de GUI y disponer de una representación de los mismos que sea independiente de entornos, lenguajes y tecnologías, que pueda ser fácilmente estructurada en capas, y que en denitiva contenga toda la información que sea posible deducir del código fuente con el objetivo de automatizar los procesos de generación de nuevas aplicaciones en la mayor medida posible. Por tanto, el propósito de este trabajo es mostrar una aproximación de Modernización Dirigida por Modelos para aplicar ingeniería inversa de los eventos de aplicaciones RAD destinada a facilitar la migración a otras plataformas, lo que nos permitirá la automatización total o parcial del proceso. Se propone una representación independiente del lenguaje para el código de manejo de eventos, y un DSL para establecer la correspondencia entre patrones código y tal representación. También, se describen varias usos de esta representación al automatizar la ingeniería inversa. La sección 2 se muestra una visión general de la arquitectura de modelos para realizar el proceso de ingeniería inversa. La sección 3 muestra el metamodelo empleado para representar la información extraída de los eventos, en la sección 4 se describe el DSL de patrones, y en la sección 5 se describen varios ejemplos de aplicación. Las secciones 6 y 7 nalizan presentando respectivamente el trabajo relacionado, y las conclusiones y trabajo futuro. 2. Visión general de la arquitectura La arquitectura de modelos propuesta para realizar el proceso de ingeniería inversa del código de manejo de eventos en aplicaciones RAD se muestra en la Figura 1. Aunque esta arquitectura esta orientada a la extracción del comportamiento de los eventos de Oracle Forms y PL/SQL, el esquema puede ser generalizado para otras tecnologías RAD. En primer lugar, partimos de código de la aplicación RAD original, código PL/SQL de Oracle Forms en nuestro caso. El código se inyecta en un modelo que lo representa mediante una transformación texto a modelo(t2m ), y que conformará con un metamodelo de la sintaxis abstracta de PL/SQL. El segundo paso consiste en obtener el modelo abstracto de eventos, que se utiliza para: i) representar el código fuente de forma independiente a lenguajes y tecnologías, mediante acciones habituales en los entornos RAD (como por ejemplo leer de la interfaz o escribir en base de datos), y ii) eliminar detalles que son superuos para analizar el comportamiento de los eventos. La obtención de un modelo abstracto de eventos a partir del modelo de código PL/SQL se consigue mediante una transformación modelo a modelo (M2M). Como explicaremos más adelante, a su vez esta
0..n 0..n RADVariable 1 ModelRoot RADReadable 1 0..n 0..n in 0..1 out 0..n 1 EventDefinition + targetelement 0..n 1 0..n RADAction UIVar DBVar TempVar PredefinedVar ReadFromDB WriteToUI ManipulateData ControlFlow Figura 2: Metamodelo abstracto de eventos transformación se obtiene automáticamente a través de otra transformación modelo a modelo que toma como entrada un modelo que representa un conjunto de patrones que establecen reglas para construir el modelo abstracto de eventos a partir del modelo de código. La siguiente etapa del proceso consiste en renar el modelo abstracto de eventos. El objetivo es inferir información adicional acerca de los eventos, y representarla de forma explícita en el propio modelo abstracto de eventos. A partir del modelo renado es posible realizar diversas tareas de reingeniería, como generar informes y visualizaciones, restructurar el código o generar esqueletos de código (automatización parcial de la migración). La infraestructura se está desarrollando en la plataforma Eclipse, utilizado Ecore como lenguaje de metamodelado, Gra2MoL [3] para inyectar código PL/SQL en modelos, y RubyTL [4] para realizar las transformaciones modelo a modelo. 3. Representación de los eventos a alto nivel El modelo abstracto de eventos se utiliza para representar los eventos GUI a alto nivel. Tiene dos características principales: permite representar las acciones de los eventos con independencia de lenguajes y tecnologías, y omite detalles que no son relevantes para analizar el comportamiento del evento (por ejemplo cuál es la funcionalidad concreta de una operación de tratamiento de enteros), con lo cuál se simplica el posterior análisis de los mismos. En la Figura 2 se muestra de forma simplicada el metamodelo al que conforman los modelos abstractos de eventos. Principalmente distinguimos dos elementos en el metamodelo: variables (RADVariable) y acciones (RADAction). Las primeras son los datos que el evento maneja, mientras que las segundas son primitivas que utilizan esos datos. En base a la proveniencia de los datos tendremos los siguientes tipos de variables: Variables temporales (TempVar), que son variables locales a los eventos y que se utilizan para almacenar datos que resultan de lecturas y manipulaciones de datos. Variables predenidas (Predened- Var), son variables globales que tienen una semántica predenida en un entorno o tecnología. Variables de interfaz (UIVar), que representan los controles de la interfaz gráca. Variables de base de datos (DBVar), que representan un recurso que permite interaccionar con una base de datos, como puede ser un origen de datos. Igualmente, distinguimos diferentes tipos de primitivas para representar acciones. En el
Primitiva ReadFromUI WriteToUI WriteToVar ReadFromDB ModifyUI ManipulateData SelectionFlow ShowMessage Invoke Signicado Lee un valor de un control de la GUI Modica un valor de un control de la GUI Escribe un valor en una variable temporal Lee valores de base de datos Modica atributos grácos de los controles de la GUI Realiza una operación sobre datos, por ejemplo, la obtención de una subcadena en base a una cadena Control de ujo selectivo Muestra una ventana modal emergente Invoca a una función o procedimiento Cuadro 1: Primitivas semánticas cuadro 1 se muestran algunas de las primitivas identicadas. Las primitivas se aplican sobre una o más variables de entrada, y si se trata de una operación de escritura, tendrán una variable de salida asociada (referencia out). Además, como se observa en el metamodelo, la entrada de una primitiva (dependencia in entre RADAction y RADReadable) puede ser otra primitiva, lo que permite componer las primitivas para expresar acciones más complejas de un modo más compacto, esto es, sin necesidad de utilizar variables temporales para almacenar el resultado de otras primitivas. Esta representación mantiene, en cierta medida, la estructura del código original lo que facilitará análisis de grano grueso. Otras representaciones más atómicas (como SSA [9] [10]) son útiles para análisis de grano no, y serán consideradas en futuros trabajos. Estas primitivas conforman un subconjunto básico suciente para comprender la funcionalidad del evento a alto nivel. Sin embargo, si en fases posteriores del proceso de modernización pretendemos generar código a partir de los eventos, necesitamos anar más en la especicación de algunas de las primitivas para incluir información más detallada. Por ejemplo, sería necesario modelar las condiciones de las primitivas de control, o la funcionalidad de las primitivas de manipulación de datos. Con el objetivo de representar toda la información del sistema original, en un futuro se evaluará la posibilidad de relacionar el metamodelo abstracto de eventos con el metamodelo de la tecnología fuente, ya sea mediante un metamodelo propio que represente el código de forma independiente de la plataforma, o utilizando un metamodelo estándar como KDM [7] para este n. El elemento ModelRoot actua como raíz del metamodelo, y contiene los eventos (EventDefinition), así como las variables globales a los éstos, de modo que las variables de interfaz, las de base de datos y las predenidas puedan ser reutilizadas. La metaclase EventDenition tiene un nombre, un tipo de evento, está asociada al elemento targetelement que dispara el evento (normalmente un control de la interfaz), y contienen las variables y acciones que denen el comportamiento a realizar cuando se activa el evento. 4. Abstracción de código mediante un DSL de patrones Para obtener el modelo abstracto de eventos a partir del modelo de código fuente, la aproximación directa sería crear una transformación modelo a modelo. Sin embargo, este enfoque presenta dos problemas fundamentales: a) el codigo de la transformación sería muy verboso, b) incorporar nuevos casos de análisis implicaría modicar la transformación. Para superar estas desventajas, se ha diseñado un DSL para establecer correspondencias entre patrones de código PL/SQL y primitivas del modelo abstracto de eventos. La dinámica consiste en aplicar los patrones sobre el código de los manejadores de eventos del sistema heredado, de modo que para ca-
«from PL/SQL» Statement source 1..n FormsPattern target 1..n «from SemanticActions» RADAction «from PL/SQL» Statement GenericStatement «from PL/SQL» Expression GenericExpression +vargroup: string «from PL/SQL» Variable GenericVariable +id: string +pattern: RegExpr «Datatype» OpType AND OR «from EventAbstractMM» RADVariable RegExpr GenericVariable +id: string GenericVarGroup +id: string SimpleRegExpr +not: boolean +expr: string CompositeRegExpr +operator: OpType 1..n Figura 3: Metamodelo de la sintaxis abstracta del DSL de patrones. da patrón concordado se genera un fragmento de código de primitivas de alto nivel. Cuando existan varios patrones posibles, se informará al desarrollador para que seleccione una de las alternativas, siendo por tanto un proceso semiautomático. Con el objetivo de denir los patrones de forma concisa, se pretende que una sola sentencia del DSL empareje con un trozo de modelo de sintaxis abstracta mediante el uso de comodines (por comodin entendemos un elemento que permite emparejar una parte cualquiera del modelo de código). Además, se ha decidido extender la propia sintaxis de PL/SQL para facilitar la escritura de los patrones, pues es menos verboso que utilizar la sintaxis abstracta. Para facilitar la extensibilidad se ha denido un repositorio de patrones (escritos con el DSL). Así, es posible incorporar de un modo sencillo nuevos patrones que sean dependientes de las convenciones de las empresas de desarrollo, sin necesidad de modicar las transformaciones. Se observa que tanto el DSL y el repositorio de patrones son dependientes de la tecnología origen del proceso de modernización. En el futuro se pretende separar la compilación de los patrones de la sintaxis concreta utilizada, con el n de usar el mismo compilador con diferentes lenguajes. El DSL de denición de patrones podría ser generado automáticamente a partir de la gramática, lo que evitaría tener que realizar un DSL manualmente para cada tecnología origen. La sintaxis abstracta del DSL corresponde al metamodelo que aparece en la Figura 3. El metamodelo hace corresponder un conjunto de sentencias PL/SQL con un conjunto de primitivas. Este metamodelo tiene referencias cruzadas con el metamodelo de PL/SQL, de modo que las metaclases Statement, Expression y Variable representan sentencias, expresiones y variables de PL/SQL respectivamente. En ocasiones ocurre que para denir los patrones necesitamos especicar que algunos elementos de un trozo de código no son relevantes. Por esta razón, las metaclases Generic- Statement, GenericExpression y GenericVariable han sido denidas para actuar como comodines al expresar los patrones. Generic- Variable puede tener un identicador (id) para referirse a la misma variable en otra parte del
Patrón PL/SQL (parte izquierda) IF GenericExpression(varGroup=V) THEN statements END SELECT - INTO GenericVariable(id=X, pattern=:*.* AND NOT :system.*) FROM - WHERE GenericExpression(varGroup=V) GenericVariable(id=X, pattern=not :*) := GenericVariable(id=Y) GenericVariable(pattern=':*.*' and not ':system.*') Primitivas (parte derecha) SelectionFlow(GenericVarGroup(id=V)) { statements } WriteToUI(ReadFromDB( GenericVarGroup(id=V)), GenericVariable(id=X)) WriteToVar(GenericVariable(id=Y), GenericVariable(id=X)) UIVar Cuadro 2: Ejemplos de reglas del DSL de patrones, con la sintaxis de PL/SQL. patrón y/o en la parte derecha de la regla (nótese que con id no nos estamos reriendo al nombre de un variable concreta del código PL/SQL). Mediante el atributo pattern también es posible especicar aquellas variables cuyo nombre cumple con una determinada expresión regular. La metaclase GenericExpression reemplaza a cualquier expresión, y utiliza el atributo vargroup para especicar el identicador del grupo de variables que se usan en la expresión (de manera que pueda utilizarse en la parte derecha de la regla). Respecto al metamodelo abstracto de eventos se denen dos tipos nuevos, GenericVarGroup y GenericVariable que representan a las variables y grupos de variables respectivamente, que se han identicado en el modelo PL/SQL. En el cuadro 2 se muestran algunos de los patrones establecidos para la tecnología Oracle Forms. Para facilitar la comprensión de los mismos se utiliza una sintaxis más verbosa que corresponde directamente con el metamodelo del DSL. El primer patrón transforma una sentencia IF en una sentencia de control de ujo de selección (SelectionFlow). El elemento GenericExpression se utiliza para representar cualquier expresión, pues no nos interesa un tipo de expresión en concreto, aunque sí que nos interesan el conjunto de variables que se utilicen en dicha expresión, a las cuales identicaremos como V. El segundo patrón representa una consulta SELECT de base de datos que escribe en una variable. De momento no estamos interesados en almacenar el nombre de la tabla y los atributos, razón por la cuál en el patrón se especica un guión para ignorarlos. Se especica que la variable (que identicaremos por X ) en la que se almacene el resultado de la consulta debe concordar con un patrón, que concretamente es un patrón que dene las variables que se reeren a controles GUI. Por esta razón, este patrón se traduce como una lectura de base de datos (ReadFromDB) que se escribe en una variable de interfaz (WriteToUI). El tercer patrón traduce una asignación de una variable de cualquier tipo a una variable local. El cuarto patrón se utiliza para resolver variables de interfaz. Cuando se aplica un patrón, puede ocurrir que la parte derecha de la regla se reera a GenericVarGroup o Generic- Variable. En estos casos es necesario aplicar otras reglas para resolver estas partes. Por ejemplo, es necesario traducir los tipos GenericVariable del modelo abstracto de eventos en tipos de variables concretas (UIVar, Temp- Var,...). Por esta razón es necesario especicar patrones (como por ejemplo el cuarto patrón) para resolver estos casos. Vamos a ilustrar el proceso de aplicación de los patrones mediante un ejemplo. En el entorno Oracle Forms 6 se pueden asociar disparadores PL/SQL a la ejecución de un conjunto predeterminado de eventos. A continuación se muestra el código de un disparador asociado al evento WHEN_VALIDATE_ITEM del campo de texto USERNAME, que se ejecuta cuando se produce un cambio en el campo de texto.
1 DECLARE 2 name VARCHAR2 (50) ; 3 BEGIN 4 name := : USER_DATA. USERNAME ; 5 IF name IS NOT NULL THEN 6 SELECT email INTO : USER_DATA. EMAIL 7 FROM User WHERE username = name ; 8 END IF ; 9 END ; En la línea 4 se copia el contenido del campo de texto USERNAME a la variable local name. Se comprueba que esta cadena de caracteres no sea nula (línea 5), y de ser así se obtiene el valor email de la la de la tabla de datos User cuyo nombre de usuario (username) coincida con el valor de la variable name. El valor obtenido de base de datos se almacena en el campo de texto EMAIL. El efecto del código es el siguiente. Cuando un usuario introduce el nombre de usuario en el campo de texto USERNAME, la aplicación busca la dirección de correo electrónico asociada a dicho usuario, y la muestra en el campo de texto EMAIL. Si aplicamos el conjunto de patrones denidos en el cuadro 2 al modelo PL/SQL antes descrito, se obtiene el siguiente modelo. Por simplicidad se han omitido algunos detalles de las primitivas, como la información relativa a la base de datos de la primitiva ReadFromDB, o la condición del SelectionFlow. Para cada conjunto de primitivas, se indica la línea o líneas que las originaron mediante la aplicación de los patrones y reglas. 1 WriteToVar (: USER_DATA. USERNAME, name ) /* línea 4 */ 2 SelectionFlow ( name ){ /* línea 5 */ 3 WriteToUI ( ReadFromDB (name ), : USER_DATA. EMAIL ) /* líneas 6 y 7 */ 4 } planteamos dos posibles usos de esta representación que tienen como objetivo inferir información implícita: la búsqueda de dependencias entre variables y la categorización de fragmentos de código. Las dependencias entre variables de interfaz (que representan controles) pueden ser una fuente de información útil en el proceso de comprensión del comportamiento de los eventos. En las interfaces de usuario frecuentemente ocurre que un cambio en el valor de un control de la interfaz afecta a otro control. Por ejemplo, imaginemos una casilla de veri- cación que cuando es marcada, habilita una lista desplegable que antes estaba deshabilitada. En este ejemplo, los controles vendrían representados por variables de interfaz, de modo que existiría una dependencia entre la variable asignada a la casilla de vericación y la variable que representa la lista desplegable. Esta información puede ser interesante para determinar dependencias entre eventos, pues un evento E 1 que estuviese asociado a una variable de interfaz V 1 podría activar la ejecución de otro evento E 2 asociado a la variable de interfaz V 2 si V 2 depende de V 1. Es posible asociar automáticamente categorías a fragmentos de código a partir de la información de grano no sobre variables y acciones obtenida en el modelo abstracto de eventos. En la actualidad estamos diseñando un algoritmo que recorre el modelo buscando secuencias de sentencias que tienen la misma naturaleza(ui, base de datos, etc.) y las agrupa. Esta información puede ser a su vez utilizada para dividir la aplicación original en capas, ya que cada fragmento de código de cierta naturaleza puede ser asignado a la UI, al controlador, o a la lógica de negocio. 5. Usos del modelo abstracto de eventos El modelo abstracto de eventos pretende ser una representación de información sobre los eventos adecuada, que está implícita en el código fuente y que puede ser de utilidad en una fase posterior de ingeniería directa para crear un nuevo sistema. A continuación 6. Trabajo relacionado En el trabajo [2] se presenta una herramienta comercial que migra aplicaciones Oracle Forms a la plataforma.net. Los eventos de la plataforma origen para los cuales existe una correspondencia con semántica similar en la plataforma destino se migran directamente, mientras que el resto deben ser asistidos por
el usuario. En [5] se aborda la evolución de sistemas heredados a sistemas SOA en tres capas. En esta propuesta los fragmentos de código original se anotan manualmente según el aspecto con que se relaciona (interfaz, lógica de negocio o datos). La arquitectura presentada permitirá automatizar estas anotaciones, como se comenta en la sección anterior. En [6] se propone la reingeniería inversa de interfaces de usuario con el objetivo de realizar pruebas de interfaz. En este trabajo se utiliza un modelo de ujo de eventos que representa todos las caminos de ejecución de eventos posibles a partir de las ventanas de la aplicación. La reingeniería se centra en deducir las relaciones entre ventanas originadas por eventos. Existen numerosos trabajos relativos al estudio del ujo de datos [8], [9] que se utilizan en la optimización de código por parte de compiladores. Estos trabajos proponen el análisis estático de código, más especícamente Single Static Assignment Form (SSA) así como otras técnicas, con el objetivo de eliminar código redundante y optimizar la asignación de variables. En [10] se utiliza SSA para obtener un grafo de ventanas, que es un grafo que representa las relaciones entre las ventanas de una GUI. Estos trabajos guardan cierta relación con las etapa de simulación y con el análisis de variables, sin embargo en nuestro caso, el análisis que realizamos es más sencillo y está orientado especícamente al código de eventos de GUI. 7. Conclusiones y trabajo futuro En este trabajo hemos presentado una aproximación para analizar el código de los eventos de la GUI de aplicaciones RAD. Como resultado de este análisis se obtiene una representación de alto nivel con información útil para la comprensión de dichos eventos. La información recopilada puede ser utilizada posteriormente para efectuar un proceso de ingeniería directa con el objetivo de generar un nuevo sistema o de reingeniería para modicar el sistema existente. Se evaluará la posibilidad de representar el sistema original completo mediante KDM [7], de modo que el modelo abstracto de eventos mantenga referencias al modelo KDM. Como trabajo futuro, se espera probar el proyecto con casos de estudio reales. Como fruto de dicho trabajo, se incorporarán nuevas primitivas de alto nivel y se renará y ampliará el conjunto de patrones identicados e incluidos en el repositorio estándar. Se modicará también la arquitectura para que sea independiente de la tecnología origen en la medida de lo posible. También sería posible realizar generadores de DSLs de denición de patrones a partir de gramáticas. Agradecimientos Este artículo ha sido parcialmente nanciado por la Consejería de Universidades, Empresa e Investigación (proyecto 129/2009) y la Fundación Séneca (proyecto 08797/P1/08). Referencias [1] O. Sánchez Ramón, J. Sánchez Cuadrado, and J. García Molina. Model-Driven Reverse Engineering of Legacy Graphical User Interfaces. In Proceedings of the 25th IEEE/ACM International Conference on Automated Software Engineering, ASE'10, 2010. [2] L. F. Andrade, J. Gouveia, M. Antunes, M. El-Ramly, and G. Koutsoukos. Forms2net - Migrating Oracle Forms to Microsoft.NET. In GTTSE, pages 261 277, 2006. [3] J. L. Cánovas Izquierdo and J. G. Molina. A Domain Specic Language for Extracting Models in Software Modernization. In ECMDA-FA '09: Proceedings of the 5th European Conference on Model Driven Architecture - Foundations and Applications, pages 8297, Berlin, Heidelberg, 2009. Springer-Verlag. [4] J. S. Cuadrado and J. G. Molina. Modularization of Model Transformations Through a Phasing Mechanism. Software and System Modeling, 8(3):325345, 2009.
[5] R. Heckel, R. Correia, C. M. P. Matos, M. El-Ramly, G. Koutsoukos, and L. F. Andrade. Architectural Transformations: From Legacy to Three-Tier and Services. In Software Evolution, pages 139170. 2008. [6] A. M. Memon. An Event-Flow Model of GUI-Based Applications for Testing: Research Articles. Software Testing Verication and Reliability, 17(3):137157, 2007. [7] OMG. Knowledge Discovery Meta-Model (KDM) v1.0. http://www.omg.org/spec/kdm/1.0/, 2008. [8] B. K. Rosen. Data Flow Analysis for Procedural Languages. J. ACM, 26(2):322 344, 1979. [9] B. K. Rosen, M. N. Wegman, and F. K. Zadeck. Global Value Numbers and Redundant Computations. In POPL '88: Proceedings of the 15th ACM SIGPLAN- SIGACT symposium on Principles of programming languages, pages 1227, 1988. [10] S. Staiger. Reverse Engineering of Graphical User Interfaces Using Static Analyses. In WCRE '07: Proceedings of the 14th Working Conference on Reverse Engineering, pages 189198, 2007.