Índice general - ridaa.unicen.edu.ar

Índice general

1. Introducción 81.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2. Descripción del proceso . . . . . . . . . . . . . . . . . . . . . . . 111.3. Estructura del Informe . . . . . . . . . . . . . . . . . . . . . . . . 12

2. Estado del Arte 132.1. Model Driven Architecture . . . . . . . . . . . . . . . . . . . . . 13

2.1.1. Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.2. Metamodelos . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.2.1. Meta Object Facility (MOF) . . . . . . . . . . . 162.1.3. Transformaciones . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.3.1. Query-View-Transformation (QVT) . . . . . . . 182.1.3.2. ATLAS Transformation Language . . . . . . . . 18

2.2. Ingeniería Inversa . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3. Ingeniería Directa . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4. Architecture Driven Modernization . . . . . . . . . . . . . . . . . 25

2.4.1. Knowledge Discovery Metamodel (KDM) . . . . . . . . . 262.4.2. Abstract Syntax Tree Metamodel (ASTM) . . . . . . . . 27

3. Lenguaje Haxe 283.1. Metaclases Principales . . . . . . . . . . . . . . . . . . . . . . . . 30

3.1.1. Metamodelado de módulos . . . . . . . . . . . . . . . . . 323.1.2. Metamodelado de comentarios . . . . . . . . . . . . . . . 323.1.3. Metamodelado de paquetes . . . . . . . . . . . . . . . . . 32

3.2. Metaclases de Tipos . . . . . . . . . . . . . . . . . . . . . . . . . 333.2.1. Metamodelado de clases e interfaces . . . . . . . . . . . . 333.2.2. Metamodelado de tipos de datos algebraicos . . . . . . . . 343.2.3. Metamodelado de tipos abstractos . . . . . . . . . . . . . 353.2.4. Metamodelado de alias de tipos Typedef . . . . . . . . . . 353.2.5. Metamodelado de metadatos . . . . . . . . . . . . . . . . 353.2.6. Metamodelado de elementos parametrizados . . . . . . . . 36

3.3. Metaclases de Expresiones . . . . . . . . . . . . . . . . . . . . . . 373.3.1. Metamodelado de expresiones compuestas . . . . . . . . . 373.3.2. Metamodelado de constantes . . . . . . . . . . . . . . . . 37

2

ÍNDICE GENERAL 3

3.3.3. Metamodelado de operaciones aritméticas . . . . . . . . . 383.3.4. Metamodelado de vectores o arreglos . . . . . . . . . . . . 383.3.5. Metamodelado de expresiones de selección . . . . . . . . . 393.3.6. Metamodelado de expresiones de selección múltiple . . . . 393.3.7. Metamodelado de expresiones de iteración . . . . . . . . . 403.3.8. Metamodelado de expresiones de corte y continuación del

�ujo de ejecución . . . . . . . . . . . . . . . . . . . . . . . 403.4. Metamodelado de declaraciones de variables . . . . . . . . . . . . 41

3.4.1. Metamodelado de atributos de instancia y de clase . . . . 423.5. Metaclases de funciones y métodos . . . . . . . . . . . . . . . . . 423.6. Metaclases de expresiones de acceso y construcción de objetos . . 433.7. Metaclases de expresiones de conversión y chequeo de tipos . . . 433.8. Metaclases de expresiones de manejo de excepciones . . . . . . . 44

4. Lenguaje C/C++ 454.1. Metaclases Principales . . . . . . . . . . . . . . . . . . . . . . . . 454.2. Metaclases de Archivos . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2.1. Metaclases de Clases, Estructuras y Uniones . . . . . . . 484.2.1.1. Ejemplos . . . . . . . . . . . . . . . . . . . . . . 49

4.2.2. Metaclases de Tipos Primitivos . . . . . . . . . . . . . . . 504.2.3. Metaclases de tipos Enum . . . . . . . . . . . . . . . . . . 50

4.2.3.1. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . 514.2.4. Metaclases de Variables . . . . . . . . . . . . . . . . . . . 514.2.5. Metaclases de Métodos . . . . . . . . . . . . . . . . . . . . 51

4.2.5.1. Ejemplos . . . . . . . . . . . . . . . . . . . . . . 534.2.6. Metaclases de Elementos Parametrizados . . . . . . . . . 53

4.2.6.1. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . 544.3. Metaclases de Expresiones . . . . . . . . . . . . . . . . . . . . . . 54

4.3.1. Metaclases de Expresiones de Selección . . . . . . . . . . 544.3.1.1. Ejemplos . . . . . . . . . . . . . . . . . . . . . . 55

4.3.2. Metaclases de Expresiones de Iteración o Bucles . . . . . 554.3.2.1. Ejemplos . . . . . . . . . . . . . . . . . . . . . . 56

4.3.3. Metaclases de Expresiones de Selección Múltiple . . . . . 564.3.3.1. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . 57

4.3.4. Metaclases de Expresiones Unarias y Binarias . . . . . . . 574.3.5. Metaclases de Expresiones de manejo de Excepciones . . . 59

4.3.5.1. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . 594.3.6. Metaclases de Expresiones Constantes . . . . . . . . . . . 594.3.7. Metaclases de Expresiones con Arreglos . . . . . . . . . . 60

4.3.7.1. Ejemplos . . . . . . . . . . . . . . . . . . . . . . 604.3.8. Metaclases de Expresiones de Salto . . . . . . . . . . . . . 61

4.3.8.1. Ejemplos . . . . . . . . . . . . . . . . . . . . . . 614.3.9. Metaclases de Expresiones Compuestas . . . . . . . . . . 624.3.10. Metaclases de Expresiones de Conversión de Tipos . . . . 62

4.3.10.1. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . 624.3.11. Metaclases Expresiones de Declaración de Variables . . . 63

ÍNDICE GENERAL 4

4.3.11.1. Ejemplos . . . . . . . . . . . . . . . . . . . . . . 634.4. Metaclases de Comentarios . . . . . . . . . . . . . . . . . . . . . 64

4.4.1. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5. Proceso de migración 655.1. Ingeniería Inversa . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.1.1. Descripción del proceso de Ingeniería Inversa . . . . . . . 665.1.2. ANTLR (ANother Tool for Language Recognition) . . . . 675.1.3. Programa Java desarrollado . . . . . . . . . . . . . . . . . 67

5.2. Transformación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.2.1. Elementos Principales . . . . . . . . . . . . . . . . . . . . 705.2.2. Tipos Primitivos . . . . . . . . . . . . . . . . . . . . . . . 715.2.3. Clases y Constructores . . . . . . . . . . . . . . . . . . . . 715.2.4. Enumeraciones . . . . . . . . . . . . . . . . . . . . . . . . 715.2.5. Expresiones . . . . . . . . . . . . . . . . . . . . . . . . . . 725.2.6. Declaración de Variables . . . . . . . . . . . . . . . . . . . 745.2.7. Métodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2.8. Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2.9. Comentarios . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.3. Ingeniería Directa . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.3.1. Acceleo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.4. Herramienta para la migración . . . . . . . . . . . . . . . . . . . 765.5. Repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6. Casos de Estudio 796.1. Programa Simple . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.1.1. Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.1.2. Resultado Final . . . . . . . . . . . . . . . . . . . . . . . . 82

6.2. Ping Pong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.2.1. Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.2.2. Resultado Final . . . . . . . . . . . . . . . . . . . . . . . . 90

6.3. Tetris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.3.1. Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.3.2. Resultado Final . . . . . . . . . . . . . . . . . . . . . . . . 96

7. Conclusiones 987.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . 100

A. Metamodelos 105A.1. Metamodelo del lenguaje Haxe . . . . . . . . . . . . . . . . . . . 105A.2. Metamodelo del lenguaje C/C++ . . . . . . . . . . . . . . . . . . 120

B. Transformaciones ATL 132

Índice de �guras

1.1. Proceso de migración . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1. Modelos MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2. Transformación MDA . . . . . . . . . . . . . . . . . . . . . . . . 172.3. Proceso MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4. Arquitectura de las herramientas de ingeniería inversa . . . . . . 222.5. Estrategias de generación de código . . . . . . . . . . . . . . . . . 242.6. Estrategia PIM-to-Framework Speci�c Model (FSM)-to-CPC . . 25

3.1. Lenguajes de destino de Haxe . . . . . . . . . . . . . . . . . . . . 283.2. Videojuegos en los que se usó Haxe . . . . . . . . . . . . . . . . . 293.3. Metaclases principales del metamodelo de Haxe . . . . . . . . . . 313.4. Metaclases de las características más comunes del metamodelo de

Haxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5. Metaclases de modelado de comentarios . . . . . . . . . . . . . . 323.6. Metaclases para el modelado de tipos . . . . . . . . . . . . . . . . 333.7. Metamodelado de clases e interfaces . . . . . . . . . . . . . . . . 343.8. Metamodelado de enumeraciones . . . . . . . . . . . . . . . . . . 343.9. Metaclases de tipos abstractos . . . . . . . . . . . . . . . . . . . . 353.10. Metaclases de metadatos . . . . . . . . . . . . . . . . . . . . . . . 363.11. Metaclases de elementos parametrizados . . . . . . . . . . . . . . 373.12. Metaclases de expresiones constantes . . . . . . . . . . . . . . . . 373.13. Metaclases de operaciones aritméticas . . . . . . . . . . . . . . . 383.14. Metaclases de arreglos . . . . . . . . . . . . . . . . . . . . . . . . 393.15. Metaclases de expresiones de selección . . . . . . . . . . . . . . . 393.16. Metaclases de expresiones de selección múltiple . . . . . . . . . . 403.17. Metaclases de expresiones de iteración . . . . . . . . . . . . . . . 403.18. Metaclases de expresiones de corte y continuación de ejecución . 413.19. Metaclases de variables . . . . . . . . . . . . . . . . . . . . . . . . 413.20. Metaclases de funciones . . . . . . . . . . . . . . . . . . . . . . . 423.21. Metaclases de acceso a objetos . . . . . . . . . . . . . . . . . . . 433.22. Metaclases de conversión de tipos . . . . . . . . . . . . . . . . . . 443.23. Metaclases de manejo de excepciones . . . . . . . . . . . . . . . . 44

5

ÍNDICE DE FIGURAS 6

4.1. Metaclases relacionadas con CppModel . . . . . . . . . . . . . . . 464.2. Metaclases relacionadas con CppPathReference y

CppPathReferentiable . . . . . . . . . . . . . . . . . . . . . . . . 474.3. Metaclases de archivos . . . . . . . . . . . . . . . . . . . . . . . . 484.4. Metaclases de tipos . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5. Metaclases de clases, estructuras y uniones . . . . . . . . . . . . 494.6. Metaclases de tipos primitivos . . . . . . . . . . . . . . . . . . . . 504.7. Metaclases de tipos Enum . . . . . . . . . . . . . . . . . . . . . . 504.8. Metaclases de acceso a variables . . . . . . . . . . . . . . . . . . . 514.9. Metaclases de métodos . . . . . . . . . . . . . . . . . . . . . . . . 524.10. Metaclases de bloques . . . . . . . . . . . . . . . . . . . . . . . . 524.11. Metaclases de invocación a métodos . . . . . . . . . . . . . . . . 534.12. Metaclases correspondientes a las expresiones de selección . . . . 554.13. Metaclases de expresiones iterativas . . . . . . . . . . . . . . . . 564.14. Metaclases de expresiones de selección múltiple . . . . . . . . . . 574.15. Metaclases de expresiones unarias y binarias . . . . . . . . . . . 584.16. Operadores usados en expresiones unarias y binarias . . . . . . . 584.17. Metaclases de expresiones de manejo de excepciones . . . . . . . 594.18. Metaclases de expresiones constantes . . . . . . . . . . . . . . . . 604.19. Metaclases de expresiones con arreglos . . . . . . . . . . . . . . . 604.20. Metaclases de expresiones de corte y continuación . . . . . . . . . 614.21. Metaclases de expresiones compuestas . . . . . . . . . . . . . . . 624.22. Metaclases de expresiones de casting . . . . . . . . . . . . . . . . 624.23. Metaclases de declaración de variables . . . . . . . . . . . . . . . 634.24. Metaclases de comentarios . . . . . . . . . . . . . . . . . . . . . . 64

5.1. Proceso de migración . . . . . . . . . . . . . . . . . . . . . . . . . 665.2. Clases principales de la aplicación . . . . . . . . . . . . . . . . . . 685.3. Diagrama de relaciones dentro del paquete mmclass . . . . . . . 695.4. Diagrama de paquetes del proyecto . . . . . . . . . . . . . . . . . 695.5. Transformación entre tipos primitivos de C++ a Haxe . . . . . . 715.6. Herramienta para la migración . . . . . . . . . . . . . . . . . . . 76

6.1. Programa simple en C++ (RectangleTesis.h) . . . . . . . . . . . 796.2. Programa simple en C++ (archivo.cpp) . . . . . . . . . . . . . . 806.3. Ejecución del programa simple en C++ . . . . . . . . . . . . . . 806.4. Programa simple en Haxe . . . . . . . . . . . . . . . . . . . . . . 836.5. Archivo CPPAutoGen del programa simple . . . . . . . . . . . . 836.6. Código Haxe modi�cado . . . . . . . . . . . . . . . . . . . . . . . 846.7. Ejecución del programa simple en Haxe . . . . . . . . . . . . . . 846.8. Ping Pong (main.cpp) . . . . . . . . . . . . . . . . . . . . . . . . 856.9. Ping Pong C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.10. Archivo Main.hx (Parte 1) . . . . . . . . . . . . . . . . . . . . . . 876.11. Archivo Main.hx (Continuación) . . . . . . . . . . . . . . . . . . 886.12. Archivo CppAutogen.hx . . . . . . . . . . . . . . . . . . . . . . . 886.13. Archivo String.hx . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

ÍNDICE DE FIGURAS 7

6.14. Archivo Stringstream.hx . . . . . . . . . . . . . . . . . . . . . . . 886.15. Ping Pong Haxe . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.16. Clásico juego de Tetris . . . . . . . . . . . . . . . . . . . . . . . . 926.17. Tetris compilado para Neko . . . . . . . . . . . . . . . . . . . . . 97

Capítulo 1

Introducción

Actualmente los dispositivos móviles acompañan a los usuarios en todomomento y lugar, y se prevé que serán el principal medio de acceso a Internet enlos próximos años, sin embargo, el desarrollo de aplicaciones de software móvilesno está lo su�cientemente maduro [34].

La proliferación de diferentes plataformas móviles ha forzado a losdesarrolladores a de�nir enfoques que permitan simpli�car el desarrollo deaplicaciones [21]. Los autores remarcan en [11] que dos de los principales desafíosde la ingeniería de software de aplicaciones móviles son por un lado, la creaciónde interfaces de usuario que abarquen diferentes clases de dispositivos móvilesy por otro, brindar aplicaciones reutilizables en múltiples plataformas.

Desarrollar una aplicación de software para un dispositivo móvil implicaadoptar y entender las características de estos dispositivos y sus restricciones.Si bien éstos cuentan con características avanzadas también se presentanimportantes restricciones. Por ejemplo, incorporan interfaces de entrada másintuitivas, usualmente, pantallas táctiles, bases de datos integradas, soportemultimedia y mecanismos de comunicación y geolocalización. También sepresentan importantes restricciones en cuanto al tamaño de la pantalladisponible, capacidad de procesamiento, la utilización de memoria primaria ylas bibliotecas de desarrollo disponibles [34].

Un problema actual es la rápida proliferación de plataformas móviles [21].El alto costo y la complejidad técnica de desplegar una aplicación a unamplio espectro de plataformas, fuerza a desarrollar aplicaciones alineadas acada tipo de dispositivo. Varias empresas tienen grupos de desarrollo paracada tipo de plataforma redoblando esfuerzos para aplicaciones móviles defuncionalidad similar. En aplicaciones multiplataforma, los desarrolladorespre�eren implementar una aplicación por vez, y desplegarla en diversasplataformas con un mínimo esfuerzo. En esta dirección, surgió el proyectoHaxe, que provee un lenguaje de programación de propósitos generales diseñadopara que los desarrolladores puedan, utilizando un solo lenguaje y un conjuntode librerías, abarcar distintas plataformas de manera e�caz. Actualmente, elcompilador de Haxe genera código para las siguientes tecnologías: JavaScript,

8

CAPÍTULO 1. INTRODUCCIÓN 9

Flash, NekoVM, PHP, C++ y C# [8] [10].Otro desafío en estos desarrollos es lograr integrar variedad de información

e interoperabilidad de herramientas. Model Driven Development (MDD) esconsiderado un enfoque promisorio para afrontarlo. MDD de�ne un amplio rangode desarrollos basados en el uso de modelos como entidades de primera clase.Una realización especí�ca de MDD, propuesta por OMG (Object ManagementGroup), es la arquitectura MDA (Model Driven Architecture) [28].

MDA propone separar la especi�cación de la funcionalidad del sistema de suimplementación sobre una plataforma en una tecnología especí�ca y controlar laevolución del software desde modelos abstractos a implementaciones tendiendoa aumentar el grado de automatización. Una de las características esencialesde MDA es que todos los artefactos involucrados en un proceso de desarrollo serepresentan a partir del lenguaje de metamodelado MOF (Meta Object Facility)[24]. Otro concepto fundamental es el de transformaciones entre modelos. EnMDA, una transformación es la especi�cación de mecanismos para convertirelementos de un modelo en elementos de otro modelo y el estándar propuestopor OMG para especi�car transformaciones es el meta modelo QVT (Query,View, Transformation) [31].

En el contexto de MDA, OMG está involucrado en el desarrollo de estándarespara la modernización de sistemas a través de la iniciativa ADM (ArchitectureDriven Modernization) [2] que lleva a cabo procesos de modernizaciónconsiderando los principios esenciales de MDA.

El proceso de modernización incluye tres etapas: ingeniería inversa,reestructuración e ingeniería directa. La ingeniería inversa, el proceso de analizarlos artefactos de software existentes para extraer información proveer vistasde alto nivel del sistema, es una etapa crucial dentro de la modernización delsistema. En el contexto de ADM, la meta de la ingeniería inversa es descubrirel conocimiento del sistema existente y producir modelos en diferentes nivelesde abstracción. Estos modelos serán el punto de partida para el proceso dereestructuración y la posterior generación del nuevo código.

El éxito de ADM y MDA depende de la existencia de herramientas CASEque soporten procesos tales como ingeniería inversa (reverse engineering) eingeniería directa (forward engineering). El proyecto Eclipse EMF (EclipseModeling Framework) se construyó para facilitar el modelado de sistemas yla generación automática de código Java. En el marco de EMF se de�nióel metamodelo Ecore que puede considerarse como la implementación o�cialde MOF, más precisamente de EMOF. EMF evoluciona con el aporte dela comunidad Eclipse brindando una variedad de herramientas altamenterelacionadas con MDD. Por ejemplo, el subproyecto Eclipse M2M soportatransformaciones modelo-a-modelo que, a partir de uno o más modelos,producen uno o más modelos de salida. El lenguaje ATL (Atlas TransformationLanguage) es un lenguaje de transformaciones provisto por un subproyectode EMF. Otro subproyecto es Acceleo, que implementa transformaciones M2T(modelo-a-texto) usadas en ingeniería directa.

MDA y ADM están integrada en Eclipse con Java y débilmente soportadospor otros lenguajes de programación tales como C++. En particular, numerosas


componentes desarrolladas en C/C++ deben ser modernizadas a �n deadaptarlas a nuevas tecnologías. EMF4CPP es el primer paso para proveer unconjunto de herramientas en Eclipse para MDD en C++ como una alternativa alas herramientas Eclipse desarrolladas en Java [41]. Especí�camente, EMF4CPPes una implementación en C++ del metamodelo Ecore que permite generarcódigo C++ desde metamodelos Ecore y analizar y serializar modelos ymetamodelos desde y hacia documentos XMI (XML Metadata Interchange).Sin embargo, no existe una de�nición del metamodelo C++ en Ecore. Esto esun requisito necesario para otros procesos MDD como por ejemplo de ingenieríainversa o modernización de software.

En esta tesis proponemos un proceso de migración desde software escritoen C/C++ a diferentes plataformas móviles a través de Haxe. En el contextode este trabajo se de�nió un metamodelo C++ a ser usado en procesos demodernización. El proceso propuesto sigue los principios de MDD: todos losartefactos involucrados en el mismo pueden verse como modelos que conformana un metamodelo, el proceso en sí mismo puede verse como una secuencia detransformaciones entre modelos y la información recuperada es representada enforma estándar a partir de metamodelos.

A continuación describimos las etapas del proceso de migración propuesto yla estructura de este documento.

1.1. Motivación

Es frecuente la necesidad de migrar componentes y aplicaciones de softwaredesarrollados en C/C++ a plataformas móviles y por ende es conveniente contarcon procesos genéricos reutilizables que la soporten. Esto puede lograrse a partirde procesos dirigidos por modelos integrados con el lenguaje multiplataformaHaxe.

En trabajos existentes no se ha encontrado una integración de C/C++con Haxe a partir de MDA y consideramos de interés de�nir procesos demigración que los integren teniendo en cuenta la cantidad de software de calidaddesarrollado en estos lenguajes que los programadores de aplicaciones móvilesdeben adaptar. Los procesos deberían incluir el análisis de código existentepara extraer modelos y la generación de código a partir de estos modelos paramúltiples plataformas móviles.

En MDD, las transformaciones entre modelos se expresan en lenguajesespecí�cos que permiten a los desarrolladores concentrarse en los aspectosconceptuales de las relaciones entre modelos y delegar el proceso detransformación. La generación de modelos a partir de transformaciones entremetamodelos en MDD apunta a generar modelos �correctos por construcción�con respecto a la especi�cación de metamodelos.

Este enfoque requiere contar con un metamodelo MOF de C/C++,produciendo además el bene�cio de otorgar a los desarrolladores MDD estemetamodelo y así la posibilidad de abordar otros escenarios de modernizaciónque involucren al lenguaje C/C++.


1.2. Descripción del proceso

El proceso de migración de C/C++ a plataformas móviles a través dellenguaje Haxe que se llevó a cabo en el presente trabajo puede verse grá�camenteen la Figura 1.1 y fue dividido en seis pasos. Los mismos son:

1. Especi�car un metamodelo del lenguaje origen (C/C++).

2. Especi�car un metamodelo del lenguaje destino (Haxe).

3. Ingeniería inversa de código C/C++ para creación del modelo queconforme al metamodelo correspondiente.

4. Transformación del modelo del lenguaje origen (C/C++) a un modelo queconforme al metamodelo del lenguaje destino (Haxe).

5. Realizar ingeniería directa desde el modelo del lenguaje destino (Haxe) atexto.

6. Compilación del código fuente a plataformas móviles.

Figura 1.1: Proceso de migración


1.3. Estructura del Informe

La continuación de este informe se encuentra estructurado de la siguientemanera:

El capítulo 2 describe el marco teórico utilizado para el desarrollo deltrabajo. En particular, se describen los conceptos fundamentales asociadoscon MDA, Ingeniería Inversa, ADM e Ingeniería Directa, así como losestándares de�nidos y herramientas existentes en este contexto.

El capítulo 3 describe el lenguaje Haxe y su metamodelo asociado utilizadopara el presente trabajo.

El capítulo 4 describe el lenguaje C/C++ y todos los componentes delmetamodelo desarrollado para el mismo.

En el capítulo 5 se muestran en detalle todos los pasos de la migración.En una primera sección, se explica en detalle la arquitectura y elfuncionamiento de la herramienta de ingeniería inversa creada para eldescubrimiento del modelo C/C++ a partir de código. En la segundasección se explican las transformaciones entre modelos llevadas a cabopara transformar un modelo C/C++ en un modelo Haxe, a través dereglas en el lenguaje ATL. Finalmente, se explica el proceso de ingenieríadirecta de modelo hacia texto.

En el capítulo 6 se realiza la evaluación del proceso mediante el desarrollode ejemplos concretos.

Finalmente, en el capítulo 7 se exponen las conclusiones del trabajo.

Capítulo 2

Estado del Arte

2.1. Model Driven Architecture

El Desarrollo Dirigido por Modelos (MDD) es un paradigma que utilizamodelos como artefactos primarios en el proceso de desarrollo. El ObjectManagement Group (OMG) [48] propone la Arquitectura Dirigida por Modelos(MDA) como la realización de esta iniciativa, donde los lenguajes de modeladoy de transformaciones son estandarizados. MDA fue adoptado como estándaren 2001 y está basado en otros estándares de modelado del OMG como UML(Uni�ed Modeling Language) , MOF (Meta Object Facility) y CWM (CommonWarehouse Metamodel). Su objetivo principal es separar la especi�cación dela funcionalidad del sistema de su implementación sobre una plataforma ytecnología especí�ca, y controlar la evolución del software desde modelosabstractos a implementaciones tendiendo a aumentar el grado de automatización[28].

La idea fundamental detrás de MDA es el uso de modelos para guiar elciclo de vida completo de un sistema. Todos los artefactos generados durante elproceso de desarrollo, tales como la especi�cación de requerimientos, descripciónde la arquitectura, descripciones de diseño y código, son vistos como modelos yel objetivo es tender a construir modelos capaces de ser interpretados de maneraautomática.

En especial, MDA pone énfasis en la creación de un modelo conceptual delsistema, independiente de la plataforma. Este modelo puede ser luego traducidoautomáticamente a un modelo especí�co para la plataforma seleccionada yposteriormente a código. La automatización de este proceso es esencial, y selogra de�niendo transformaciones entre modelos que permitan a herramientasllevar a cabo toda, o al menos parte, de la conversión. Una premisa claveen MDD es que los programas se generen automáticamente a partir de suscorrespondientes modelos.

Los bene�cios que otorga el uso del Desarrollo Dirigido por Modelos en el

13

CAPÍTULO 2. ESTADO DEL ARTE 14

desarrollo de software son:Portabilidad: MDA parte de un modelo de alto nivel de abstracción,

independiente de cualquier plataforma, y ese modelo puede ser transformadoen numerosos modelos que dependen de diferentes plataformas. Por lo tanto,cada modelo especi�cado independientemente de las plataformas es un modelocompletamente portable al que, para cada nueva tecnología y plataforma quesurja, solo será necesario de�nir las transformaciones correspondientes. Estopermite que se desarrollen nuevos sistemas basados en los modelos existentes dealto nivel.

Productividad: el aumento en la productividad está dado por la existenciade numerosas herramientas que permiten automatizar gran parte de lastransformaciones entre modelos de distintos niveles de abstracción.

Interoperabilidad: se debe establecer la relación entre los distintos modelosdependientes de plataformas, para alcanzar la interoperabilidad entre diferentesplataformas.

Mantenimiento y documentación: los modelos de alto nivel deabstracción son utilizados para generar modelos dependientes de una plataformay estos últimos para generar código fuente. Los modelos independientes deplataforma proveen la documentación de alto nivel necesaria para cualquiersistema.

2.1.1. Modelos

Los modelos son el componente principal dentro de MDA. Se podría decirque un modelo es una descripción de un sistema, o parte de él, escrito en unlenguaje bien de�nido. Es posible crear muchos tipos de modelos diferentespara un sistema, desde modelos abstractos que especi�can la funcionalidad enforma independiente de la plataforma, hasta modelos concretos vinculados conplataformas, tecnologías e implementaciones especí�cas.

En MDA, pueden distinguirse cuatro niveles de modelado en función de sugrado de abstracción. Como puede verse en la Figura 2.1, ellos son:

Computation-Independent Model (CIM): es el nivel más abstracto delmodelado. Representa el contexto, los requerimientos y el propósito del sistemadesde un punto de vista independiente de la computación. Es conocido comomodelo de dominio y ayuda a reducir la brecha existente entre los expertos enun dominio y los ingenieros de software. Puede consistir en modelos UML yotros modelos de requerimientos.

Platform-Independent Model (PIM): este nivel describe elcomportamiento y la estructura del sistema, independientemente de laplataforma. Puede verse como un modelo del sistema que será ejecutado poruna máquina virtual independiente de cualquier tecnología.

Platform-Speci�c Model (PSM): este modelo contiene toda lainformación necesaria del comportamiento y la estructura del sistema para unaplataforma especí�ca. Esta vista combina la especi�cación del sistema capturadaen el PIM con los detalles particulares de la tecnología en que se implementará.


Implementation-Speci�cic Model (ISM): es una descripción delsistema a nivel de código.

Figura 2.1: Modelos MDA

2.1.2. Metamodelos

En el contexto de MDA, es necesario que los modelos estén escritos en unlenguaje bien de�nido, es decir, un lenguaje formal. Una manera de de�nir taleslenguajes es mediante el uso de metamodelos. Un metamodelo es un modeloque de�ne un lenguaje para expresar modelos. Es una descripción de todos losconceptos que pueden ser usados en un modelo. Cada uno de los elementospresentes en un modelo debe estar de�nido en el metamodelo del lenguajeutilizado.

Como un metamodelo es también un modelo, el mismo debe estar escritoen un lenguaje bien de�nido. Este lenguaje, a su vez, puede ser expresadomediante un modelo. Por lo que un meta-metamodelo de�ne un lenguaje paraescribir metamodelos.

El OMG propone una arquitectura de modelado de cuatro capas para susestándares, donde cada nivel (excepto el superior) se caracteriza por conformaral nivel que está sobre él. Éstas capas se denominan M0, M1, M2 y M3:

Nivel M0 (sistema): en este se encuentran las instancias reales delsistema, es decir, los datos o información de dominio que se quiere representar.

Nivel M1 (el modelo del sistema): los conceptos que aparecen en estenivel son clasi�caciones o categorizaciones de las instancias que aparecen en elnivel M0. Cada elemento en el nivel M0 será una instancia de un elemento delnivel M1.


Nivel M2 (el modelo del modelo): cada elemento del nivel M1 es unainstancia de un elemento de M2, y cada elemento de M2 clasi�ca elementosde M1. El modelo que reside en este nivel se llama metamodelo. Cuando seconstruye un metamodelo se está de�niendo un lenguaje con el cual escribirmodelos. En este nivel se encuentran el metamodelo UML, CWM (CommonWarehouse Model) y SPEM (Software Process Engineering Metamodel) entreotros estándares de OMG.

Nivel M3 (el modelo del modelo del modelo): es la capa superior dela arquitectura. Al igual que en los niveles anteriores, cada elemento del nivelM2 es una instancia de un elemento de M3, y cada elemento de M3 clasi�caelementos de M2. El modelo en este nivel se llama meta-metamodelo que de�neel lenguaje para de�nir lenguajes de modelado. El lenguaje estándar de OMGdel nivel M3 es MOF [24].

Se podría seguir agregando niveles en la jerarquía, pero como esta separaciónde niveles es super�cial, ya que simplemente ayuda a razonar sobre modelos yclasi�caciones, OMG ha declarado que todos los elementos del nivel M3 debenser de�nidos como instancias de los conceptos del mismo nivel M3.

2.1.2.1. Meta Object Facility (MOF)

MDA se basa en el uso de un lenguaje para de�nir metamodelos denominadoMeta Object Facility (MOF) [24]. MOF provee un lenguaje formal paradescribir modelos y, a su vez, proporciona un lenguaje común para manipular eintercambiar dichos modelos. Al mismo tiempo, proporciona la base para de�niry ejecutar transformaciones, las cuales son un componente esencial dentro deMDA.

El requisito esencial para integrar diferentes lenguajes y herramientas es quelos lenguajes involucrados se de�nan (modelen) en MOF.

MOF es esencialmente un conjunto mínimo de conceptos que puedenutilizarse para de�nir otros lenguajes de modelado. Los conceptos de MOFderivan de los conceptos de�nidos en UML Infrastructure en el paqueteCore. En la de�nición de MOF 2.0 se incluyen dos meta-metamodelos: EMOF(Essential MOF ) y CMOF (Complete MOF ). El primero favorece la simplicidadde implementación por sobre la expresividad, mientras que el segundo es másexpresivo, pero más complejo. La variante Ecore que ha sido de�nido en elframework de modelado Eclipse es más o menos similar a EMOF.

Las construcciones de modelamiento más importantes que utiliza MOF son:Clases: que modelan metaobjetos MOF.Asociaciones: que modelan relaciones binarias entre metaobjetos.Tipos de datos: que modelan tipos primitivos.Paquetes: que modularizan los modelos.


2.1.3. Transformaciones

El Object Management Group de�ne transformación de modelos en elcontexto de MDA como �el proceso de convertir un modelo en otro modelodel mismo sistema�. La transformación de modelos es un concepto centraldentro del enfoque de MDD, ya que proporciona un mecanismo que permite,por un lado, conseguir una representación de todo un sistema al combinar susdiferentes modelos; por otro lado, organizar los modelos del sistema en distintosniveles de abstracción; y, por último, derivar el código fuente del sistemamediante sucesivas transformaciones entre modelos, desde la representaciónmás abstracta, pasando por la capa intermedia de modelos. Para ello, todatransformación toma un modelo como entrada y genera otro modelo como salida(Figura 2.2 [36]) que puede estar escrito en el mismo lenguaje o en un lenguajediferente al del modelo de entrada.

Las transformaciones son una parte fundamental dentro de MDA, dadoque constituyen el mecanismo que permite convertir de un modelo a otro, porejemplo, de un PIM a un PSM y de PSM a código. Realizar una transformaciónentre modelos requiere de un claro entendimiento de la sintaxis abstracta y lasemántica de los modelos origen y destino.

En MDA, las transformaciones también pueden ser vistas como modelos queconforman a un metamodelo.

Figura 2.2: Transformación MDA

Un desarrollo MDA que evoluciona desde modelos abstractos aimplementaciones, distinge las siguientes etapas (Figura 2.3):

1. Construir un CIM

2. Construir un PIM en un alto nivel de abstracción, independiente de unatecnología especí�ca y relacionado al CIM.

3. Transformar al PIM en uno o más modelos dependientes de la plataforma(PSM).

4. Transformar PSM a código.


Figura 2.3: Proceso MDA

Con el objetivo de reducir el esfuerzo y evitar la generación de errores, seha buscado automatizar el proceso de transformación de distintas formas. Porejemplo, a través lenguajes de propósito general, representaciones intermediaso lenguajes especí�cos de transformación. La alternativa de utilizar lenguajesespecí�cos de transformación es la que ofrece el mayor potencial.

2.1.3.1. Query-View-Transformation (QVT)

La especi�cación MOF 2.0 Query, View, Transformation es el estándarpropuesto por el OMG para especi�car transformaciones entre modelos [31]. Elacrónimo QVT hace referencia a:

Query: es una expresión consulta para seleccionar elementos de un modelo.El resultado es una o más instancias de los tipos de�nidos sobre el metamodelofuente.

View: vistas de metamodelos MOF.Transformation: proceso que genera un modelo destino a partir de un

modelo origen.

El estándar QVT está de�nido por un metamodelo basado en MOF quecomprende tres lenguajes para modelar transformaciones: dos de naturalezadeclarativa llamados Relations y Core, y uno de naturaleza imperativa llamadoOperational Mappings.

QVT de�ne un estándar para transformar un modelo origen en un modelodestino, donde ambos deben ser instancias de metamodelos MOF. Otracaracterística que posee es que la transformación es considerada en sí mismaun modelo que se ajusta a un metamodelo MOF. Una transformación QVTestá compuesta por un conjunto de reglas y un conjunto de parámetros de losmodelos asociados con la transformación.

El estándar QVT incluye sólo transformaciones modelo a modelo (M2M),en las que los modelos son instancias de metamodelos MOF 2.0. Lastransformaciones de tipo modelo a texto y texto a modelo no estáncontempladas.

2.1.3.2. ATLAS Transformation Language

ATL (ATLAS Transformation Language) es un lenguaje de transformaciónde modelos y un conjunto de herramientas que dan soporte a estastransformaciones desarrollado por el grupo AtlanMod (Inria, Ecole des Mines


de Nantes & LINA). La especi�cación del lenguaje ATL está dada tanto por unmetamodelo como por una sintaxis textual concreta.

ATL permite la programación declarativa e imperativa. La escrituradeclarativa permite simplemente expresar correspondencias entre los elementosdel origen y del destino. La escritura imperativa facilita la especi�cación deconstrucciones que difícilmente se pueden expresar de manera declarativa.

El ATL Integrated Development Enviroment (IDE) se encuentra desarrolladosobre la plataforma Eclipse. Proporciona una serie de herramientas de desarrolloque tienen como objetivo facilitar el diseño de las transformaciones ATL [44].

Un programa de transformación ATL se compone de reglas que de�nencómo se emparejan y navegan los elementos del modelo origen para crear einicializar los elementos del modelo destino. Cada uno de estos programasconstituye una transformación y se especi�ca mediante un módulo ATL.

Un módulo ATL está compuesto por los siguientes elementos:Encabezado: de�ne algunos atributos que se relacionan con el módulo de

transformación.Import: es una sección opcional que permite importar librerías ATL

existentes.Helpers: el conjunto de helpers en ATL puede verse como el equivalente de

los métodos Java.Reglas: el conjunto de reglas de�ne la forma en que se generan los elementos

del metamodelo destino a partir de los elementos del metamodelo origen.

EncabezadoLa sección de encabezado de�ne el nombre del módulo de transformación y

los nombres de las variables que identi�can a los modelos origen y destino. Lasintaxis es la siguiente:

El nombre del archivo ATL que contiene el código del módulo debecorresponderse con el nombre del mismo y debe tener la extensión .atl. Es posibledeclarar más de un modelo de entrada o de salida separándolos por coma. Dadoque el nombre de un modelo constituye su identi�cador en el contexto de latransformación, el nombre de los modelos declarados deben ser únicos.

ImportEsta sección opcional permite declarar qué librerías ATL deben ser

importadas. La declaración se realiza de la siguiente manera:


HelpersEl conjunto de helpers en ATL puede verse como el equivalente a los métodos

Java. Permiten de�nir código ATL que puede ser llamado desde diferentespuntos de una transformación. Un helper consta de los siguientes elementos:

un nombre (que se corresponde con el nombre del método);

un tipo de contexto, que de�ne el contexto en el que el atributo se de�ne;

un tipo de valor de retorno;

una expresión ATL que representa el código del helper;

un conjunto de parámetros opcional, en el que cada parámetro se de�nepor un par (nombre del parámetro, tipo del parámetro).

ReglasEn ATL se pueden distinguir tres tipos de reglas que se corresponden con

los dos modos de programación que provee ATL: las matched rules (asociadasa la programación declarativa), las lazy rules y las called rules (asociadas a laprogramación imperativa).

Matched rules: constituyen el núcleo de la transformación declarativa.Cada una de estas reglas se corresponde con un tipo de elemento determinado delmetamodelo de entrada y genera como resultado uno o más tipos de elementosdel metamodelo de salida. La regla especi�ca la forma en que los elementos delmodelo de salida deben inicializarse a partir de los elementos seleccionados delmetamodelo de entrada.

Una matched rule comienza con la palabra reservada rule y está compuestapor dos secciones obligatorias, source pattern y target pattern, y dos seccionesopcionales que corresponden a las variables locales y al bloque de sentenciasimperativas.

La sección de variables locales, cuando está de�nida, comienza con la palabrareservada using. Esta sección permite declarar e inicializar un conjunto devariables locales, que serán visibles en el ámbito de la regla actual.

El source pattern se de�ne luego de la palabra reservada from. Permiteespeci�car una variable para el tipo de elementos del modelo origen que seránalcanzados por la regla. Esto signi�ca que la regla generará elementos delmetamodelo destino por cada uno de los elementos del origen que coincida con eltipo del elemento de entrada. En algunos casos, puede que solo se quiera utilizarun subconjunto de elementos que conforman al tipo del elemento de entrada.Esto se consigue especi�cando una condición opcional para los elementos deentrada. De esta forma, la regla solo utilizará como entrada los elementos


que coincidan con el tipo indicado y, que además, veri�quen la condiciónespeci�cada.

El target pattern de una regla se introduce después de la palabra reservadato. Especi�ca los elementos que deben ser generados cada vez que un elementoen el modelo de entrada coincide con el source pattern de la regla, e indica cómoestos elementos que se generan deben inicializarse. Cada elemento declarado enel target pattern corresponde a un elemento en el metamodelo de salida con susrespectivos valores iniciales.

Finalmente, la sección imperativa opcional, que comienza con la palabrareservada do, permite especi�car código imperativo que se ejecutará luego de lainicialización de los elementos de salida generados por la regla.

Lazy rules: son similares a las matched rules, pero solo se aplican cuandoson llamadas por otra regla.

Called rules: estas reglas proveen algunas facilidad para la programaciónimperativa. Pueden verse como un tipo particular de helpers: deben ser llamadasexplícitamente para ser ejecutadas y aceptan parámetros. Sin embargo, adiferencia de los helpers, éstas pueden generar elementos del modelo destinode la misma manera en que lo hacen las matched rules.

Al igual que las matched rules, comienzan con la palabra rule y puedenincluir una sección opcional de variables locales. Sin embargo, como no debenseleccionar elementos del metamodelo de entrada, no incluyen un source pattern.Por esta razón, la inicialización de los elementos que se generen debe ser unacombinación de parámetros, variables locales y atributos del módulo. El targetpattern, el cual es opcional, se de�ne luego de la palabra reservada to.

Una called rule puede también tener una sección de sentencias imperativas.

2.2. Ingeniería Inversa

La Ingeniería Inversa es el proceso de analizar artefactos de softwareexistentes con el objetivo de extraer información y proveer vistas de mayor nivelsobre el sistema subyacente. La ingeniería inversa generalmente implica extraerartefactos de diseño y construir o sintetizar abstracciones menos dependientesde la implementación. Esto se realiza con el objetivo de lograr una mejorcomprensión del sistema y de su funcionamiento.

Se pueden distinguir tres procesos relacionados con la ingeniería inversa:re-documentación, recuperación del diseño y reestructuración.

Re-documentación : es la creación de representaciones alternativas paraartefactos de software dentro de un mismo nivel de abstracción, con elpropósito de obtener documentación acerca del sistema en estudio. Lasformas de representación resultantes son consideradas generalmente vistasalternativas del sistema.

Recuperación del diseño: reconstruye abstracciones de diseño a partirde una integración entre el código, la documentación de diseño existente (siexiste), la experiencia personal, y el conocimiento general sobre el dominio.


Reestructuración: es la transformación de un artefacto de softwarede una forma de representación a otra, preservando el comportamientoexterno del artefacto.

Se pueden distinguir algunos objetivos que motivan el desarrollo y aplicación detécnicas de ingeniería inversa sobre un sistema de software. Estos son: lidiarcon la complejidad y volumen de los sistemas, generar vistas alternativas,recuperar información perdidad, detectar efectos colaterales y anomalías,sintetizar abstracciones de más alto nivel, y facilitar el reuso.

La ingeniería inversa constituye un proceso de análisis del software. Estatarea de comprender un sistema existente es altamente costosa (en términosde tiempo y recursos), por lo que cualquier solución que ayude y permitaautomatizar, aunque sea parcialmente, este proceso resulta de gran utilidad.La Ingeniería Dirigida por Modelos (MDE) ofrece una solución prometedorapara este problema, dado que provee nociones y herramientas para representarsistemas complejos mediante modelos, ofreciendo así artefactos de software másmaleables y transformables.

La Model Driven Reverse Engineering (MDRE) es la aplicación de losprincipios y técnicas de MDE para la ingeniería inversa. El objetivo es obtenervistas basadas en modelos, facilitando de esta forma el entendimiento ymanipulación de dichos sistemas. Por lo que, se puede utilizar MDRE paradescubrir modelos de los componentes de un sistema y poder procesar estosmodelos para generar nuevas vistas [5]. La iniciativa que propone el OMG paraMDRE es Architecture Driven Modernization (ADM), que será detallada enprofundidad en la siguiente sección.

Una arquitectura básica para describir las herramientas de ingeniería inversase puede ver en la Figura 2.4, propuesta por Chikofsky y Cross [45].

Figura 2.4: Arquitectura de las herramientas de ingeniería inversa

El producto de software que está bajo estudio es analizado y los resultadosson almacenados en una base de información. Cuando se diseña una base,es conveniente hacerlo usando un esquema común compartido por diferentes


herramientas. Los esfuerzos en esta dirección produjeron esquemas como elLenguaje de Intercambio de Grafos (GXL) [49], el Formato Estándar de Rigi(RSF) [50], el Metamodelo FAMIX utilizado por Moose o el Metamodelo deDescubrimiento de Conocimiento (KDM), propuesto por el OMG.

Los datos de la base de información luego son utilizados por los compositoresde vistas para producir vistas alternativas del producto de software. De acuerdoa las técnicas de ingeniería inversa utilizadas se pueden distinguir algunosartefactos. Si se utiliza análisis estático se pueden distinguir documentación deusuario, requerimientos, modelos de diseño y código fuente; si el análisis fueradinámico, trazas de ejecución y registros de utilización de memoria.

El rol de la ingeniería inversa, en relación con estos artefactos, es:

Reconstruir artefactos no disponibles o que no re�ejan el sistema bajoestudio.

Construir otras vistas de alto nivel para proveer información necesariapara entender el sistema.

Proveer la información necesaria para realizar tareas de cambios en elsoftware en un escenario de reingeniería dirigida por modelos.

Muchos de estos artefactos pueden no estar disponibles y, en muchos casos,solamente se contará con el código fuente o aún peor, los binarios de un sistemacomo documentación del mismo. Para recuperar la información necesaria quepermita construir los artefactos deseados y, por ende, entender el sistemade software bajo estudio, la ingeniería inversa ha evolucionado incorporandodistintos tipos de técnicas para aplicar durante el análisis.

2.3. Ingeniería Directa

La Ingeniería Directa es el proceso de moverse desde niveles de abstracciónaltos y diseños lógicos, independientes de la implementación, hasta laimplementación física de un sistema. La ingeniería directa sigue una secuenciade etapas que van desde el análisis de requerimientos hasta el diseño de laimplementación.

La adopción del Desarrollo Dirigido por Modelos (MDD) puedesimpli�car drásticamente el desarrollo hacia múltiples dispositivos, reduciendosustancialmente el costo y el tiempo. Cuando se sigue un enfoque MDD, hayvarias estrategias de llegar a la generación de código dependiendo del nivel deabstracción utilizado para modelar la aplicación y del nivel de abstracción delcódigo que se generará.

En particular, en MDA los tres niveles de abstracción son: ComputationIndependent Models (CIM), Platform Independent Models (PIM), y PlatformSpeci�c Models (PSM). Un conjunto de mapeos entre cada nivel y elsiguiente pueden ser de�nidos a través de transformaciones entre modelos.Especí�camente, cada CIM puede ser transformado en diferentes PIMs, los


cuales pueden ser transformados a PSMs. Sin embargo, se pueden dar algunasotras combinaciones, por ejemplo, omitiendo algún nivel.

A continuación se describen en detalle los diferentes enfoques posibles parala generación de código para aplicaciones móviles representados en la Figura 2.5[35].

Figura 2.5: Estrategias de generación de código

PIM-to-Native Code (NC): el enfoque PIM-a-NC establece que elcódigo de aplicación se genera a partir del PIM. Para llegar a múltiplesplataformas, se deberá proporcionar una nueva transformación para elcódigo nativo de cada una de ellas.

PIM-to-PSM-to-NC: este enfoque consiste, en primer lugar, en laespeci�cación de la aplicación de manera independiente de la plataformaque será utilizada para implementar el código ejecutable a travésde un PIM. El segundo paso, es la creación de diferentes PSMs,uno para cada plataforma especí�ca, a través de transformacionesmodelo-a-modelo. Estos modelos PSMs serán la entrada del generador decódigo para las plataformas correspondientes, a través de transformacionesmodelo-a-texto.

PSM-to-NC: consiste en de�nir directamente los PSMs, uno por cadaplataforma de desarrollo y luego generar el código desde estos PSMs,omitiendo el nivel de abstracción de PIMs.

PIM-to-Cross Platform Code (CPC): proporcionar unaimplementación nativa no siempre es conveniente, debido a los costosen el desarrollo que la misma conlleva (recursos y tiempo asociado conla actividad para cada plataforma). La utilización de un código destinoque permita utilizarse en múltiples plataformas simpli�ca la tarea ydisminuye los costos, a costa de perder el control de la parte nativa de lasaplicaciones.

PIM-to-Framework Speci�c Model (FSM)-to-CPC: con respectoa la opción PIM-a-CPC, este enfoque introduce el Modelo Especí�codel Framework. Este modelo contiene la información que el framework


multiplataforma utiliza para generar las aplicaciones. Especí�camente, unFSM es un PSM en el que la plataforma es un framework multiplataformapara el desarrollo de aplicaciones móviles. En la Figura 2.6 [35] puede versegrá�camente este proceso.

Figura 2.6: Estrategia PIM-to-Framework Speci�c Model (FSM)-to-CPC

2.4. Architecture Driven Modernization

La modernización de sistemas legados es una nueva área de investigaciónen la industria del software que está destinada a proporcionar apoyo para latransformación de un sistema de software existente a uno nuevo que satisfagalas nuevas demandas. Esta tarea requiere marcos técnicos para la integraciónde la información y herramientas de interoperabilidad que permita la gestión delas nuevas plataformas, técnicas de diseño y procesos. La iniciativa del OMG(Object Management Group) para la modernización es la Architecture DrivenModernization (ADM). En 2003, el OMG conformó el Architecture-DrivenModernization Task Force (ADMTF) con el objetivo de crear especi�cacionesy generar consenso dentro de la industria del software en relación a lamodernización de sistemas legados. Este grupo elaboró y publicó en una hojade ruta que dejó sentado un plan para la de�nición de una serie de estándaresde modernización [2].

Entre los estándares de�nidos por el ADMTF se encuentran KnowledgeDiscovery Metamodel (KDM) [18] y Abstract Syntax Tree Metamodel (ASTM)[3]. KDM de�ne una especi�cación que permite representar informaciónsemántica de un sistema, mientras que ASTM establece una especi�caciónpara representar la sintaxis del código fuente por medio de árboles de sintaxisabstracta. ASTM actúa como la base para modelar software dentro delecosistema de estándares del OMG, mientras que KDM sirve como puerta deentrada a los modelos del OMG de más alto nivel. A su vez, ASTM complementaKDM proveyendo un framework para efectuar mapeos entre modelos de softwarede bajo nivel representados en ASTM, y vistas conceptuales de alto nivelrepresentadas en KDM y otros estándares de modelado del OMG, como UML.

Hasta la fecha, ADMTF ha publicado KDM (Knowledge DiscoveryMetamodel), ASTM (Abstract Syntax Tree Metamodel) y SMM (Software


Metrics Metamodel).El proceso de modernización incluye tres etapas: la ingeniería inversa, la

reestructuración y la ingeniería directa. La ingeniería inversa, es el proceso deanálisis de los artefactos de software disponibles con el �n de extraer informacióny proporcionar puntos de vista de alto nivel del sistema. En el contexto deADM, el objetivo de la ingeniería inversa es descubrir el conocimiento de lasolución existente y producir modelos con diferentes niveles de abstracción. Estosmodelos son el punto de partida para el proceso de reestructuración y generacióndel nuevo sistema (ingeniería directa). El éxito del enfoque ADM depende dela existencia de herramientas CASE que ayuden en la automatización de cadaetapa del proceso de modernización.

2.4.1. Knowledge Discovery Metamodel (KDM)

El estándar KDM de�ne un metamodelo para el descubrimientode conocimiento en software independiente de cualquier lenguaje deimplementación y plataforma. Su objetivo es proporcionar un formato comúnpara el intercambio de metadatos de aplicaciones facilitando la interoperabilidadentre herramientas [18].

El metamodelo representa los activos de software en varios niveles deabstracción como entidades, relaciones y atributos. Está especi�cado en MOFy utiliza como lenguaje de intercambio XMI.

La especi�cación está organizada en las siguientes 4 capas y, a su vez,cada capa se organiza en paquetes que de�nen un conjunto de elementos delmetamodelo cuya �nalidad es representar un cierto aspecto independiente delconocimiento en relación con los sistemas de software existentes. Las capas son:

Capa de Infraestructura: esta capa está conformada a su vez por trespaquetes: el paquete Core que provee las construcciones básicas para creary describir clases del metamodelo, el paquete Kdm que describe diferenteselementos de infraestructura que se encuentran presentes en cada una delas instancias KDM y, por último, el paquete Source que representa losartefactos físicos de un sistema existente como entidades KDM y especi�cael mecanismo de trazabilidad que permite asociar elementos KDM consu representación �original� en el código fuente del sistema de softwarerepresentado. El paquete kdm junto con los elementos de�nidos en elpaquete Core constituyen el KDM Framework.

Capa de Elementos del Programa: esta capa provee una representaciónintermedia para construcciones comunes a los lenguajes de programación.De�ne un único modelo KDM (CodeModel) y está compuesta por lospaquetes Code y Action. El paquete Code representa elementos de códigodeterminados por los lenguajes de programación (tipos de datos, clases,métodos, variables) y las relaciones estructurales existentes entre ellos. Elpaquete Action captura los elementos de bajo nivel que determinan el �ujode control y �ujo de datos entre componentes del código.


Capa de Recursos de Ejecución: representa el entorno operacionaldel sistema existente y está formada por cuatro paquetes: Platform(representa los recursos de la plataforma de ejecución tales comocomunicación entre procesos, el uso de registros y manejo de datos), UI(representa el conocimiento relacionado con las interfaces de usuario),Event (contiene el conocimiento asociado a eventos y transiciones deestado) y Data (representa el conocimiento relacionado con la persistenciade datos).

Capa de Abstracciones: esta capa representa abstracciones del dominioy de la aplicación así como artefactos relacionados con el procesode compilación del sistema de software existente. Está compuesta portres paquetes: Conceptual (provee construcciones para crear un modeloconceptual durante la fase de análisis al realizar el descubrimiento deconocimiento de código existente), Structure (representa la organizaciónlógica del sistema de software en subsistemas, capas y componentes) yBuild (representa la vista de ingeniería del sistema de software, esto es, lainformación relacionada con su proceso de compilación).

2.4.2. Abstract Syntax Tree Metamodel (ASTM)

En el contexto de MDD, los Árboles de Sintaxis Abstracta (AST) sonutilizados como un modelo del código fuente [3]. En este sentido, ASTMestablece una especi�cación para representar árboles de sintaxis abstracta,es decir, provee una de�nición de los elementos utilizados para componermodelos AST. Un modelo AST es un modelo que describe como se estructuranlas sentencias de un programa de acuerdo a la gramática del lenguaje deprogramación particular en que el programa se encuentra implementado. Paraproporcionar uniformidad y al mismo tiempo un framework universal capaz deser extendido, la especi�cación ASTM se compone de:

El Metamodelo de Árbol de Sintaxis Abstracta Genérico (GASTM):representa un conjunto genérico de elementos para modelar lenguajescomún a numerosos lenguajes de programación, constituyendo, de estaforma, un core común para el modelado de lenguajes.

Los Metamodelos de Árbol de Sintaxis Abstracta Especializado(SASTMs): representan un conjunto de especi�caciones complementariasque extienden el core genérico para lenguajes tales como Ada, C, Fortran,Java, etc. Estas especi�caciones se encuentran modeladas en MOF oformas compatibles con MOF y expresadas en términos del metamodelogenérico junto con extensiones de modelado que permiten capturar lasparticularidades del lenguaje especí�co.

Los Metamodelos de Árbol de Sintaxis Abstracta Propietario (PASTMs):expresan árboles de sintaxis abstracta para lenguajes como Ada, C,COBOL, etc. modelados en formatos que no son compatibles con MOF,GASTM o SASTM.

Capítulo 3

Lenguaje Haxe

El proyecto Haxe fue iniciado en el año 2005 por el desarrollador francésNicolas Cannase y consta de un lenguaje de programación open source dealto nivel y un compilador. El lenguaje es orientado a objetos, aunque concaracterísticas funcionales y fuertemente tipado, con una sintaxis similar aECMAScript. Empleando las abstracciones correctas, es posible mantener unúnico código base para múltiples plataformas.

Actualmente, hay nueve lenguajes de destino compatibles que permitendiferentes casos de uso: Javascript, Neko, PHP, Python, C++, Actionscript3,Flash, Java y C# (Figura 3.1) [46].

Figura 3.1: Lenguajes de destino de Haxe

Dado que el lenguaje Haxe puede ser compilado para diferentes plataformas,es muy útil en una amplia variedad de dominios como lo son juegos, aplicacionesweb, aplicación móviles, entre otros.

28

CAPÍTULO 3. LENGUAJE HAXE 29

Algunos casos conocidos en los que se usó este lenguaje son (Figura 3.2):

Papers, Please: es un videojuego tipo rompecabezas que se enfoca en lacarga emocional que supone trabajar como inspector de aduanas en el�cticio estado comunista de Arstotzka, decidiendo quién entra o no en elpaís.

Evoland: es un videojuego que traza la historia de los videojuegos. Amedida que el jugador progresa, el o ella desbloquea nuevas tecnologías ymejoras grá�cas que hacen referencia a diferentes eras de la industria delos videojuegos.

Rymdkapsel: es un videojuego donde se toma el mando de una estaciónespacial y se debe plani�car su expansión y administrar sus recursos paraexplorar la galaxia.

Castle DB: es una base de datos estructurada para facilitar la colaboraciónen proyectos de juegos. Construida con y para Haxe.

Nape Physics Engine: es un motor potente y rápido de física 2D disponiblepara Haxe y escrito en Haxe.

Además, Haxe cuenta con numerosas bibliotecas que facilitan muchascaracterísticas al desarrollador, como lo son OpenFL [37], HaxeFlixel [38],HaxePunk [39], entre otras.

Figura 3.2: Videojuegos en los que se usó Haxe


Algunas compañías que están utilizando Haxe en sus proyectos son: Prezi,BBC, Nickelodeon, Disney, Coca Cola, Mattel, Hashbro, Toyota, Massive, Area9, etc.

La plataforma Haxe se encuentra integrada con MDA, ya que se encuentrade�nido un metamodelo Ecore de la misma y un generador de código [12]. Laintegración de esta plataforma permite la de�nición de procesos tales como losde ingeniería inversa e ingeniería directa en forma rigurosa y sistematizada queinvolucra a Haxe como plataforma de desarrollo.

El metamodelo utilizado se encuentra expresado en Ecore para el lenguajeHaxe en su versión 3.1.3. Desde la óptica de MDA, las instancias del metamodelocorresponden a un modelo especí�co de la plataforma, o PSM.

A continuacion se explicarán brevemente las metaclases que componen elmetamodelo que se encuentra en el Apéndice A [12].

3.1. Metaclases Principales

Las metaclases principales del metamodelo son aquellas que permiten laespeci�cación de una aplicación utilizando a Haxe como lenguaje y se muestranen la Figura 3.3. Una de las más importantes del metamodelo es HaxeModel,la cual sirve de contenedora de los elementos utilizados para describir unaaplicación y almacenar información adicional sobre la misma.

Las metaclases utilizadas directamente por HaxeModel son HaxeModule(para acceder a los distintos módulos de Haxe usados en el proyecto) yHaxePathReferentiable (para acceder a los distintos elementos del árbol depaquetes que son declarados en el proyecto y para acceder a los elementos alos que se hace referencia en el proyecto, pero que no han sido de�nidos demanera completa para el mismo). La metaclase HaxePathReferentiable (padrede las metaclases HaxeType y HaxePackage) es utilizada para poder aceptar elalmacenamiento de tipos que estén contenidos en la raíz del árbol de paquetes.

Adicionalmente, por medio de la relaciónmainClass, la metaclase HaxeModelpuede referenciar a una clase capaz de ser usada como punto de entrada almomento de la ejecución del proyecto cuando ya esté compilado.


Figura 3.3: Metaclases principales del metamodelo de Haxe

Para modelar las características más comunes del metamodelo, seencuentran las metaclases abstractas HaxeModelElement, HaxeNamedElementy HaxeASTNode (Figura 3.4).

Figura 3.4: Metaclases de las características más comunes del metamodelo deHaxe


3.1.1. Metamodelado de módulos

La metaclase HaxeModule permite modelar el concepto de módulo o unidadde compilación. Además, la relación de composición con la metaclase HaxeFieldpermite expresar las relaciones de uso estáticas, las cuales permiten usarmétodos estáticos de clases sin referenciar directamente a la clase a la quepertenecen en el ámbito de la unidad de compilación.

3.1.2. Metamodelado de comentarios

Los distintos tipos de comentarios están modelados mediante metainstanciasde la metaclase HaxeComment, y, según el tipo de comentario, asignando elvalor correspondiente al atributo lineComment para comentarios de una omúltiples líneas, o utilizando la metaclase HaxeHaxedocComment en el casode comentarios que correspondan a la documentación (Figura 3.5).

Figura 3.5: Metaclases de modelado de comentarios

3.1.3. Metamodelado de paquetes

Los paquetes de Haxe permiten agrupar lógicamente distintas declaracionesde tipos y asociarlas a un determinado nombre. Los paquetes pueden seragrupados de manera jerárquica, incluso con otros tipos. Esto está modeladomediante la metaclase HaxePackage. Mediante las relaciones childrenPackages yparentReference, es posible acceder a los paquetes hijos y padre respectivamente,y por medio de la relación containedTypes se contienen a los tipos declarados


para ese paquete. Mediante el par de metaclases HaxePathReferentiable yHaxePathReference, se encuentran modelados, de manera abstracta, aquellostipos que pueden ser referenciados, y las referencias en sí que pueden ocurrir endistintos ámbitos de un programa Haxe.

3.2. Metaclases de Tipos

Las metaclases representativas de los distintos tipos de Haxe, que se observanen la Figura 3.6, permiten expresar los diferentes tipos que pueden ser declaradoso utilizados en un proyecto Haxe. En el metamodelo existen metaclases paracubrir cinco de las siete clases de tipos disponibles. En particular, para lostipos Clase (los tipos clase e interfaz), Enumeración, Función, Tipo Abstract yEstructura Anónima.

Además, se encuentran clases como HaxeTypeAccess, la cual permiteespeci�car referencias a tipos de manera abstracta.

Figura 3.6: Metaclases para el modelado de tipos

3.2.1. Metamodelado de clases e interfaces

A través de la metaclaseHaxeClass se modelan las distintas clases e interfacesque aparecen en un proyecto.

HaxeClass tiene una relación de composición con la metaclase HaxeField, quecontiene a todos los elementos que de�nen la estructura de la clase, como sonlos métodos, constructores, atributos y propiedades. De HaxeFields se derivanlas relaciones HaxeConstructors, HaxeOperations y HaxeAttribute, obteniendode ellas todos los constructores, operaciones y atributos de una determinadaclase o interfaz. Las relaciones de herencia entre clases e interfaces Haxe,la generalización y la implementación, se encuentran modeladas mediante lasrelaciones implementation y generalization (Figura 3.7).


Figura 3.7: Metamodelado de clases e interfaces

3.2.2. Metamodelado de tipos de datos algebraicos

El lenguaje Haxe incluye un mecanismo para declarar tipos algebraicos dedatos generalizados, los cuales son declarados utilizando la palabra reservadaenum. En el metamodelo se encuentra implementada esta característica a travésde las metaclases HaxeEnum y HaxeEnumConstructor, como se ve en la Figura3.8.

Figura 3.8: Metamodelado de enumeraciones


3.2.3. Metamodelado de tipos abstractos

Los tipos abstract permiten agregar funcionalidad a otro tipo Haxe que hayasido declarado anteriormente. Estos tipos se encuentran modelados mediante laclase HaxeAbstract, como se muestra en la Figura 3.9. La misma tiene tresrelaciones que son underlyingType (que hace referencia al tipo subyacente deltipo abstract) y las referencias directCastingFromType y directCastingToType(que modelan las referencias a los tipos usados para realizar conversionesimplícitas desde o hacia el tipo abstract declarado).

Figura 3.9: Metaclases de tipos abstractos

3.2.4. Metamodelado de alias de tipos Typedef

Los tipos typedef de Haxe permiten asignar un nombre de tipo a unaocurrencia de algún otro tipo, de manera análoga a un alias. Los mismos seencuentran modelados a través de una única relación de composición, llamadarefType, la cual hace referencia a una instancia de HaxeTypeAccess.

3.2.5. Metamodelado de metadatos

Los metadatos de Haxe, permiten agregar información a distintos elementosdel lenguaje. Éstos, en términos sintácticos, consisten de un nombre, yun conjunto opcional de valores. Para ello, se encuentra la metaclaseHaxeMetadata la cual tiene una relación de composición con la metaclaseHaxeMetadataContainer, como se aprecia en la Figura 3.10. Esta metaclase esheredada por los elementos que pueden ser anotados con metadatos, como son lasmetaclases abstractas HaxeClassi�er y HaxeField, dado que son los elementosque, por de�nición del lenguaje, pueden ser anotables.


Figura 3.10: Metaclases de metadatos

3.2.6. Metamodelado de elementos parametrizados

Las características que permiten la parametrización de distintoselementos de Haxe se encuentran implementadas a través de la metaclaseHaxeTypeParameter. Las distintas instancias de esta metaclase pueden agregarsemediante composición a las relaciones typeParameter declaradas en lasmetaclases HaxeType y HaxeAbstractFunction, que son los elementos que puedenalojar estas declaraciones (Figura 3.11).


Figura 3.11: Metaclases de elementos parametrizados

3.3. Metaclases de Expresiones

3.3.1. Metamodelado de expresiones compuestas

Dentro de las metaclases de expresiones, existen metaclases que tienenrelaciones de composición con la metaclase HaxeExpression. Por ejemplo,HaxeBlock, la cual por medio de la relación de composición statementsse compone de un conjunto, posiblemente vacío, de expresiones Haxe; ola metaclase HaxeExpressionStatement, la cual sirve para separar distintasexpresiones en forma de secuencia.

3.3.2. Metamodelado de constantes

Para las constantes de Haxe, se encuentran de�nidas las metaclasescorrespondientes a los seis tipos de constantes aceptadas por Haxe (Figura 3.12):HaxeStringLiteral, HaxeNullLiteral, HaxeBooleanLiteral, HaxeNumberLiteral,HaxeIdenti�erLiteral y HaxeRegexLiteral.

Figura 3.12: Metaclases de expresiones constantes


3.3.3. Metamodelado de operaciones aritméticas

Para las operaciones aritméticas que pueden realizarse en Haxese encuentran, en principio, dos metaclases abstractas (Figura 3.13):HaxeUnaryExpression y HaxeBinaryExpression con las cuales se expresanoperaciones con uno y dos operandos, respectivamente. Dependiendo delorden entre operador y operando y, para las operaciones binarias hay dosmetaclases: HaxeIn�xExpression, la cual permite expresar operaciones in�jasde dos o más términos y HaxeAssignment, la cual solamente requiere de dosoperandos y expresa las distintas asignaciones posibles de realizar. En el casode las operaciones unarias, dependiendo de la posición del operador existen:HaxePost�xExpression y HaxePre�xExpression.

Figura 3.13: Metaclases de operaciones aritméticas

3.3.4. Metamodelado de vectores o arreglos

Aunque el lenguaje Haxe no provee tipos vector o arreglo comoconstrucciones sintácticas del lenguaje, éste sí es provisto mediante un tipo,llamado Array<T>, que aparece declarado en las librerías provistas por laplataforma. Para esto, en el metamodelo se encuentran dos metaclases, las cualespueden verse en la Figura 3.14: HaxeArrayInitializer, que corresponde con uninicializador de arreglos, y HaxeArrayAccess, que modela las expresiones queacceden como arreglo, mediante una expresión índice.


Figura 3.14: Metaclases de arreglos

3.3.5. Metamodelado de expresiones de selección

Las expresiones condicionales de Haxe permiten, dada una expresiónbooleana, elegir entre dos �ujos de programa distintos o dos expresionesdistintas. Para ello, existe una metaclase, HaxeConditionalExpression, conlas relaciones comunes para las expresiones de selección, realizadas con lasmetaclases concretas HaxeIfStatement y HaxeTernaryExpression (Figura 3.15).

Figura 3.15: Metaclases de expresiones de selección

3.3.6. Metamodelado de expresiones de selección múltiple

Las expresiones de selección múltiple (switch) permiten, a partir de unaexpresión, elegir entre varios caminos de ejecución según el valor obtenidode evaluar esta última. Las metaclases HaxeCase y HaxeSwitch permitenescribir este tipo de expresiones de selección. La metaclase HaxeSwitch permitecrear sentencias switch a través relaciones de composición con las metaclasesHaxeCase y HaxeExpression, como se ve en la Figura 3.16.


Figura 3.16: Metaclases de expresiones de selección múltiple

3.3.7. Metamodelado de expresiones de iteración

Para las estructuras de control, se encuentra una metaclase abstracta,llamada HaxeLoopStatement, que contiene los elementos comunes a lasexpresiones de control. Las metaclases hijas, en particular HaxeWhileStatementy HaxeDoWhileStatement, si bien no cuentan con más atributos y relaciones quesu clase padre, permiten expresar las diferencias de orden entre el cuerpo y lacondición de corte del bucle.

Para la expresión for de Haxe, que comparte una sintaxis similar con lasentencia Enhanced For de Java, existe la metaclase HaxeForStatement, la cualestá relacionada con la metaclase HaxeSingleVariableDeclaration. Esta relacióncon esta metaclase modela la ocurrencia de la variable de iteración del bucle, enla cual se almacenan los distintos valores que se obtienen durante la iteración.

El metamodelado de expresiones de iteración se encuentra visualmente en laFigura 3.17.

Figura 3.17: Metaclases de expresiones de iteración

3.3.8. Metamodelado de expresiones de corte ycontinuación del �ujo de ejecución

Las expresiones de corte y continuación, conocidas como break y continue,permiten escapar de un bucle de expresiones o seguir su iteración sin ejecutar las


instrucciones posteriores. Esto se encuentra modelado a través de las metaclasesHaxeBreak y HaxeContinue y se puede observar en la Figura 3.18.

Figura 3.18: Metaclases de expresiones de corte y continuación de ejecución

3.4. Metamodelado de declaraciones de variables

La metaclase que permite expresar las distintas combinacionesposibles de declaraciones de variables es HaxeVariableDeclaration.Esta metaclase es la base para la declaración de variables, y luegose encuentran dos metaclases hijas, como se ve en la Figura 3.19,HaxeVariableDeclarationFragment y HaxeSingleVariableDeclaration. Unainstancia de HaxeSingleVariableDeclaration representa la declaración de unsolo identi�cador con, opcionalmente, algún tipo asignado o algún valor pordefecto. Para el modelado de las declaraciones múltiples de variables, hay unametaclase adicional, llamada HaxeVariableDeclarationGroup, que representa unconjunto de variables asociadas a un mismo tipo.

Figura 3.19: Metaclases de variables


3.4.1. Metamodelado de atributos de instancia y de clase

Para modelar los atributos de instancia y de clase de Haxe existe la claseHaxeAttribute. Esta metaclase puede expresar simultaneamente una propiedado una variable de clase. Las propiedades extienden el concepto de las variables declase y brindan características que permiten un control de acceso granularmentemás �no a los valores de los atributos.

3.5. Metaclases de funciones y métodos

En el metamodelado de funciones y operaciones, existe una metaclase basepara modelar todos los tipos de funciones que pueden ser declaradas, que esHaxeAbstractFunction, metaclase que contiene dos relaciones de composiciónbásicas para las funciones, que son la relación theBody (que modela elcuerpo de la función) y la relación formalParameters (que modela la lista deparámetros formales), como se ve en la Figura 3.20. Esta metaclase base esluego especializada por HaxeFunctionExpression, la cual realiza las funcioneslocales, y HaxeAbstractOperation, que es la metaclase base que modela losdistintos métodos y constructores; y luego, las metaclases HaxeOperation yHaxeConstructor que corresponden a las distintas funciones y constructores enparticular.

El modelado de las distintas invocaciones a métodos yfunciones locales está dado por las metaclases HaxeCallExpression yHaxeAbstractMethodInvocation. Esta última metaclase es luego especializadapor las metaclases HaxeMethodInvocation, HaxeSuperMethodInvocation yHaxeSuperConstructorInvocation, que son utlizadas para realizar las llamadasa métodos, llamadas a constructores de la clase padre y las invocaciones amétodos sobrecargados.

Figura 3.20: Metaclases de funciones


3.6. Metaclases de expresiones de acceso yconstrucción de objetos

La metaclase HaxeThisExpression modela las expresiones que, en el contextode un método, acceden al objeto actual que recibe una llamada a método, siendoéste expresado por la palabra reservada this.

En la metaclase HaxeSuperConstructorInvocation, se modelan las llamadas aconstructores pertenecientes a la clase padre, los cuales son usados en el ámbitode los constructores de clase y con la metaclase HaxeSuperMethodInvocation,se modelan las llamadas a los métodos pertenecientes a las clases padre, loscuales no podrían ser accedidos si estos fueran sobrecargados por clases másespecializadas (Figura 3.21).

Figura 3.21: Metaclases de acceso a objetos

3.7. Metaclases de expresiones de conversión ychequeo de tipos

Las expresiones de conversión de tipos (casting) permiten cambiar lainterpretación de un valor de una expresión a la de un tipo distinto alesperado. En el lenguaje Haxe, fueron de�nidas dos tipos de conversiones,una que retorna el valor de una expresión convertida convenientemente aun tipo predeterminado (casting seguro) y, la otra, envuelve el valor enuna instancia de un tipo monomorph, el cual luego el compilador determinamediante uni�cación, si esta nueva expresión puede ser usada en expresionessubsiguientes (casting inseguro). El metamodelo, como se ve en la Figura 3.22,implementa dos metaclases para las conversiones de tipos, una denominadaHaxeUnsafeCastExpression, la cual modela las expresiones de conversióninseguras y la metaclase HaxeCastingExpression, con la cual se puede modelaruna expresión de conversión segura.

Para las expresiones de chequeo de tipos existentes en Haxe, el metamodeloincluye la metaclase HaxeTypeCheckExpression.


Figura 3.22: Metaclases de conversión de tipos

3.8. Metaclases de expresiones de manejo deexcepciones

El lenguaje Haxe provee soporte para el manejo de excepciones, utilizandoexpresiones throw y bloques try/catch. Las metaclases que permiten modelaresto son: HaxeThrowExpression, HaxeTryExpression y HaxeCatchClause, comose ve en la Figura 3.23.

Figura 3.23: Metaclases de manejo de excepciones

Capítulo 4

Lenguaje C/C++

Se presenta en esta sección un metamodelo desarrollado en Ecore parael lenguaje C/C++. Desde el punto de vista de MDA, las instancias delmetamodelo corresponden a un modelo especí�co de la plataforma (PSM).

Para el desarrollo se utilizaron las herramientas de modelado del proyectoEclipse y, en particular, el lenguaje de modelado Ecore. Además, a la horadel diseño e implementación se utilizó una representación textual llamadaOclInEcore. Esta representación permite una mayor legibilidad, modi�cabilidade integración con herramientas de versionado. Otra ventaja que presenta es quepermite especi�car expresiones en el lenguaje OCL en el mismo archivo en elque se escribe el metamodelo.

Para la presentación del metamodelo desarrollado, se explicarán acontinuación las metaclases principales y sus relaciones y, �nalmente, semostrarán las metaclases más especí�cas del lenguaje. El metamodelo completose encuentra en el Apéndice A.

4.1. Metaclases Principales

Las metaclases principales del metamodelo son aquellas que permiten laespeci�cación de una aplicación utilizando a C++ como lenguaje.

Una de las metaclases más importantes es CppModel. La misma sirve decontenedora de todos los elementos utilizados para describir una aplicación enel lenguaje C++.

Las metaclases utilizadas directamente por CppModel, como se muestra enla Figura 4.1, son:

CppClassFile: por medio de la relación modules se accede a los diferentesarchivos de la aplicación.

CppPathReferentiable: por medio de la relación elements se accede a losdistintos elementos del árbol de paquetes que son declarados en el proyecto.

45

CAPÍTULO 4. LENGUAJE C/C++ 46

CppClass: a través de la relación mainClass se obtiene la clase principalde la aplicación.

CppType: por medio de la relación orphanTypes se accede a los tiposprimitivos.

Figura 4.1: Metaclases relacionadas con CppModel

Se creó la metaclase CppModelElement como metaclase padre de todos loselementos del modelo y la metaclase CppNamedElement como padre para todoslos elementos con nombre.

Mediante el par de metaclases CppPathReferentiable y CppPathReference, semodelaron de manera abstracta aquellos tipos que pueden ser referenciados, ylas referencias que pueden ocurrir en distintos ámbitos de un programa (Figura4.2). De la metaclase CppPathReferentiable heredan las siguientes metaclases:

CppClassFile: permite modelar los diferentes archivos de clases (.cpp o.c) que componen un proyecto. Esta metaclase, a través de la relaciónelements, sirve de contenedora de los elementos que componen un archivoy, a través de la relación imports, contiene todos los archivos que importa.

CppPackage: los paquetes en C++ no son como los paquetes en otroslenguajes tipo Java, o incluso Haxe. En este caso, se considera comopaquete una carpeta que agrupa diferentes archivos del programa, yque puede seguir una estructura de árbol. Esta metaclase contiene tresrelaciones:

• childrenPackages para acceder a los paquetes hijos.


• parentReference para acceder al paquete padre.

• containedTypes contiene a los tipos declarados para ese paquete.

Además, se creó la metaclase CppImportDeclaration para modelar los importsque puede tener cada CppClassFile.

Figura 4.2: Metaclases relacionadas con CppPathReference yCppPathReferentiable

4.2. Metaclases de Archivos

Se creó la metaclase CppClassFile, la cual por medio de la relación elementscontiene elementos de la metaclase CppType, como se ve en la Figura 4.3. De estametaclase heredan CppVariable, CppClassi�er y CppFunction, lo que permiteque cada archivo pueda contener clases, funciones y/o variables. En las siguientessecciones se explicara cada tipo en detalle.


Figura 4.3: Metaclases de archivos

Para modelar los diferentes tipos de datos de C/C++ se creó la metaclaseabstracta CppType como padre de todos ellos, como se observa en la Figura 4.4.De la misma heredan PrimitiveType (para modelar tipos de datos primitivos),CppClassi�er (para modelar clases, estructuras y uniones), CppEnum (paramodelar enumeraciones), CppFunction (para modelar funciones) y CppVariable(para modelar variables). Para modelar el acceso a todos los tipos se creó lametaclase TypeAccess.

Figura 4.4: Metaclases de tipos

4.2.1. Metaclases de Clases, Estructuras y Uniones

Para el modelado de Clases, Estructuras y Uniones se creó la metaclaseCppClass, que hereda de CppClassi�er (como muestra la Figura 4.5). El atributoque de�ne de cuál de estos tres tipos (class, struct o unión) se trata esclasskey. En caso de tratarse de clases (solo C++), cada CppClassi�er tienerelaciones de composición con CppMemberFunction para de�nir las operaciones(a través de la relación cppOperations), el constructor (a través de la relacióncppConstructor) y el destructor (a través de la relación cppDestructor). Además,tiene una relación de composición (cppAttributes) con CppVariable para de�nir


los atributos que serán las variables de clase o componentes de la estructura ounión.

La metaclase CppFieldContainer contiene a través de la relación cppFieldstodos los elementos que de�nen la estructura de una clase: las operaciones(métodos, constructor y destructor) y los atributos. Además, cada CppClasscontiene la relación superClass para modelar la herencia múltiple del lenguajeC++.

Figura 4.5: Metaclases de clases, estructuras y uniones

4.2.1.1. Ejemplos

Clases

Estructuras

Uniones


4.2.2. Metaclases de Tipos Primitivos

Para modelar los tipos primitivos se creó la metaclase abstractaPrimitiveType, como muestra la Figura 4.6. De la misma heredan las clasesconcretas: BooleanType, CharType, DoubleType, FloatType, UnsignedType,SignedType, IntType, LongType, ShortType y VoidType.

Figura 4.6: Metaclases de tipos primitivos

4.2.3. Metaclases de tipos Enum

Una enumeración es un conjunto de constantes enteras. A la enumeraciónse le puede asignar un nombre, que se comportará como un nuevo tipo dedato que solo podrá contener los valores especi�cados en la enumeración.Como muestra la �gura 4.7, para modelar este tipo de datos se crearon lasmetaclase CppEnum (que hereda de CppType) y CppEnumConstructor (quehereda de CppNamedElement). Ambas metaclases se encuentran vinculadas poruna relación de composición, ya que CppEnum contiene, mediante la relaciónliterals, CppEnumConstructors.

Figura 4.7: Metaclases de tipos Enum


4.2.3.1. Ejemplo

4.2.4. Metaclases de Variables

La metaclase que representa cada variable es CppVariable, la cual heredade CppField, VariableDeclaration y CppTypedElement. La misma agrega dosatributos: el tipo de almacenamiento (StorageType) y un booleano que indica sise trata de una constante o no. Para modelar el acceso a las variables se creó lametaclase VariableAccess (Figura 4.8).

Figura 4.8: Metaclases de acceso a variables

4.2.5. Metaclases de Métodos

Para modelar los métodos se crearon las metaclases que se muestran enla Figura 4.9. La metaclase principal es CppFunction. La misma contieneuna relación ownedParameters con SingleVariableDeclaration para modelar losparámetros que puede recibir una función, y la relación functionBody conCppBlock para modelar el cuerpo de la función. De ella y de CppField heredala metaclase CppMemberFunction, la cual es la clase padre de los métodos, losdestructores y los constructores.


Figura 4.9: Metaclases de métodos

El cuerpo de la función se modeló a través de la clase CppBlock, la cualcontiene cero o más expresiones, como se muestra en la Figura 4.2.5.

Figura 4.10: Metaclases de bloques

Para modelar la invocación a los métodos se crearon las metaclases que semuestran en la Figura 4.11. La metaclases abstracta AbstractMethodInvocationcontiene, mediante la relación de composición arguments, los argumentos con losque se invoca al método (que está dado por la relación method). Las metaclasesconcretas para el modelado de estas invocaciones son:

MethodInvocation: para modelar el acceso a cualquier tipo de método.

SuperMethodInvocation: para modelar el acceso a un método de una clasepadre.

SuperConstructorInvocation: para modelar el acceso al constructor de laclase padre.


Figura 4.11: Metaclases de invocación a métodos

4.2.5.1. Ejemplos

Método

Constructor

Destructor

4.2.6. Metaclases de Elementos Parametrizados

Las plantillas (Templates), también denominadas tipos parametrizados, sonun mecanismo de C++ que permite que un tipo pueda ser utilizado comoparámetro en la de�nición de una clase o una función. Ya se trate de claseso funciones, la posibilidad de utilizar un tipo como parámetro en la de�nición,posibilita la existencia de entes de nivel de abstracción superior al de la funcióno clase concreta.


template <T> void fun(T& ref); // declaración de función genéricatemplate <T> class C {/*...*/}; // declaración de clase genéricaPara modelar esto, se creó la metaclase CppTypeParameter, la cual está

vinculada con relaciones de composición con la metaclase CppType.

4.2.6.1. Ejemplo

4.3. Metaclases de Expresiones

Las metaclases de expresiones, permiten construir las distintas expresionesque permite el lenguaje C++. Las mismas heredan de la metaclase abstractaCppExpression. A continuación se mostrarán como se modelaron los diferentestipos de expresiones.

4.3.1. Metaclases de Expresiones de Selección

Las expresiones de selección de C/C++, permiten dada una condiciónexpresada como una expresión booleana, elegir entre �ujos de ejecución distintosde acuerdo al resultado de evaluar dicha condición.

En el metamodelo, se realizaron las metaclases y relaciones mostradas en laFigura 4.12 para expresar este tipo de construcción, donde:

La metaclase abstracta SelectionStatement hereda de CppExpressioncontiene las relaciones comunes para las expresiones de selección: larelación condition (que referencia a la condición que se evaluará) ystatement (que referencia al cuerpo de ejecución).

Las metaclases concretas IfStatement e IfElseStatement heredan deSelectionStatement. La diferencia entre las mismas es que la primerano acepta una rama else y la segunda si. Además, la metaclaseIfElseStatement tiene un atributo booleano que indica si es de una únicalínea o no, esto indica si el if en ese caso está escrito como una expresiónternaria.


Figura 4.12: Metaclases correspondientes a las expresiones de selección

4.3.1.1. Ejemplos

If

If Else

4.3.2. Metaclases de Expresiones de Iteración o Bucles

Las sentencias de iteración permiten repetir un conjunto de sentenciasejecutando un bucle. En C/C++ existen tres formas de iteraciones: los buclesWhile, Do While y For. Estas expresiones se modelaron a partir de unametaclase llamada IterationStatement que hereda de CppExpression, como semuestra en la Figura 4.13. Esta metaclase contiene los elementos comunes alas expresiones While, Do While y For, como lo son la condición (a través de larelación condition) y el cuerpo de ejecución (a través de la relación theBody). DeIterationStatement heredan las metaclases: DoWhileStatement, WhileStatementy ForStatement. Las primeras dos no agregan nada con respecto a su clasepadre. En cambio, ForStatement agrega dos relaciones nuevas: una expresiónque inicializa la variable con la que se itera (a través de la relación initializer) yuna expresión que actualiza el valor del iterador (a través de la relación updater).


Figura 4.13: Metaclases de expresiones iterativas

4.3.2.1. Ejemplos

While

Do While

For

4.3.3. Metaclases de Expresiones de Selección Múltiple

Las expresiones de selección múltiple (expresiones switch) permiten apartir de una expresión, elegir entre varios caminos de ejecución según elvalor obtenido de evaluar esta última. Como se muestra en la �gura 4.14,las metaclases SwitchExpression y CppCase, que heredan de la metaclaseHaxeExpression, permiten escribir este tipo de expresiones de selección. Lametaclase SwitchExpression permite crear sentencias switch y tiene tresrelaciones de composición con las metaclases HaxeCase y HaxeExpression:

A través de la relación expression se modela la expresión que se evalúapara elegir la rama que se ejecutará.


A través de la relación default se permite agregar opcionalmente una ramade ejecución por defecto, que se ejecutará si el valor de la expresión nocoincide con ninguno de los valores considerados en cada rama.

A través de la relación cases con la metaclase CppCase, contiene lasdiferentes ramas de ejecución posibles. En la metaclase CppCase, pormedio de la relación values, se con�gura la lista de valores que puedetomar la expresión de la sentencia switch que la contiene y, por medio dela relación expression, se realiza la composición de las expresiones que seejecutarán en esa rama.

Figura 4.14: Metaclases de expresiones de selección múltiple

4.3.3.1. Ejemplo

4.3.4. Metaclases de Expresiones Unarias y Binarias

Para el metamodelado de las operaciones se optó por realizar dosmetaclases abstractas, UnaryExpression y BinaryExpression, las cuales heredande CppExpression (como se muestra en la Figura 4.15). Con las mismas sepermite expresar operaciones con uno y dos operandos, respectivamente. Losoperandos se obtienen a través de las relaciones rightOperand y leftOperand enlas binarias, y por la relación expression en las unarias.


Figura 4.15: Metaclases de expresiones unarias y binarias

Operaciones Unarias: de la metaclase UnaryExpression heredan lasmetaclases Post�xExpression y Pre�xExpression, de acuerdo al orden enel que se encuentre el operador y el operando. En las expresiones post�jas(Post�xExpression) se encuentra primero el operando y luego el operador,y viceversa para las expresiones pre�jas. Cada metaclase contiene unarelación con una enumeración que describe los posibles operadores que sepueden utilizar en cada operación, como se muestra en la �gura 4.16.

Operaciones Binarias: de la metaclase BinaryExpression heredan lasmetaclases In�xExpression y AssignamentStatement, para diferenciar si setrata de una expresión in�ja o de una asignación. Cada metaclase contieneuna relación con una enumeración que describe los posibles operadores quese pueden utilizar en cada operación, como se muestra en la Figura 4.16.

Figura 4.16: Operadores usados en expresiones unarias y binarias


4.3.5. Metaclases de Expresiones de manejo deExcepciones

El manejo de excepciones en C++ se realiza a través de expresiones throw ybloques try/catch (Figura 4.17). Para ello, se crearon las siguientes metaclasesque heredan de CppExpression:

ThrowExpression: esta metaclase contiene una relación expression en laque contiene la expresión que utiliza como argumento.

TryExpression: esta metaclase contiene una relación theBody que contienela expresión que se ejecutará dentro del try y una relación catchClause enla que contiene las posibles expresiones de catch.

CatchClause: esta metaclase, al igual que TryExpression, contiene unarelación theBody con la expresión que se ejecutará dentro del catch.

Figura 4.17: Metaclases de expresiones de manejo de excepciones

4.3.5.1. Ejemplo

4.3.6. Metaclases de Expresiones Constantes

Para las expresiones constantes, se crearon las siguientes metaclasesque heredan de CppExpression (Figura 4.18): BooleanLiteral (para valores


booleanos), CharacterLiteral (para caracteres), NumberLiteral (para valoresnuméricos), NullLiteral (para valores nulos), StringLiteral (para cadenas decaracteres) y RegexLiteral (para expresiones regulares). Cada instancia de estasmetaclases almacenará el valor del literal, según corresponda en cada caso.

Figura 4.18: Metaclases de expresiones constantes

4.3.7. Metaclases de Expresiones con Arreglos

En cuanto a las expresiones que sirven para la manipulación de arreglos, secrearon dos metaclases que heredan de CppExpression, como se puede ver en laFigura 4.19:

ArrayInitializer : que corresponde con un inicializador de arreglos. Estametaclase, por medio de la relación expressions, contiene a las distintasexpresiones que permiten la inicialización.

ArrayAccess: permite modelar las expresiones que acceden a un arreglo.Las relaciones index y array contienen el índice y el arreglo al que seaccede, respectivamente.

Figura 4.19: Metaclases de expresiones con arreglos

4.3.7.1. Ejemplos

Acceso


Inicializador

4.3.8. Metaclases de Expresiones de Salto

Para modelar las expresiones de salto GoTo, Break, Continue y Return secreó una metaclase abstracta JumpStatement de la cual heredan las metaclases:BreakStatement, ReturnStatement (la cual tiene una relación returnExpressioncon la expresión de retorno), GotoStatement (la cual tiene una relación labelcon la expresión que tiene la etiqueta a la que se salta) y ContinueStatement,como se puede ver en la Figura 4.20).

Figura 4.20: Metaclases de expresiones de corte y continuación

4.3.8.1. Ejemplos

Break

Continue

Go To / Labels


4.3.9. Metaclases de Expresiones Compuestas

Para las expresiones compuestas se creó la metaclase CppBlock, comomuestra la Figura 4.21. En esta metaclase, a través de la relación de composiciónsatements, sirve de contenedora de cero o más expresiones.

Figura 4.21: Metaclases de expresiones compuestas

4.3.10. Metaclases de Expresiones de Conversión de Tipos

Las expresiones de conversión explícita de tipos (o expresiones de casting)permiten cambiar la interpretación de un valor de una expresión a la de un tipodistinto al esperado. La sintaxis puede ser: (<nombre de tipo>)<expresión>o <nombre de tipo>(<expresión>). Para ello, como se ve en la �gura 4.22, secreó la metaclase CastExpression, que hereda de CppExpression. Esta metaclasecontiene una referencia a una expresión (que es la que se convertirá) y unareferencia al tipo al que se quiere convertir.

Figura 4.22: Metaclases de expresiones de casting

4.3.10.1. Ejemplo


4.3.11. Metaclases Expresiones de Declaración deVariables

Para poder declarar variables y atributos en el contexto del metamodelo, secrearon las metaclases mostradas en la Figura 4.23:

DeclarationExpression: esta metaclase que hereda de CppExpressionpermite modelar una expresión de declaración de variables.

VariableDeclaration: esta metaclase abstracta se creó con el objetivode expresar las diferentes combinaciones posibles de declaraciones devariable. Contiene como atributos el tipo de variable (del tipo enumVarType) y un booleano que indica si se trata de un arreglo o no.Además, cuenta con dos referencias a CppExpression: una para modelarsi la variable declarada tiene un inicializador y otra para expresar lasdimensiones en caso de tratarse de un arreglo. De esta metaclase heredanVariableDeclarationFragment y SingleVariableDeclaration.

VariableDeclarationGroup: esta metaclase representa la declaración demúltiples variables asociadas a un mismo tipo. Por lo tanto, se creó unarelación de composición con VariableDeclarationFragment, a través dela cual se modelan los diferentes fragmentos que componen el grupo devariables.

Figura 4.23: Metaclases de declaración de variables

4.3.11.1. Ejemplos

Declaración


Declaración e Inicialización

4.4. Metaclases de Comentarios

Para el metamodelado de los comentarios, se creó la metaclase CppComment(como muestra la Figura 4.24). Los comentarios pueden abarcar una línea ovarias, debiendo éstos ser delimitados de manera apropiada y no anidados. Porlo tanto, la metaclase contiene como atributos dos valores booleanos que indicansi el comentario es de una línea o multilínea. Además, contiene el contenido delcomentario.

Figura 4.24: Metaclases de comentarios

4.4.1. Ejemplo

Capítulo 5

Proceso de migración

El proceso de migración de C/C++ a plataformas móviles a través dellenguaje Haxe puede verse grá�camente en la Figura 5.1.

El primer paso de la migración consiste en una transformacióncódigo-a-modelo, en la que el código fuente del programa escrito en C/C++ estraducido a un modelo que conforme al metamodelo de�nido para tal lenguaje.Para llevar a cabo este proceso en primer lugar se debe diseñar un metamodeloque describa los elementos del lenguaje de origen, por lo que fue desarrollado unmetamodelo que describa al lenguaje C/C++ (Capítulo 4). Este metamodeloes el principal factor que asegura la calidad y la completitud de la fase dedescubrimiento encargada de generar instancias del metamodelo a partir delsistema. En el presente trabajo, se utilizó ANTLR y se desarrolló un programaJava para llevar a cabo la tarea de descubrimiento del modelo a partir delprograma.

El siguiente paso consiste en transformar el modelo que conforma al lenguajede origen, a un modelo que conforme el metamodelo del lenguaje destino. Estaetapa se llevó a cabo mediante una transformación a nivel de metamodelos,implementada en ATL, que toma como entrada el modelo C/C++ parael programa y genera como salida el correspondiente modelo Haxe. Dichatransformación se especi�ca mediante un conjunto de reglas de transformaciónque de�nen mapeos semánticos entre los elementos del metamodelo de entrada(metamodelo C/C++) y los elementos del metamodelo de salida (metamodeloHaxe).

Finalmente, el último paso es la ingeniería directa, una transformaciónmodelo-a-texto desde el modelo que conforma al metamodelo Haxe hacia códigofuente. Para ello, se utilizó el generador de código Acceleo.

La migración completa se encuentra en el siguiente repositorio:https://github.com/mduthey/Tesis_Duthey_Spina

65

CAPÍTULO 5. PROCESO DE MIGRACIÓN 66

Figura 5.1: Proceso de migración

5.1. Ingeniería Inversa

5.1.1. Descripción del proceso de Ingeniería Inversa

El primer paso de la migración consiste en una transformacióncódigo-a-modelo, en la que el código fuente del programa escrito en C/C++ estraducido a un modelo que conforme al metamodelo de�nido para tal lenguaje.Esta representación es un paso muy importante, dado que permite obtener laimplementación del programa en términos de un modelo compatible con MOF.

Hoy en día, la herramienta más completa alineada con ADM es MoDisco, unframework open source para MDRE (Model Driven Reverse Engineering) queforma parte de la plataforma Eclipse. MoDisco provee un framework genérico yextensible cuyo objetivo es facilitar el desarrollo de herramientas para extraermodelos a partir de sistemas legados. Como un componente Eclipse, MoDiscopuede integrarse con otros plugins y tecnologías disponibles en el entornoEclipse tales como el Eclipse Modeling Framework (EMF), Graphical ModelingFramework (GMF) y transformaciones modelo-a-modelo.

Las limitaciones que tiene MoDisco es que solo provee herramientas parael descubrimiento del modelo de proyectos escritos en el lenguaje Java. Por lotanto, fue necesario desarrollar una herramienta propia para realizar esta tarea.


5.1.2. ANTLR (ANother Tool for Language Recognition)

ANTLR es una poderosa herramienta de generación de analizadores léxicosy sintácticos para lectura, procesamiento, ejecución y/o traducción de textoestructurado e incluso archivos binarios.

Esta herramienta es ampliamente utilizada para el desarrollo de lenguajes,frameworks e incluso de otras herramientas.

Partiendo de gramáticas de distintos tipos, ANTLR genera lexers y parserscapaces de construir y recorrer árboles de parsing. Permite además insertaracciones semánticas en cada punto de las reglas gramaticales, e incluso poseeun sistema de predicados, de gran utilidad para desambiguar casos complejos, obien simpli�car considerablemente gramáticas complicadas con el agregado desimples condiciones.

En anteriores versiones de ANTLR, sólo se contemplaba la generación deanalizadores léxicos y sintácticos. En las versiones actuales se puede, además,escribir gramáticas especialmente diseñadas para recorrer y procesar árbolessintácticos on the �y, pudiendo así separar el parsing, del recorrido y proceso delas estructuras obtenidas. También provee en las versiones actuales un templateengine para la traducción entre lenguajes, es decir, para la generación de textosestructurados escritos en un segundo lenguaje, tomando como entrada el análisissintáctico resultante del texto escrito en el lenguaje original modelado por lagramática.

5.1.3. Programa Java desarrollado

Una vez generado el árbol de parsing con la herramienta ANTLR y lagramática C++ que provee la misma, se desarrolló un programa escrito en ellenguaje Java para el recorrido del mismo y creación del modelo correspondientea cada programa C/C++ de entrada. La salida del programa es un archivo XMLque representa el modelo. El tipo de modelo obtenido luego de esta conversiónse denomina modelo inicial dado que posee una correspondencia directa con loselementos del sistema original con la menor pérdida de información.

En el diagrama que se encuentra en la Figura 5.2 se pueden observar lasrelaciones existentes en las clases principales del proyecto. Desde la aplicaciónprincipal, al seleccionar un proyecto escrito en C++, se ejecuta el Compiler.Esta clase es la encargada de centralizar y llamar a los métodos necesariospara realizar la lectura de código y transformarlo en modelos. Se ayuda de laclase ExtractListenerCPP, TypesController y PromiseController. La primera, esla encargada de recorrer el árbol de sintaxis abstracta generado por ANTLR alpasarle un archivo escrito en C/C++. Este extractor, utiliza la clase Expressionsque se encarga principalmente de reconocer las diferentes expresiones dellenguaje. La clase TypesController permite llevar el conocimiento de loselementos principales encontrados en el código (clases, métodos y variables).De esta manera, es posible recuperar una instancia de cualquier elemento si esnecesario (por ejemplo, llamado a una función y crear la relación). La tercer


clase nombrada, PromiseController, almacena elementos solicitados que aún nohan sido procesados (pueden ser métodos, clases, variables) e información delobjeto que la requiere. Al generar un nuevo elemento se noti�ca a esta clasedel mismo, de esta manera, se buscan los objetos que la solicitaron y se losactualiza con la referencia. Cuando se terminan de procesar todos los archivos,se revisa esta clase buscando los elementos faltantes y, con la ayuda de la claseCPPAutoGen, se generan los elementos faltantes de manera generica los cualesdeberan ser revisados.

También, se pueden encontrar la clase XmiReference, que es laimplementación de la interfaz XmiReferenceInterface. Esta implementaciónpermite tener herencia múltiple dentro del lenguaje Java. Es utilizada pararemarcar que la clase puede ser referenciada por otra y ofrece los métodosnecesarios para realizar esta tarea. La interfaz Class2XMI provee un métodoque debe ser implementado. Este método permite generar el código XML parasu utilización/visualización. Es implementado por las clases principales dentrodel paquete mmclass.

Figura 5.2: Clases principales de la aplicación

En el diagrama que se encuentra en la Figura 5.3 se pueden observar lasrelaciones entre los subpaquetes del paquete mmclass. Este paquete contiene lasclases .java generadas a partir del metamodelo. De esta manera, cada clase sepuede implementar siendo �el al metamodelo y generar de manera sencilla elXML resultante ya que cada una sabe como representarse.


Figura 5.3: Diagrama de relaciones dentro del paquete mmclass

En el diagrama que se encuentra en la Figura 5.4 se muestran las relacionesdel paquete mmclass con el resto de los paquetes del proyecto. El paqueteantlr4.ccparser es generado a partir de la gramática de C++ con la herramientaANTLR 4.5. Estas clases son utilizadas para generar el árbol de sintaxisabstracta de un archivo escrito en C++ y ofrece una clase base para recorrerlo. Apartir de esta clase se generan los extractores. En el paquete main se encuentrael programa principal. Dicho programa permite seleccionar el proyecto que sedesea procesar. El paquete generic contiene las clases principales utilizadaspara el procesamiento, las principales son Compiler y ExtractListenerCPP. Elpaquete extractor posee la clase Expressions que se encarga del procesamientode expresiones del lenguaje.

Figura 5.4: Diagrama de paquetes del proyecto


5.2. Transformación

En el nivel de metamodelos las transformaciones están dadas por mapeosentre metamodelos. Para cada transformación se deben de�nir los metamodelosorigen y destino. El metamodelo origen describe la familia de modelos parael cual es posible aplicar la transformación. El metamodelo destino indica lascaracterísiticas de los modelos generados.

La transformación cpp2Haxe, de C++ a Haxe, permite la conversión desdemodelos que conformen con el metamodelo de C/C++ a su modelo equivalenteque conforme al metamodelo de Haxe. El objetivo es la traducción de losdistintos elementos sintácticos de un programa codi�cado en el lenguaje C/C++para poder ser expresados como construcciones válidas en el lenguaje Haxe.La implementación de las transformaciones fue utilizando el lenguaje ATL. Seutilizó el lenguaje ATL debido a su madurez, integrabilidad y estabilidad.

A continuación, se explican las características de las transformaciones paralas diferentes construcciones.La transformación completa se encuentra en elApéndice B.

5.2.1. Elementos Principales

La metaclase principal del metamodelo de C++ es CppModel y, la delmetamodelo de Haxe es HaxeModel. Por lo tanto, la transformación de unainstancia de CppModel a una de HaxeModel se realiza mediante la regla model,en la que:

La referencia elements se resuelve utilizando un helper llamadoget_allpackages que obtiene todos los CppPackages que contiene unCppModel.

La referencia referenced se resuelve �ltrando los elementos de la relaciónorphanTypes, pero eliminando los elementos sin ocurrencias en el modelo,y quedándose únicamente con los tipos primitivos.

La referencia HaxeModules se resuelve utilizando un helper llamadoget_class�les que obtiene todos los CppClassFiles de todos los paquetes.

La referencia mainClass se resuelve de manera directa con la mainClassdel CppModel.

Transformaciones entre metaclases simples se realizaron de manera directa, talescomo:

CppNamedElement a HaxeNamedElement, mediante la reglanamedElement.

CppPackage a HaxePackage, mediante la regla packages.

CppClassFile a HaxeModule, mediante la regla modules. En la mismase utilizó, para resolver la referencia dependencies un helper llamadoget_imports.


5.2.2. Tipos Primitivos

La conversión entre tipos primitivos, se muestra en la Figura 5.5.

Tipo Primitivo de C++ Tipo Primitivo de Haxe

int Intboolean Boolvoid Voidchar Stringshort Intlong Int�oat Floatdouble Floatsigned Int

unsigned Uint

Figura 5.5: Transformación entre tipos primitivos de C++ a Haxe

5.2.3. Clases y Constructores

La transformación de las clases públicas se hizo de manera directa a través dela regla classes, y la transformación de los constructores de clase se realizaronpor la regla constructors. Sin embargo, se tuvieron que tener en cuenta lossiguientes puntos:

El lenguaje Haxe no admite que las clases sean abstractas. En cambio, sepuede simular esta situación convirtiendo al constructor de la clase en unmétodo privado. Por lo tanto, cada clase que en C++ fuera declarada comoabstracta, fue transformada como una clase en Haxe cuyo constructor esprivado.

A diferencia del lenguaje C++, Haxe no permite la declaración de losdestructores de las clases. Por lo tanto, éstos fueron descartados almomento de la transformación.

El lenguaje C++ admite herencia mútliple de clases y Haxe solo permiteherencia simple. En la transformación se optó por generar solo laherencia del primer elemento (a través de la lazy rule get_generalization),descartando las siguientes. Esto claramente puede tener inconvenientes almomento de generar el código que deberán ser solucionados manualmente.

5.2.4. Enumeraciones

Para la transformación de las enumeraciones, se utilizaron las siguientesreglas:

enumTransformation que se encarga de transformar un CppEnum en unHaxeEnum.


enumConstructor que se encarga de transformar un CppEnumConstructoren un HaxeEnumConstructor.

5.2.5. Expresiones

Expresiones binarias: las expresiones que heredan deCppBinaryExpression a HaxeBinaryExpression se transformaron através de las las reglas:

• in�xExpression, que transforma una CppIn�xExpression a unaHaxeIn�xExpression

• assignmentExpression, que transforma un CppAssignamentStatementa un HaxeAssignment.

Expresiones unarias: las expresiones que heredan deCppUnaryExpression a HaxeUnaryExpression se transformaron através de las reglas:

• pre�xExpression, que transforma una CppPre�xExpression a unaHaxePre�xExpression.

• post�xExpression, que transforma una CppPost�xExpression a unaHaxePost�xExpression.

Expresiones condicionales: las expresiones que heredan deCppSelectionStatement a HaxeConditionalExpression, se transformaron através de las siguientes reglas:

• ifStatement, que transforma un CppIfStatement a unHaxeIfStatement.

• ifElseStatement, que transforma un CppIfElseStatement a unHaxeIfStatement (agregándole la sección �else�).

• ifElseStatementInline, que transforma un CppIfElseStatement comooperación ternaria a una HaxeTernaryExpression.

Expresiones iterativas: CppIterationStatement a HaxeLoopStatement,se transformó mediante la regla abstracta loopStatement, de la cualheredan las reglas:

• doWhileStatement, que transforma un CppDoWhileStatement a unHaxeDoWhileStatement.

• whileStatement, que transforma un CppWhileStatement a unHaxeWhileStatement.

Expresión For : Haxe no soporta las sentencias for tradicionales, sino quesolo se puede aplicar sobre tipos que pueden ser iterados o sobre intervalos.Por ejemplo: for (v in e1) e2 o for (i in 0...10) trace(i). Por lo tanto, para


la transformación de un for tradicional como es el caso de los que tieneel lenguaje C++, se recurrió a convertirlo en una sentencia while a travésde la regla forStatement.

Expresión Switch: CppSwitchExpression a HaxeSwitch, se transformómediante la regla switch. Además, la estructura de los posibles casos dentrode un switch se transformó mediante la regla case, la cual transforma unCppCase a un HaxeCase.

Bloques de sentencias: la transformación de un CppBlock a unHaxeBlock se realiza a través de la lazy rule generateBlock. Se recurrió autilizar una regla lazy para evitar la transformación innecesaria de bloquesvacíos.

Expresiones de excepciones: para modelar las excepciones seutilizaron tres expresiones: CppTryExpression, CppCatchClause yCppThrowExpression, las cuales fueron transformadas a sus equivalentesen el lenguaje Haxe a través de las siguientes reglas:

• La regla try transforma una CppTryExpression en unaHaxeTryExpression.

• La regla catch transforma una CppCatchClause en unaHaxeCatchClause.

• La regla throw transforma una CppThrowExpression en unaHaxeThrowExpression.

Expresiones para el manejo de arreglos: las expresionesque participan en el manejo de arreglos son CppArrayAccess yCppArrayInitializer, las cuales fueron transformadas a HaxeArrayAccess(a través de la regla arrayAccess) y a HaxeArrayInitializer (a través de laregla arrayInitializer), respectivamente.

Expresiones constantes: las expresiones constantes se transformaron demanera directa a través de las siguientes reglas:

• La regla stringLiteral transforma un CppStringLiteral a unHaxeStringLiteral.

• La regla nullLiteral transforma un CppNullLiteral a unHaxeNullLiteral.

• La regla booleanLiteral transforma un CppBooleanLiteral a unHaxeBooleanLiteral.

• La regla numberLiteral transforma un CppNumberLiteral a unHaxeNumberLiteral.

• La regla charLiteral transforma un CppCharacterLiteral a unHaxeStringLiteral.


• La regla regexLiteral transforma un CppRegexLiteral a unHaxeRegexLiteral.

Expresiones de casting de variables: la regla castRule se encarga detransformar una CppCastExpression en una HaxeCastingExpression.

Expresiones break , continue, return y this: estas expresiones setransformaron de manera directa a través de las siguientes reglas:

• La regla breakStatement transforma un CppBreakStatement a unHaxeBreak.

• La regla continueStatement transforma un CppContinueStatement aun HaxeContinue.

• La regla return transforma un CppReturnStatement a unHaxeReturn,

• La regla thisExpression transforma una CppThisExpression a unaHaxeThisExpression.

Expresiones de acceso a elementos: las expresiones de acceso adiferentes elementos fueron transformadas de la siguiente manera:

• La regla �eldAccess transforma un CppFieldAccess en unHaxeFieldAccess.

• La regla variableAccess transforma un CppVariableAccess en unHaxeSingleVariableAccess.

• La regla typeAccessClass transforma un CppTypeAccess en unHaxeClassi�erAccess, en el caso de que el tipo sea CppClassi�er.

• La regla typeAccessPrimitive transforma un CppTypeAccess en unHaxeClassi�erAccess, en el caso de que el tipo sea CppPrimitiveType.

5.2.6. Declaración de Variables

Las expresiones que permiten la declaración simple de variables y lasdeclaraciones de grupos de variables, se transformaron a través de las siguientesreglas:

La regla variableDeclarationGroup se encarga de la transformación de unCppVariableDeclarationGroup a un HaxeVariableDeclarationGroup.

La regla abstracta variableDeclaration se encarga de la transformación deuna CppVariableDeclaration a una HaxeVariableDeclaration. De esta reglaheredan las siguientes:

• variableDeclarationFragment que se encarga de latransformación de un CppVariableDeclarationFragment en unHaxeVariableDeclarationFragment. Este caso se aplica cuando lavariable que se está declarando no es de tipo arreglo.


• variableDeclarationFragmentArray que se encarga de latransformación de un CppVariableDeclarationFragment en unHaxeVariableDeclarationFragment. Este caso se aplica cuando lavariable que se está declarando es de tipo arreglo, ya que es necesariala creación de una instancia de la metaclase CppArrayCreation.

• singleVariableDeclaration que se encarga detransformar una CppSingleVariableDeclaration en unaHaxeSingleVariableDeclaration.

La regla declarationExpression se encarga de la transformación de unaCppDeclarationExpression a una HaxeDeclarationExpression.

5.2.7. Métodos

La regla abstracta abstractFunction se encarga de la transformación deuna CppFunction a una HaxeAbstractFunction. De la misma hereda laregla abstractOperation que se encarga de transformar una CppFunctiona una HaxeAbstractOperation. De la regla abstractOperation hereda laregla methods, cuyo objetivo es transformar un CppMethod en unaHaxeOperation.

Para la transformación de las metaclases que modelan el acceso a losmétodos, se crearon las siguientes reglas:

• methodInvocation que se encarga de transformar unCppMethodInvocation en un HaxeMethodInvocation.

• superMethodInvocation que se encarga de transformar unCppSuperMethodInvocation en un HaxeSuperMethodInvocation.

• superConstructorInvocation que se encarga detransformar un CppSuperConstructorInvocation en unHaxeSuperConstructorInvocation.

5.2.8. Variables

La regla que se encarga de transformar las variables es la llamadaclassVariables, la cual parte de una CppVariable y la transforma en unHaxeAttribute. En el caso de que se trate de una variable de tipo arreglo, laregla que se ejecuta es diferente y es la llamada classVariablesArray, ya quetambién debe crear una instancia de HaxeArrayCreation.

5.2.9. Comentarios

La transformación de los comentarios se realizó de manera directa a travésde la regla comments.


5.3. Ingeniería Directa

5.3.1. Acceleo

Para el proceso de Ingeniería Directa que transforma un modelo del lenguajeHaxe en código, se utilizó Acceleo. Acceleo es un sistema de generación de códigobasado en el estándar MOFM2T (Modelo a Texto) del OMG. Fue desarrolladopor la empresa francesa Obeo en el año 2005.

Acceleo contiene todas las herramientas que se esperan de un IDE degeneración de código de calidad: sintaxis simple, generación de código e�ciente,herramientas avanzadas, entre otras. Su enfoque basado en prototipos y modelosfacilita la creación de generadores de texto basados en el código fuente delos prototipos existentes. Es compatible con muchos de los modelos queactualmente se pueden utilizar para representar realidades, entre los que seencuentran modelos UML, UML2, EMF, Ecore, XML, XMI, modelos generadospor MoDisco (JAVAXMI).

5.4. Herramienta para la migración

Para facilitar el uso de las herramientas provistas se generó un programaJava con una interfaz muy sencilla (Figura 5.6) que permite la selección de unproyecto C/C++ y la ejecución de los pasos para obtener un proyecto Haxe.

Figura 5.6: Herramienta para la migración

Este software facilita la tarea de generar código Haxe mediante los siguientespasos:

1. Se debe seleccionar la carpeta donde se encuentra el proyecto C/C++haciendo click en el botón �Seleccionar�. Se habilita el botón �Generarmodelo C++� cuando un proyecto es seleccionado.


2. Se debe ingresar un nombre para el proyecto (no es obligatorio, peropermite identi�car un .xmi, ya que el modelo contiene este nombre).

3. Al hacer click sobre �Generar modelo C++�, se elige el destino del modelo.xmi que se generará. Al �nalizar, se habilita el botón �Generar modeloHaxe�.

4. Al hacer click sobre �Generar modelo Haxe�, se anuncia que estafuncionalidad no está implementada y permite elegir el .xmi ya generado(debido a limitaciones, este debe generarse mediante Eclipse). Al cargarel xmi, se habilita el botón �Generar código Haxe�.

5. Al hacer click sobre �Generar código Haxe�, la herramienta permite elegiruna carpeta destino para la salida del código generado e indica cuando ha�nalizado la generación.

De esta manera, se pueden tener los archivos intermedios generados en latransformación, además del resultado �nal que consiste en el proyecto Haxeque podrá ser compilado para diversas plataformas.

Los casos de estudios que se presentarán en el Capítulo 6 fueron migrados através de la presente aplicación.

5.5. Repositorio

El repositorio donde se puede encontrar todo el código del proceso descriptose encuentra en: https://github.com/mduthey/Tesis_Duthey_Spina.

El código de la ingeniería inversa con ANTLR se encuentra en:https://github.com/mduthey/Tesis_Duthey_Spina/tree/master/Proyecto ATL/thesis_�nal y contiene CPP2Haxe.atl, cpp.ecore,Haxe.ecore y los xmi correspondientes a los casos de prueba delCapítulo 6.

Los metamodelos (cpp.ecore y Haxe.ecore) se encuentranen: https://github.com/mduthey/Tesis_Duthey_Spina/tree/master/Metamodelos.

La transformacion ATL se encuentra en:https://github.com/mduthey/Tesis_Duthey_Spina/tree/master/Transformacion.

Software Final: https://github.com/mduthey/Tesis_Duthey_Spina/tree/master/Software Final Este último contiene el .jar de la interfaz grá�cay los .jar correspondientes al proyecto de ingeniería inversa (llamadoIngInversa.jar) y al proyecto Acceleo (llamado IngDirecta.jar). Tambiénestan los codigos cpp listos para transformar (sin miniwin).

Casos de estudio (que se explicarán en el siguiente capítulo):


• Caso de estudio 1: https://github.com/mduthey/Tesis_Duthey_Spina/tree/master/Casos de Prueba/Caso 01



Capítulo 6

Casos de Estudio

Como casos de estudio, se tomaron diferentes piezas de software escritos enC/C++ y se les aplicó el proceso completo de migración para validar el procesodesarrollado.

6.1. Programa Simple

El primer caso de estudio que se tomó para analizar fue un programa muysimple escrito en C++, de un único archivo .cpp y un archivo .h. El objetivo deeste programa es mostrar de manera simple los pasos de la migración completa.

El archivo RectangleTesis.h (Figura 6.1) contiene el header de la claseRectangle, el cual tiene la declaración de dos variables y de encabezados dedos métodos, más dos constructores y un destructor.

El archivo RectangleTesis.cpp (Figura 6.2) contiene la implementación delos métodos de la clase Rectangle, además de la implementación de un métododisplay() y un método main().

Figura 6.1: Programa simple en C++ (RectangleTesis.h)

79

CAPÍTULO 6. CASOS DE ESTUDIO 80

Figura 6.2: Programa simple en C++ (archivo.cpp)

El resultado de ejecutar este programa es la salida por consola con el texto�Área: 12� como puede verse en la Figura 6.3.

Figura 6.3: Ejecución del programa simple en C++

6.1.1. Proceso

El primer paso, al tener el código fuente, será aplicarle el proceso deingeniería inversa para lograr el descubrimiento del modelo y generar, deesta manera, el archivo .xmi que representa la instancia del modelo C++correspondiente al programa que conforma al metamodelo desarrollado.

El siguiente paso consiste en aplicar la transformación modelo a modeloescrita en ATL a ese modelo de entrada. El resultado de la misma es otro archivo.xmi que representa la instancia del modelo Haxe correspondiente al programaen cuestión y que conforma al metamodelo del lenguaje Haxe.

Luego de aplicar la transformación, lo siguiente es realizar proceso deingeniería directa. El mismo, genera como resultado un proyecto Haxe completocompuesto por una carpeta �src� y un archivo build.hxml. Dentro de la carpeta�src�, se generan las carpetas que corresponden a los diferentes paquetes, queen este caso son solo dos: �defaultpkg� y �system�. Dentro de �default� seencuentra el archivo RectangleTesis.hx, que corresponde a la implementaciónen Haxe de lo mismo que se encontraba implementado en C++. La carpeta�system� contiene el archivo CPPAutoGen.hx, como se explicó anteriormenteque se generaría.

Se tomó una pequeña porción de código para mostrar la evolución delproceso.

1. En primer lugar, se puede observar el método main() en C++:


2. A continuación, se observa la instanciación del modelo para la sección decódigo mostrada en 1:

3. Luego, se muestra el modelo Haxe luego de aplicada la transformaciónATL:


4. Finalmente, se muestra el código Haxe al que se llega luego del procesode ingeniería directa:

6.1.2. Resultado Final

El código fuente Haxe que se encuentra en el archivo RectangleTesis.hx sepuede ver en la Figura 6.4.


Figura 6.4: Programa simple en Haxe

Como se puede ver, se generó la clase Rectangle, conteniendo las mismasvariables y métodos que las del programa en C++. Además, se generó la claseRectangleTesis, la cual contiene la función display(), que no se encontraba enninguna clase, y la función main().

El contenido del archivo CPPAutoGen.hx se puede ver en la Figura 6.1.2.

Figura 6.5: Archivo CPPAutoGen del programa simple

Gracias a este archivo, el programador podrá notar que la función printf,propia de C/C++ para salidas por consola no se encuentra en el lenguajedestino, por lo que en ese caso deberá modi�car el código que la contenga.Este paso fue llevado a cabo, reemplazando printf por la función trace propiade Haxe (también podría haberse utilizado Sys o println).

Además, para que el código generado funcione se tuvieron que hacer lossiguientes cambios:

Como Haxe no permite tener múltiples constructores, fue necesarioeliminar uno.

Modi�car los parámetros del constructor existente para mantener elmétodo de inicialización sin parámetros que se tenía en el código original.


Se eliminó la clase autogenerada, ya que solo se utilizó con �nesinformativos.

El resultado es el código de la Figura 6.1.2.

Figura 6.6: Código Haxe modi�cado

El código es totalmente funcional, y se puede ver el resultado de sucompilación para Neko en la Figura 6.7.

Figura 6.7: Ejecución del programa simple en Haxe

6.2. Ping Pong

El clásico juego de Ping Pong escrito en el lenguaje C++, se descargó desdeel siguiente repositorio: https://sourceforge.net/projects/juegosc/.

El mismo está compuesto por tres archivos de código fuente: miniwin.h,miniwin.cpp y main.cpp. Los archivos miniwin.h y miniwin.cpp correspondena una librería propia de C/C++, la cual permite realizar la parte grá�ca deljuego, como abrir una ventana, pintar en ella, detectar la presión de las teclas yel movimiento y los botones del mouse. A continuación se muestra el contenidodel archivo main.cpp, el cual contiene toda la lógica del juego (Figura 6.8).


Figura 6.8: Ping Pong (main.cpp)

En la Figura 6.9 se puede ver una captura de pantalla del juego.


Figura 6.9: Ping Pong C++

6.2.1. Proceso

Aclaración: la libreria miniwin no sera transformada por su dependencia conlibrerias propias de C/C++.

El primer paso, al tener el código fuente, será aplicarle el proceso deingeniería inversa para lograr el descubrimiento del modelo y generar, deesta manera, el archivo .xmi que representa la instancia del modelo C++correspondiente al programa que conforma al metamodelo desarrollado. Elresultado se encuentra es el archivo PingPongCPP.xmi,

El siguiente paso consiste en aplicar la transformación modelo a modeloescrita en ATL a ese modelo de entrada. El resultado de la misma es otroarchivo .xmi (PingPongHaxe.xmi) que representa la instancia del modelo Haxecorrespondiente al programa en cuestión y que conforma al metamodelo dellenguaje Haxe.

Luego de aplicar la transformación, lo siguiente es realizar proceso deingeniería directa. El mismo, genera como resultado un proyecto Haxe completocompuesto por una carpeta �src� y un archivo build.hxml. Dentro de la carpeta�src�, se generan las carpetas que corresponden a los diferentes paquetes, queen este caso son solo dos: �defaultpkg� y �system�. Dentro de �defaulpkg�se encuentra el archivo Main.hx (Figuras 6.10 y 6.11), que corresponde a laimplementación en Haxe de lo mismo que se encontraba implementado enC++. La carpeta �system� contiene los archivos CPPAutoGen.hx (Figura 6.12),String.hx (Figura 6.13) y Stringstream.hx (Figura 6.14).


Figura 6.10: Archivo Main.hx (Parte 1)


Figura 6.11: Archivo Main.hx (Continuación)

Figura 6.12: Archivo CppAutogen.hx

Figura 6.13: Archivo String.hx

Figura 6.14: Archivo Stringstream.hx



1. En primer lugar, se puede observar el método barra_pintar() en C++,que se compone de un for :


3. Luego, se muestra el modelo Haxe luego de aplicada la transformaciónATL. Como se explicó anteriormente, Haxe no cuenta con la construcciónfor como la que se utilizó en este caso, por lo tanto, luego de latransformación, la iteración se convierte en un while, como se ve acontinuación:




Luego de obtener el código transformado, se debe realizar una interfaz grá�capropia del lenguaje Haxe. Para ello, se utilizó un framework llamado OpenFL


y se respetaron las funciones utilizadas en el código original y las generadaspor CPPAutoGen.hx. Fue necesario completar el cuerpo de estas funciones y lasmodi�caciones que se realizaron para que el juego funcione son:

Cambiar el cuerpo del método convar para pasar Int a String

Cambiar string por String

Return String a partir de un entero

Eliminar del paquete System los archivos String.hx y Stringstream.hx

Reemplazar llamadas a color(c) por color_rgb(r, g, b)

Crear el tablero de juego (GameTable) el cual contiene toda la ventanagrá�ca (barras, pelota, contadores y limites).

Modi�car los cuerpos de algunas funciones en Main.hx para incluir elfuncionamiento de Sprites especí�cos de la interfaz grá�ca de Haxe. Elcuerpo del while que se encontraba en el main se movió a una nuevafunción update() la cual es llamada por el tablero.

El resultado luego de aplicar estas modi�caciones, compilado para Neko, es unjuego de ping pong totalmente funcional, como se muestra en la Figura 6.15.

Figura 6.15: Ping Pong Haxe

Luego, se añadieron las funciones necesarias para que el movimiento nose realice a través de teclas, sino que sea a través de la pantalla táctil de un


smartphone. El resultado, luego de compilar el código fuente para Android, esun juego totalmente funcional que puede jugarse en un dispositivo móvil.

6.3. Tetris

El juego Tetris escrito en el lenguaje C++, se descargó a partir de losvideos provistos en: http://www.minidosis.org/#/temas/Juegos.Tetris. Puedeverse una captura del juego en la Figura 6.16.

Figura 6.16: Clásico juego de Tetris

El proyecto está compuesto por tres archivos de código fuente: miniwin.h,miniwin.cpp y tetris.cpp. Los archivos miniwin.h y miniwin.cpp correspondena una librería propia de C/C++, la cual permite realizar la parte grá�ca deljuego, como abrir una ventana, pintar en ella, detectar la presión de las teclasy el movimiento y los botones del mouse.

Los archivos pueden encontrarse en el repositorio del proyecto. No seincluyeron debido a su extensión.

6.3.1. Proceso

Aclaración: la libreria miniwin no será transformada por su dependencia conlibrerías propias de C/C++.


El primer paso, al tener el código fuente, será aplicarle el proceso deingeniería inversa para lograr el descubrimiento del modelo y generar, deesta manera, el archivo .xmi que representa la instancia del modelo C++correspondiente al programa que conforma al metamodelo desarrollado. Elresultado se encuentra es el archivo TetrisCPP.xmi. El siguiente paso consisteen aplicar la transformación modelo a modelo escrita en ATL a ese modelode entrada. El resultado de la misma es otro archivo .xmi (TetrisHaxe.xmi)que representa la instancia del modelo Haxe correspondiente al programa encuestión y que conforma al metamodelo del lenguaje Haxe.

Luego de aplicar la transformación, lo siguiente es realizar proceso deingeniería directa. El mismo, genera como resultado un proyecto Haxe completocompuesto por una carpeta �src� y un archivo build.hxml. Dentro de la carpeta�src�, se generan las carpetas que corresponden a los diferentes paquetes, queen este caso son solo dos: �defaultpkg� y �system�. Dentro de �defaulpkg�se encuentra el archivo Tetris.hx, que corresponde a la implementación enHaxe de lo mismo que se encontraba implementado en C++. La carpeta�system� contiene los archivos CPPAutoGen.hx, String.hx y Stringstream.hx.Las implementaciones de String.hx y Stringstream.hx son iguales al caso PingPong, ya que estas son auto-generadas durante la ingeniería inversa.


1. En primer lugar, se puede observar la función tablero_cuenta_lineas()en C++, que se compone de una declaración de variables y un while:



3. Luego, se muestra el modelo Haxe luego de aplicada la transformaciónATL:



Luego de obtener el código transformado, se debe realizar una interfazgrá�ca propia del lenguaje Haxe. Para ello, se utilizó el framework OpenFLy se respetaron las funciones utilizadas en el código original y las generadaspor CPPAutoGen.hx. Fue necesario completar el cuerpo de estas funciones y lasmodi�caciones que se realizaron para que el juego funcione son:

Cambiar el cuerpo de a_string para pasar Int a String

Cambiar string por String

Return String a partir de un entero

Eliminar del paquete System los archivos String.hx y Stringstream.hx

Crear el tablero de juego (GameTable) el cual contiene toda la ventanagrá�ca (límites, puntuación, niveles, �cha siguiente y tablero)

Modi�car los cuerpos de algunas funciones en Tetris.hx para incluir elfuncionamiento de Sprites especí�cos de la interfaz grá�ca de Haxe. Elcuerpo del while que se encontraba en el main se movió a una nuevafunción update() la cual es llamada por el tablero.

Agregar constructores a las clases generadas a partir de un Struct y hacerpúblicas sus variables. (Aplica para Coord y Pieza)

Agregar Sprite y método copiar a la clase Pieza

El resultado luego de aplicar estas modi�caciones, compilado para Neko, es eljuego Tetris totalmente funcional, como se muestra en la Figura 6.17.


Figura 6.17: Tetris compilado para Neko

Luego, se añadieron las funciones necesarias para que el movimiento nose realice a través de teclas, sino que sea a través de la pantalla táctil de unsmartphone. El resultado, luego de compilar el código fuente para Android, esun juego totalmente funcional que puede jugarse en un dispositivo móvil.

Capítulo 7

Conclusiones

A lo largo del presente trabajo se describió un proceso general para realizaruna migración desde el lenguje C/C++ hacia plataformas móviles a través dellenguaje Haxe y utilizando el enfoque Dirigido por Modelos. Este proceso fuevalidado a través de la implementación tres casos de estudio completos, unprograma muy simple y dos juegos: un Ping Pong y un Tetris. El resultadode esta implementación es una herramienta que toma como punto de partidaun proyecto escrito en C/C++ y produce como salida un proyecto equivalentesescrito en Haxe, además de los archivos intermedios generados.

ContribucionesSe pueden mencionar como principales contribuciones de este trabajo:

La especi�cación de un metamodelo Ecore para el lenguaje C/C++, quepermite su integración en MDA, ya que no se ha encontrado ningunoespeci�cado detalladamente hasta el momento.

La de�nición de un proceso para ingeniería inversa de código fuenteC/C++ a un Modelo Especí�co de la Plataforma (PSM), a través deun programa Java y un constructor de parsers.

La transformación de modelos C/C++ a modelos Haxe, a través dellenguaje ATL.

La implementación de una herramienta que lleva a cabo la migración decódigo existente en C/C++ de manera semiautomática hacia el lenguajeHaxe.

DesafíosLa implementación de este proceso nos permitió conocer y enfrentar los

desafíos que implica desarrollar un proceso de estas características y utilizandoel enfoque Dirigido por Modelos. Los mismos fueron:

98

CAPÍTULO 7. CONCLUSIONES 99

El primer desafío tiene que ver con la especi�cación del metamodelo paraun lenguaje especí�co y, en este caso concreto, para el lenguaje C/C++.Al ser un lenguaje tan amplio y con tantas construcciones, la especi�cacióndel mismo llevó un tiempo considerable.

El segundo desafío fue la construcción de una herramienta para laingeniería inversa de código C/C++. Esta tarea implicó considerar todoslos elementos del lenguaje y proveer el tratamiento adecuado para cadauno. Esta tarea, en el caso de una gramática como la del lenguaje C/C++requirió gran cantidad de tiempo en análisis e implementación.

El tercer desafío fue la implementación de las transformaciones entrelos metamodelos de C/C++ a Haxe. Para de�nir los mapeos entremetamodelos requeridos para realizar transformaciones de modelos, sedebió lograr un amplio entendimiento de los metamodelos utilizados, sobretodo el de destino, ya que no fue especi�cado por nosotros.

LimitacionesPor otro lado, la implementación de una herramienta y su utilización en

distintos casos de prueba, nos permitió comprobar la validez de la migraciónpropuesta así como analizar los bene�cios y limitaciones de los resultadosobtenidos. Las limitaciones que encontramos son:

El lenguaje C/C++ no es puramente orientado a objetos, como lo es ellenguaje Haxe. Esto llevó a que las migraciones no re�ejen por completo,en ciertos casos, la estructura del programa original en C/C++.

Luego de ser generado el código Haxe, siempre se requiere trabajo adicionalpara que sea completamente funcional, ya que surgen algunos errores(como se vio en los casos de estudio), que están dados por la gran diferenciaque existe entre ambos lenguajes.

Las interfaces grá�cas de los programas siempre están atadas a bibiliotecasespecí�cas de los lenguajes. Por lo tanto, una limitación importante es laimposibilidad de migrar la parte visual de las aplicaciones.

La transformación entre modelos mediante ATL depende de Eclipse parapoder ejecutarse. Por lo que es necesario poseer Eclipse con ATL instaladopara llevar a cabo esa fase de la migración.

Las directivas para el pre-compilador de C/C++ (#include, #macro,#if, entre otras) son descartadas (al igual que los comentarios) por lagramática, por lo que no se han contemplado.

Trabajo FuturoLa elaboración de este trabajo, puso en evidencia nuevas posibilidades para

trabajos futuros, como así algunas mejoras a la implementación existente. Acontinuación se mencionan algunas de ellas:


Integración de la herramienta en la plataforma Eclipse: al igual queMoDisco, la misma podría integrarse mediante un plugin que permitarealizar el descubrimiento de modelos C/C++ y migración, todo dentrode la misma plataforma.

Mejora y re�namiento del metamodelo C/C++ y del parser: elmetamodelo puede seguir re�nándose y agregándole construcciones quefalten, al igual que al parser.

Re�nar el código ATL para poder generar un código compatible conEMFTVM. De esta manera podría ejecutarse la migración completa sindepender de Eclipse.

Re�namiento de la gramática. Si bien la gramática utilizada es la provistapor Antlr, aún pueden hacerse re�naciones en la misma.

7.1. Conclusiones generales

Como primer conclusión a la que se llegó luego de �nalizar el proceso es quees posible la migración de aplicaciones escritas en lenguajes como los son C yC++ hacia plataformas móviles de manera semiautomática, dentro de los límitesde las herramientas y los metamodelos. En particular, fue posible transformarla lógica de aplicaciones propuestas y ejecutarlas en plataformas móviles, sinrecurrir a una reescritura completa de las mismas, aunque se debió realizaralgún tipo de trabajo manual para que sean totalmente funcionales.

El uso del enfoque Dirigido por Modelos para llevar a cabo el procesopermitió representar el conocimiento extraído del código fuente en forma demodelos, a los que se les pudieron aplicar transformaciones para llevar a caboun proceso de migración. Esto nos lleva a resaltar las ventajas de utilizar estastécnicas [47].

Reusabilidad: se pudo crear un proceso completamente reutilizablepara migrar cualquier aplicación escrita en C/C++ hacia Haxe. Estacaracterística se logró gracias a la utilización de modelos y metamodeloscomo guías del proceso.

Extensibilidad: el proceso descripto puede ser extendido con nuevas etapaso incluso ser modi�cado con etapas que reemplazan a las existentes.Los modelos generados en las distintas etapas constituyen un punto deextensión válido para incorporar nuevas etapas.

Reutilización: los fragmentos de las cadenas de transformación puedenreutilizarse de�niendo metamodelos que desacoplen unas partes de otras,y de�niendo las transformaciones hacia y desde esos metamodelos. Porejemplo, de esta migración, podría utilizarse el fragmento de ingenieríainversa y descubrimiento del modelo C/C++ para utilizarse en una nuevatransformación hacia otro lenguaje, o hacia un nivel de abstracción másalto.


Interoperabilidad con herramientas de terceros: los modelos constituyenun punto de extensión que facilita la integración con aplicaciones deterceros, aunque no estén implementadas con un enfoque MDE. Unaaplicación de terceros que requiera una entrada serializada y genere unasalida serializada puede ser integrada en una cadena de transformación.Habría que seleccionar dos puntos de extensión (modelos), uno parala entrada y otro para la salida de datos de la aplicación de terceros.La incompatibilidad para el punto de entrada se soluciona con unatransformación M2T y la del punto de salida con una transformación T2M.En este caso, se puede observar que cualquier aplicación de terceros escritaen C/C++ puede ser migrada.

Uni�cación e Integración: los lenguajes de metamodelado como Ecoreo MOF tienen gran potencia expresiva y existen potentes lenguajesde transformación de modelos para implementar las transformacionesrequeridas en las etapas del proceso, además de la posibilidad de de�nirrestricciones en los metamodelos y la libertad de de�nir cualquier tipo denotación para un modelo. Esto permite la uni�cación de metamodelos yla fácil integración y transformación de los mismos.

La utilización de este enfoque también llevó a observar las limitaciones quepresenta, que están relacionadas principalmente por la carencia o inmadurez delas herramientas que soportan estos procesos.

Carencia de herramientas para ciertos lenguajes de programación: elframework MoDisco ofrece varios discoverers que generan un modelo KDMa partir de Java, JSP y XML entre otros, pero para otros lenguajes esnecesario implementar el discoverer, lo cual no es sencillo. En este caso,como el lenguaje a utilizar era C/C++, fue necesario construir uno propio.

Inmadurez de los entornos de desarrollo MDE: a pesar de que Eclipseproporciona su framework de modelado, las herramientas aún no seencuentran maduras, sobre todo para la fase de transformaciones a travésde ATL y de ingeniería directa con Acceleo.

Bibliografía

[1] Acceleo (2015). Obeo. Acceleo Generator.http://www.eclipse.org/acceleo/

[2] ADM (2015). Architecture-driven modernization task force.http://www.adm.org

[3] ASTM (2011). OMG Architecture-driven Modernization:Abstract Syntax Tree Metamodel (ASTM), versión 1.0,http://www.omg.org/spec/ASTM.

[4] Bowen, J., Hinze, A. (2011). Supporting mobile application developmentwith modeldriven emulation. Journal of the ECEASST, Volumen 45 (pp. 1-5).

[5] Brambilla, M. Cabot, J., Wimmer, M (2012). Model-Driven SoftwareEnginneering in Practice, Synthesis Lectures on Software Engineering. Morgan& Claypool Publishers.

[6] Braun, P., Eckhaus, R. (2008). Experiences on model-driven softwaredevelopment for mobile applications. In Proceedings of Engineering ofComputer-Based Systems, IEEE International Conference and Workshop onthe Engineering of computer Base Systems (pp. 490-493), Los Alamitos: IEEEComputer Society.

[7] Bruneliere, H. Cabot, J. Dupé, G., Madiot, F. (2014). MoDisco: a ModelDriven Reverse Engineering Framework. Information and Software Technology56 (pp. 1012- 1032).

[8] Cannasse, N. (2014). Haxe. Too Good to be True? GameDuell Tech Talk.http://www.techtalk-berlin.de/news/read/nicolas-cannasse-introducing-Haxe/

[9] CASE MDA. (2015). Committed companies and their products.www.omg.org/mda/committed-products.htm

[10] Dasnois, B. (2011). Haxe 2 Beginner's Guide. Packt Publishing.[11] Dehlinger, J., Dixon, J. (2011). Mobile application software engineering:

Challenges and research directions. Proceedings of the Workshop on MobileSoftware Engineering (pp. 29-32), Berlin Heidelberg: Springer-Verlag.

[12] Díaz Bilotto, Pablo; Favre, Liliana (en prensa) Migrating JAVA toMobile Platforms through Haxe: An MDD Approach, Aceptado como capítulodel libro Modern Software Engineering Methodologies for Mobile and CloudEnvironments. Editores: Antonio Miguel Cruz , Sara Paiva. IGI GLOBAL, USA.2016

[13] Dunkel, J., Bruns, R. (2007). Model-driven architecture for mobile

102


applications. In Business Information Systems, W. Abramowicz, Ed., LectureNotes in Computer Science, Volumen 4439 (pp. 464-477), Berlin Heidelberg:Springer-Verlag.

[14] EMF (2015) Eclipse Modeling Framework (EMF) Retrieved April 15,2015 from http://www.eclipse.org/modeling/emf/

[15] Jouault, F., Allilaire, F., Bézivin, J., Kurtev, I (2008). ATL: A modeltransformation tool. Science of Computer Programming 72, 1 (pp. 31-39).

[16] Jouault, F., Allilaire, F., Bézivin, J., Kurtev, I., Valduriez, P: (2006)ATL: a QVT-like transformation language. Companion to the 21st ACMSIGPLAN Symposium on Objectoriented programming systems, languages, andapplications (New York, NY, USA, 2006), OOPSLA '06 (pp. 719-720), NewYork: ACM Press.

[17] Jouault, F., Kurtev, I. (2005). Transforming models with ATL. InSatellite Events at the MoDELS 2005 Conference (Berlin, 2006), LectureNotes in Computer Science, vol. 3844, Berlin Heidelberg: Springer Verlag (pp.128-138).

[18]KDM. OMG (2011). Architecture-Driven Modernization: KnowledgeDiscovery MetaModel (KDM), versión 1.3, http://www.omg.org/

[19] Kim, H. K. (2008). Frameworks of process improvement for mobileapplications. Engineering Letters 16, 4 (pp. 550-555).

[20] Kramer, D., Clark, T., Oussena, S. (2010). MobDSL: A domain speci�clanguage for multiple mobile platform deployment. Networked EmbeddedSystems for Enterprise Applications (NESEA), 2010 IEEE InternationalConference (pp. 1-7), Los Alamitos: IEEE Press.

[21] Lettner, M., Tschernuth, M., Mayrhofer, R. (2012). Mobile platformarchitecture review: Android, Iphone, Qt. In Computer Aided Systems TheoryEUROCAST 2011, R. Moreno-Díaz, F. Pichler, and A. Quesada-Arencibia,Lecture Notes in Computer Science, Volumen 6928 (pp. 544-551). BerlinHeidelberg: Springer-Verlag.

[22] MMT (2015). Model-to-Model Transformation. Eclipse ModelingFramework. Retrieved April 15, 2015, https://www.eclipse.org/mmt/

[23] MoDisco. (2012). Model discovery. Retrieved April 15, 2015http://www.eclipse.org/MoDisco

[24] MOF (2011). OMG Meta Object Facility (MOF) corespeci�cation version 2.4.1. OMG Document Number:formal/2011-08-07.http://www.omg.org/spec/MOF/2.4.1

[25] MOFM2T (2008). MOF Model to Text Transformation Language,Version 1.0. http://www.omg.org/spec/MOFM2T/1.0/

[26] OCL (2014). OMG Object constraint language (OCL), version 2.4.http://www.omg.org/spec/OCL/2.4

[27] OCLinEcore (2015) OCLinEcore Editor.http://wiki.eclipse.org/MDT/OCLinEcore.

[28] OMG MDA (2014). MDA guide version rev. 2.0 OMG Documentormsc/2014-06-01. http://www.omg.org/cgi-bin/doc?ormsc/14-06-01

[29] Parr, T. (2013) The De�nitive ANTLR 4 Reference. PragmaticBokkshelf, Second Edition.


[30] Pérez Castillo, R., García Rodriguez, I., Gómez Cornejo, R., FernándezRopero, M., Piattini, M. (2013). ANDRIU. A Technique for Migrating GraphicalUser Interfaces to Android. Proceedings of The 25th International Conference onSoftware Engineering and Knowledge Engineering (SEKE 2013) (pp. 516-519)Boston: Knowledge Systems Institute.

[31] QVT (2012). QVT: MOF 2.0 query, view,transformation:Version 1.1. OMG Document Number: formal/2011-01-01.http://www.omg.org/spec/QVT/1.1/SMM

[32] Steinberg, D., Budinsky, F., Paternostro, M., Merks, E. (2009). EMF:Eclipse Modeling Framework, 2 ed. Addison-Wesley, Boston, MA.

[33] Thompson, C., Schmidt, D., Turner, H., White, J. (2011).Analyzing Mobile Application Software Power Consumption via Model-DrivenEngineering, Proceedings of PECCS 2011 (pp. 101-113).

[34] Wasserman, A. I. (2010). Software engineering issues for mobileapplication development. Proceedings of the FSE/SDP workshop on Future ofsoftware engineering research (FoSER '10), (pp. 397-400) New York, NY: ACM.

[35] Umuhoza, E., Ed-douibi, H., Brambilla, M., Cabot, J., Bongio, A. (2015).Automatic Code Generation for Cross-platform, Multi-Device Mobile Apps:Some Re�ections from an Industrial Experience. In 3rd International Workshopon Mobile Development Lifecycle, MobileDeli 2015.

[36] Biehl, Matthias (2010). Literature Study on Model Transformations.Technical Report ISRN/KTH/MMK/R-10/07-SE, Royal Institute ofTechnology.

[37] OpenFL framework. http://www.open�.org[38] HaxeFlixel framework. http://Haxe�ixel.com[39] HaxePunk framework. http://Haxepunk.com[40] C++ Guide. http://www.cplusplus.com[41] EMF4CPP : what is EMF4CPP?

http://code.google.com/archive/p/emf4cpp[42] N.islam, R.Want Smathphones:Past, present and future. Pervasive

Computing, 13(4), 82-92, 2014[43] XMI. XML Metadata Interchange (XMI) Speci�cation. OMG Document

<Number formal/2014-04-04. http://www.omg.org/spec/XMI/2.4.2/PDF/,2014

[44] ATL Documentation. https://eclipse.org/atl/documentation/[45] E. Chikofsky y J. Cross, �Reverse engineering and design recovery: A

taxonomy�, IEEE Software, vol. 7, n.o 1, págs. 13-17, 1990.[46] Haxe Documentation. http://Haxe.org/documentation/[47] Sánchez Ramón,O., García Molina, J. (2013). Una valoración de

Modernización de Software Dirigida por Modelos. Conference Paper: JISBD'13.[48] Object Management Group. http:/www.omg.org[49] Graph Exchange Language. http://www.gupro.de/GXL[50] Rigi Standard Format. http://www.rigi.cs.uvic.ca

Apéndice A

Metamodelos

Se presentan a continuación los metamodelos correspondientes a loslenguajes con los que se trabajó en el presente trabajo: Haxe y C/C++.

A.1. Metamodelo del lenguaje Haxe

1 package Haxe : _' org . e c l i p s e . emf . e co re . Haxe ' =2 ' http ://Haxe . unicen . edu . ar '3 {4 enum HaxeTarget { s e r i a l i z a b l e }5 {6 l i t e r a l neko ;7 l i t e r a l cpp ;8 l i t e r a l java ;9 l i t e r a l f l a s h ;10 l i t e r a l c s ;11 l i t e r a l j s ;12 }13 c l a s s HaxeModel14 {15 annotat ion ;16 a t t r i b u t e name : S t r ing { id }17 a t t r i b u t e sourceFo lder : S t r ing = ' src '18 a t t r i b u t e ta rge tFo lde r : S t r ing = ' out '19 a t t r i b u t e t a r g e t : HaxeTarget20 property mainClass : HaxeClass21 property e lements : HaxePathReferent iable [ ∗ ]22 { composes }23 property r e f e r en c ed : HaxePathReferent iable [ ∗ ]24 { composes }25 property HaxeModules : HaxeModule [ ∗ ] { composes }

105

APÉNDICE A. METAMODELOS 106

26 i nva r i an t sourceFolderNotEmpty :27 sourceFo lder . s i z e ( ) > 0 ;28 i nva r i an t targetFolderNotEmpty :29 ta rge tFo lde r . s i z e ( ) > 0 ;30 i nva r i an t31 mainClassHasMainMethod : not ( mainClass .32 HaxeOperations33 −>s e l e c t ( x : HaxeOperation | ( x . name .34 matches ( 'main ' ) and x . i s S t a t i c and35 x . formalParameters36 −>isEmpty ( ) ) )37 −>isEmpty ( ) ) ;38 i nva r i an t nameNotEmpty : name . s i z e ( ) > 0 ;39 i nva r i an t nameNotNull : name <> nu l l ;40 }41 abs t r a c t c l a s s HaxeModelElement42 ab s t r a c t c l a s s HaxeASTNode extends HaxeModelElement43 {44 property comments : HaxeComment [ ∗ ] { ordered45 composes }46 }47 abs t r a c t c l a s s HaxeNamedElement extends HaxeASTNode48 {49 a t t r i b u t e name : S t r ing50 i nva r i an t nameNotEmpty : name . s i z e ( ) > 0 ;51 }52 c l a s s HaxeComment extends HaxeASTNode53 {54 a t t r i b u t e enclosedByParent : Boolean ;55 a t t r i b u t e pre f ixOfParent : Boolean ;56 a t t r i b u t e content : S t r ing57 a t t r i b u t e lineComment : Boolean58 }59 c l a s s HaxeHaxedocComment extends HaxeComment60 {61 property tags : HaxeTagElement [ ∗ ]62 { ordered composes }63 }64 c l a s s HaxeTagElement extends HaxeASTNode65 {66 a t t r i b u t e tagName : S t r ing [ ? ]67 property fragments : HaxeASTNode [ ∗ ]68 { ordered composes }69 }70 c l a s s HaxeTextElement extends HaxeASTNode71 {


72 a t t r i b u t e t ext : S t r ing73 }74 abs t r a c t c l a s s HaxePathReferent iable extends75 HaxeNamedElement76 {77 property parentReference#ch i l d r enRe f e r en c e s :78 HaxePackage [ ? ]79 property r e f e r en c ed In#re fe rencedTermina l :80 HaxePathReference [ ∗ ] { readonly v o l a t i l e }81 }82 abs t r a c t c l a s s HaxePathReference extends83 HaxeModelElement84 {85 property re f e rencedTermina l#r e f e r en c ed In :86 HaxePathReferent iable [ ? ]87 }88 abs t r a c t c l a s s HaxeFie ldContainer extends89 HaxeModelElement90 {91 property HaxeFie lds#f i e l dCon t a i n e r : HaxeField [ ∗ ]92 { ordered composes ! r e s o l v e }93 }94 abs t r a c t c l a s s HaxeExpression extends HaxeASTNode95 abs t r a c t c l a s s HaxeLoopStatement extends96 HaxeExpression97 {98 property theBody : HaxeExpression { composes }99 property exp r e s s i on : HaxeExpression { composes }100 }101 abs t r a c t c l a s s HaxeUnaryExpression extends102 HaxeExpression103 {104 property operand : HaxeExpression { composes }105 }106 abs t r a c t c l a s s HaxeBinaryExpression extends107 HaxeExpression108 {109 property l e f t S i d e : HaxeExpression { composes }110 property r i gh tS i d e : HaxeExpression { composes }111 }112 c l a s s HaxeBlock extends HaxeExpression113 {114 opera t i on isEmpty ( ) : Boolean115 {116 body : statements−>isEmpty ( ) ;117 }


118 property statements : HaxeExpression [ ∗ ]119 { ordered composes }120 }121 abs t r a c t c l a s s HaxeCondit ionalExpress ion extends122 HaxeExpression123 {124 property exp r e s s i on : HaxeExpression { composes }125 property thenStatement : HaxeExpression126 { composes }127 }128 c l a s s HaxeIfStatement extends129 HaxeCondit ionalExpress ion130 {131 property e l s eStatement : HaxeExpression [ ? ]132 { composes }133 }134 c l a s s HaxeTernaryExpression extends135 HaxeCondit ionalExpress ion136 {137 property e l s eExp r e s s i on : HaxeExpression138 { composes }139 }140 c l a s s HaxeForStatement extends HaxeLoopStatement141 {142 annotat ion ;143 property parameter :144 HaxeS ing l eVar iab l eDec la ra t ion { composes }145 }146 c l a s s HaxeWhileStatement extends HaxeLoopStatement147 c l a s s HaxeInExpression extends HaxeExpression148 {149 property va r i ab l e :150 HaxeS ing l eVar iab l eDec la ra t ion { composes }151 property exp r e s s i on : HaxeExpression { composes }152 }153 c l a s s HaxeDoWhileStatement extends HaxeLoopStatement154 c l a s s HaxePre f ixExpress ion extends HaxeUnaryExpression155 {156 a t t r i b u t e operator : HaxePref ixOperators157 }158 c l a s s HaxeIn f ixExpress ion extends159 HaxeBinaryExpression160 {161 property extendedSide : HaxeExpression [ ∗ ]162 { composes }163 a t t r i b u t e operator : HaxeInf ixOperators


164 }165 c l a s s HaxePost f ixExpress ion extends166 HaxeUnaryExpression167 {168 a t t r i b u t e i s Increment : Boolean169 }170 c l a s s HaxeReturn extends HaxeExpressionStatement171 c l a s s HaxeBreak extends HaxeExpression172 c l a s s HaxeContinue extends HaxeExpression173 c l a s s HaxeThisExpression extends HaxeExpression174 c l a s s HaxeEmptyStatement extends HaxeExpression175 abs t r a c t c l a s s HaxeConstant extends HaxeExpression176 c l a s s HaxeSt r ingL i t e ra l extends HaxeConstant177 {178 a t t r i b u t e escapedValue : S t r ing ;179 }180 c l a s s HaxeNul lL i t e ra l extends HaxeConstant181 c l a s s HaxeBooleanLitera l extends HaxeConstant182 {183 a t t r i b u t e value : Boolean ;184 }185 c l a s s HaxeNumberLiteral extends HaxeConstant186 {187 a t t r i b u t e value : S t r ing ;188 }189 c l a s s Hax e I d e n t i f i e r L i t e r a l extends HaxeConstant190 {191 a t t r i b u t e value : S t r ing ;192 }193 c l a s s HaxeRegexLiteral extends HaxeConstant194 {195 a t t r i b u t e pattern : S t r ing ;196 a t t r i b u t e opt ions : S t r ing ;197 }198 c l a s s HaxeFieldAccess extends HaxeExpression199 {200 property f i e l d : HaxeS ing leVar iab leAccess201 { composes } ;202 property exp r e s s i on : HaxeExpression203 { composes } ;204 }205 c l a s s HaxeParenthizedExpress ion extends HaxeExpression206 {207 property exp r e s s i on : HaxeExpression { composes } ;208 }209 c l a s s HaxeAr r ay In i t i a l i z e r extends HaxeExpression


210 {211 property exp r e s s i on s : HaxeExpression [+]212 { composes } ;213 }214 c l a s s HaxeArrayCreation extends HaxeExpression215 {216 property dimensions : HaxeExpression [ ∗ ]217 { ordered composes } ;218 property i n i t i a l i z e r : HaxeAr r ay In i t i a l i z e r [ ? ]219 { composes } ;220 property type : HaxeTypeAccess { composes } ;221 }222 c l a s s HaxeArrayAccess extends HaxeExpression223 {224 property array : HaxeExpression { composes } ;225 property index : HaxeExpression { composes } ;226 }227 c l a s s HaxeSwitch extends HaxeExpression228 {229 property exp r e s s i on : HaxeExpression { composes } ;230 property ca s e s : HaxeCase [ ∗ ] { composes } ;231 property d e f au l t : HaxeExpression [ ∗ ] { composes } ;232 }233 c l a s s HaxeCase extends HaxeExpression234 {235 property va lue s : HaxeExpression [+] { composes } ;236 property exp r e s s i on : HaxeExpression { composes } ;237 }238 c l a s s HaxeFunctionExpression extends HaxeExpression ,239 HaxeAbstractFunction ;240 c l a s s HaxeCal lExpress ion extends HaxeExpression241 {242 property exp r e s s i on : HaxeExpression { composes } ;243 property arguments : HaxeExpression [ ∗ ]244 { ordered composes } ;245 }246 c l a s s HaxeObjectDeclarat ion extends HaxeExpression247 {248 property extendsType : HaxeTypeAccess [ ? ]249 { composes } ;250 property f i e l d s : HaxeFie ldDec larat ion [+]251 { composes } ;252 }253 c l a s s HaxeFie ldDec larat ion extends254 HaxeNamedElement , HaxeTypedElement255 {


256 property value : HaxeExpression { composes } ;257 }258 c l a s s HaxeTryExpression extends HaxeExpression259 {260 property theBody : HaxeExpression { composes } ;261 property catchClauses : HaxeCatchClause [ ∗ ]262 { ordered composes } ;263 }264 c l a s s HaxeCatchClause extends HaxeExpression265 {266 property except ion#catchClause :267 HaxeS ing l eVar iab l eDec la ra t ion { composes } ;268 property theBody : HaxeExpression { composes } ;269 }270 c l a s s HaxeThrowExpression extends271 HaxeExpressionStatement ;272 c l a s s HaxeExpressionStatement extends HaxeExpression273 {274 annotat ion ;275 property exp r e s s i on : HaxeExpression { composes } ;276 }277 c l a s s HaxeCastingExpress ion extends HaxeExpression278 {279 property exp r e s s i on : HaxeExpression { composes } ;280 property type : HaxeTypeAccess { composes } ;281 }282 c l a s s HaxeUnsafeCastExpression extends HaxeExpression283 {284 property exp r e s s i on : HaxeExpression { composes } ;285 }286 c l a s s HaxeTypeCheckExpression extends HaxeExpression287 {288 property exp r e s s i on : HaxeExpression { composes } ;289 property type : HaxeTypeAccess { composes } ;290 }291 c l a s s HaxeSuperMethodInvocation extends292 HaxeExpression , HaxeAbstractMethodInvocation ;293 c l a s s HaxeMethodInvocation extends294 HaxeExpression , HaxeAbstractMethodInvocation295 {296 property exp r e s s i on : HaxeExpression [ ? ]297 { composes } ;298 }299 c l a s s HaxeSuperConstructorInvocat ion extends300 HaxeMethodInvocation ;301 c l a s s HaxeS ing leVar iab leAccess extends HaxeExpression


302 {303 property q u a l i f i e r : HaxeExpression [ ? ]304 { composes } ;305 property va r i ab l e#usageInVar iab leAcces s :306 HaxeVar iab leDec larat ion { ! r e s o l v e } ;307 }308 c l a s s HaxePackageAccess extends HaxeExpression ,309 HaxePathReference310 {311 property q u a l i f i e r : HaxePackageAccess [ ? ]312 { composes } ;313 }314 c l a s s HaxeAssignment extends HaxeBinaryExpression315 {316 a t t r i b u t e operator : HaxeAssignmentOperator ;317 }318 abs t r a c t c l a s s HaxeAbstractMethodInvocation extends319 HaxeASTNode320 {321 property method : HaxeAbstractOperation ;322 property arguments : HaxeExpression [ ∗ ]323 { ordered composes } ;324 property typeArguments : HaxeTypeAccess [ ∗ ]325 { ordered composes } ;326 }327 abs t r a c t c l a s s HaxeVar iab leDec larat ion extends328 HaxeNamedElement329 {330 property usageInVar iab leAccess#va r i ab l e :331 HaxeSing leVar iab leAccess [ ∗ ] { readonly332 t r an s i e n t v o l a t i l e ! r e s o l v e } ;333 property i n i t i a l i z e r : HaxeExpression [ ? ]334 { composes } ;335 i nva r i an t variableNameRegex : name . matches336 ( ' [ a−zA−Z_ ] [ a−zA−Z0−9_] ∗ ' ) ;337 }338 c l a s s HaxeVariableDeclarationGroup extends339 HaxeTypedElement340 {341 property conta ine r#groups :342 HaxeVar iab leDec larat ionExpress ion { t r an s i e n t343 v o l a t i l e } ;344 property i n i t i a l i z e r : HaxeExpression [ ? ]345 { composes } ;346 property fragments#var i ab l e sConta in e r :347 HaxeVariableDeclarationFragment [ ∗ ] { composes } ;


348 }349 c l a s s HaxeVariableDeclarat ionFragment extends350 HaxeVar iab leDec larat ion351 {352 property va r i ab l e sConta ine r#fragments :353 HaxeVariableDeclarationGroup [ ? ] { t r a n s i e n t354 v o l a t i l e } ;355 }356 c l a s s HaxeVar iab leDec larat ionExpress ion extends357 HaxeExpression358 {359 property groups#conta ine r :360 HaxeVariableDeclarationGroup [+] { composes } ;361 }362 c l a s s HaxeS ing l eVar iab l eDec la ra t i on extends363 HaxeVariableDeclarat ion , HaxeTypedElement364 {365 a t t r i b u t e i sOpt i ona l : Boolean ;366 property catchClause#except ion : HaxeCatchClause [ ? ] ;367 }368 c l a s s HaxePackage extends HaxePathReferent iable369 {370 property ch i l d r enRe f e r en c e s#parentReference :371 HaxePathReferent iable [ ∗ ] { composes } ;372 property ch i ldrenPackages : HaxePackage [ ∗ ]373 { der ived readonly v o l a t i l e }374 {375 de r i v a t i on : ch i l d r enRe f e r en c e s376 −>s e l e c t ( x | x . oc l I sKindOf (HaxePackage ) )377 −>c o l l e c t ( x | x . oclAsType (HaxePackage ) ) ;378 }379 property containedTypes : HaxeType [ ∗ ] { der ived380 readonly v o l a t i l e }381 {382 de r i v a t i on : ch i l d r enRe f e r en c e s383 −>s e l e c t ( x | x . oc l I sKindOf (HaxeType ) )384 −>c o l l e c t ( x | x . oclAsType (HaxeType ) ) ;385 }386 i nva r i an t packageNameRegex : name . matches387 ( ' [ a−z ] [ A−Z0−9a−z_− ]∗ ' ) ;388 }389 c l a s s HaxeModule extends HaxeNamedElement390 {391 property commentList : HaxeComment [ ∗ ]392 { ordered } ;393 property dependenc ies :


394 HaxeDependencyDeclaration [ ∗ ] { composes } ;395 property thePackage : HaxePackage [ ? ] ;396 property theElements#containerModule :397 HaxeType [ ∗ ] ;398 i nva r i an t moduleNameRegex : name . matches399 ( ' [A−Z ] [A−Z0−9a−z_− ]∗ ' ) ;400 }401 abs t r a c t c l a s s HaxeType extends HaxePathReferent iable ,402 HaxeASTNode403 {404 a t t r i b u t e p r i va t e : Boolean ;405 a t t r i b u t e extern : Boolean ;406 property containerModule#theElements :407 HaxeModule [ ? ] ;408 property commentsAfterDeclarat ion :409 HaxeComment [ ∗ ] { ordered composes } ;410 property commentsBeforeDeclarat ion :411 HaxeComment [ ∗ ] { ordered composes } ;412 property typeParameters :413 HaxeTypeParameter [ ∗ ] { composes } ;414 }415 abs t r a c t c l a s s HaxeC l a s s i f i e r extends HaxeType ,416 HaxeFieldContainer , HaxeMetadataContainer417 {418 property conta inerPackage : HaxePackage [ ? ]419 { der ived readonly t r an s i e n t v o l a t i l e }420 {421 de r i v a t i on : i f ( containerModule .422 oc l I sUnde f ined ( ) )423 then nu l l424 e l s e containerModule . thePackage425 end i f ;426 }427 property HaxeOperations : HaxeOperation [ ∗ ]428 { der ived readonly v o l a t i l e }429 {430 de r i v a t i on : s e l f . HaxeFie lds431 −>s e l e c t ( e : HaxeField | e . oc lIsTypeOf432 ( HaxeOperation ) ) . oclAsType ( HaxeOperation ) ;433 }434 property HaxeAttribute : HaxeAttribute [ ∗ ]435 { der ived readonly v o l a t i l e }436 {437 de r i v a t i on : s e l f . HaxeFie lds438 −>s e l e c t ( e : HaxeField | e . oc l I sKindOf439 ( HaxeAttribute ) ) . oclAsType ( HaxeAttribute ) ;


440 }441 property HaxeConstructors : HaxeConstructor [ ∗ ]442 { der ived readonly v o l a t i l e }443 {444 de r i v a t i on : HaxeFie lds445 −>s e l e c t (m : HaxeField | m. oclIsTypeOf446 ( HaxeConstructor ) ) . oclAsType ( HaxeConstructor ) ;447 }448 }449 c l a s s HaxeTypeParameter extends HaxeType450 {451 property bounds : HaxeTypeAccess [ ∗ ] { ordered452 composes } ;453 }454 abs t r a c t c l a s s HaxeTypeAccess extends HaxeExpression ;455 c l a s s HaxeFunctionTypeAccess extends HaxeTypeAccess456 {457 property returnType : HaxeTypeAccess ;458 property argumentTypes : HaxeTypeAccess [ ∗ ]459 { ordered } ;460 }461 c l a s s HaxeC la s s i f i e rAcc e s s extends462 HaxePathReference , HaxeTypeAccess463 {464 property parameterMapping : HaxeTypeAccess [ ∗ ]465 { ordered composes } ;466 }467 abs t r a c t c l a s s HaxeTypedElement extends468 HaxeModelElement469 {470 property type : HaxeTypeAccess [ ? ] { composes } ;471 }472 c l a s s HaxeClass extends HaxeC l a s s i f i e r473 {474 a t t r i b u t e i s I n t e r f a c e : Boolean475 {476 (477 body = 'HaxeTypedElement '478 ) ;479 (480 body = ' HaxeAbstract '481 ) ;482 }483 property g e n e r a l i z a t i o n : HaxeC la s s i f i e rAcc e s s [ ? ]484 { composes } ;485 property implementation : HaxeC la s s i f i e rAcc e s s [ ∗ ]


486 { composes } ;487 i nva r i an t classNameRegex : name . matches488 ( ' [A−Z ] [A−Za−z_− ]∗ ' ) ;489 i nva r i an t490 inter faceMethods : ( i s I n t e r f a c e ) imp l i e s491 ( HaxeConstructors492 −>isEmpty ( ) and HaxeOperations493 −>fo rA l l ( x : HaxeOperation | x . theBody .494 c l I sUnde f in ed ( ) ) ) ;495 i nva r i an t oneOrZeroConstructors : ( not extern )496 imp l i e s HaxeConstructors497 −>s i z e ( ) < 2 ;498 i nva r i an t499 ex te rnDec l a ra t i on : extern imp l i e s ( HaxeOperations500 −>fo rA l l ( x : HaxeOperation | not x . type501 −>oc l I sUnde f ined ( ) and x . theBody502 −>oc l I sUnde f ined ( ) ) ) ;503 }504 c l a s s HaxeAbstract extends HaxeC l a s s i f i e r505 {506 property underlyingType : HaxeTypeAccess [ ? ]507 { composes } ;508 property directCastingFromType : HaxeTypeAccess [ ? ]509 { composes } ;510 property directCastingToType : HaxeTypeAccess [ ? ]511 { composes } ;512 i nva r i an t abstractNameRegex : name . matches513 ( ' [A−Z ] [A−Za−z_− ]∗ ' ) ;514 }515 c l a s s HaxeEnum extends HaxeC l a s s i f i e r516 {517 property l i t e r a l s : HaxeEnumConstructor [ ∗ ]518 { ordered der ived readonly v o l a t i l e }519 {520 de r i v a t i on : s e l f . HaxeFields−>s e l e c t ( e :521 HaxeField | e . oc lIsTypeOf (HaxeEnumConstructor ) ) .522 oclAsType (HaxeEnumConstructor ) ;523 }524 i nva r i an t o n l yL i t e r a l s : s e l f . HaxeFields−>f o rA l l525 (x | x . ocl IsTypeOf (HaxeEnumConstructor ) ) ;526 }527 c l a s s HaxeTypedef extends HaxeType528 {529 property refType : HaxeTypeAccess { composes } ;530 }531 abs t r a c t c l a s s HaxeField extends HaxeNamedElement ,


532 HaxeMetadataContainer533 {534 property f i e l dCon t a i n e r#HaxeFields :535 HaxeFie ldContainer { t r an s i e n t v o l a t i l e ! r e s o l v e } ;536 a t t r i b u t e i s S t a t i c : Boolean537 {538 (539 body = ' HaxeAttribute ' ,540 unique = ' f a l s e ' ,541 upper = '∗ '542 ) ;543 }544 a t t r i b u t e i sP r i v a t e : Boolean ;545 }546 c l a s s HaxeAttribute extends HaxeField ,547 HaxeS ing l eVar iab l eDec la ra t ion548 {549 property g e t t e r : HaxeOperation [ ? ] ;550 property s e t t e r : HaxeOperation [ ? ] ;551 a t t r i b u t e ge t t e rProper ty : HaxeAttr ibuteProperty [ ? ] ;552 a t t r i b u t e s e t t e rPrope r ty : HaxeAttr ibuteProperty [ ? ] ;553 i nva r i an t554 coherentGetter : ( ge t t e rProper ty =555 HaxeAttr ibuteProperty : : method ) imp l i e s i f ( not556 s e l f . g e t t e r . o c l I sUnde f ined ( ) )557 then ( g e t t e r . name) . matches ( ' get_ ' . concat (name) )558 e l s e t rue559 end i f ;560 i nva r i an t561 cohe r en tSe t t e r : ( s e t t e rPrope r ty =562 HaxeAttr ibuteProperty : : method ) imp l i e s i f ( not563 s e l f . s e t t e r . o c l I sUnde f ined ( ) )564 then ( s e t t e r . name) . matches ( ' set_ ' . concat (name) )565 e l s e t rue566 end i f ;567 }568 enum HaxeAttr ibuteProperty { s e r i a l i z a b l e }569 {570 l i t e r a l d e f au l t ;571 l i t e r a l method ;572 l i t e r a l _' nu l l ' ;573 l i t e r a l dynamic ;574 }575 abs t r a c t c l a s s HaxeAbstractFunction extends HaxeASTNode576 {577 property formalParameters :


578 HaxeS ing l eVar iab l eDec la ra t ion [ ∗ ] { ordered579 composes } ;580 property typeParameters : HaxeTypeParameter [ ∗ ]581 { ordered composes } ;582 property theBody : HaxeExpression { composes } ;583 }584 abs t r a c t c l a s s HaxeAbstractOperation extends585 HaxeAbstractFunction586 {587 a t t r i b u t e i s I n l i n e : Boolean588 {589 (590 body = ' HaxeAbstractFunction '591 ) ;592 }593 a t t r i b u t e ov e r r i d e s : Boolean594 {595 (596 body = ' HaxeAbstractFunction '597 ) ;598 }599 }600 c l a s s HaxeOperation extends HaxeAbstractOperation ,601 HaxeField , HaxeTypedElement602 {603 a t t r i b u t e macro : Boolean604 {605 (606 body = ' HaxeConstructor ' ,607 unique = ' f a l s e ' ,608 upper = '∗ '609 ) ;610 }611 }612 c l a s s HaxeConstructor extends HaxeAbstractOperation ,613 HaxeField614 {615 property cons t ruc t edCla s s : HaxeClass { der ived }616 {617 de r i v a t i on : f i e l dCon t a i n e r . oclAsType618 ( HaxeClass ) ;619 }620 }621 c l a s s HaxeEnumConstructor extends622 HaxeVariableDeclarat ion , HaxeField623 {


624 annotat ion ;625 property parameters :626 HaxeS ing l eVar iab l eDec la ra t ion [ ∗ ] { ordered627 composes } ;628 i nva r i an t n o I n i t i a l i z e r : i n i t i a l i z e r −>isEmpty ( ) ;629 }630 abs t r a c t c l a s s HaxeDependencyDeclaration extends631 HaxePathReference , HaxeASTNode ;632 c l a s s HaxeImportDeclaration extends633 HaxeDependencyDeclaration634 {635 property s ta t i cE lement : HaxeField [ ? ] ;636 i nva r i an t637 i sAStat icElement : i f ( s e l f . s ta t i cE lement638 −>notEmpty ( ) )639 then s e l f . s ta t i cE lement . i s S t a t i c640 e l s e t rue641 end i f ;642 }643 c l a s s HaxeUsingDeclarat ion extends644 HaxeDependencyDeclaration645 {646 property s t a t i c F i e l d : HaxeField ;647 i nva r i an t i sAStat icElement : s e l f . s t a t i c F i e l d .648 i s S t a t i c ;649 }650 c l a s s HaxeMetadata extends HaxeNamedElement ,651 HaxeExpression652 {653 property usedIn#metadata : HaxeMetadataContainer654 { t r an s i e n t } ;655 a t t r i b u t e compilerMetadata : Boolean ;656 property parameters : HaxeExpression [ ∗ ] { ordered657 composes } ;658 }659 abs t r a c t c l a s s HaxeMetadataContainer extends660 HaxeModelElement661 {662 property metadata#usedIn : HaxeMetadata [ ∗ ]663 { composes } ;664 }665 enum HaxePref ixOperators { s e r i a l i z a b l e }666 {667 l i t e r a l NOT = 1 ;668 l i t e r a l MINUS = 2 ;669 l i t e r a l PLUS = 3 ;


670 l i t e r a l INCREMENT = 4 ;671 l i t e r a l DECREMENT = 5 ;672 l i t e r a l ONECOMPLEMENT = 6 ;673 }674 enum HaxeAssignmentOperator { s e r i a l i z a b l e }675 {676 l i t e r a l ASSIGN = 1 ;677 l i t e r a l PLUS_ASSIGN = 2 ;678 l i t e r a l MINUS_ASSIGN = 3 ;679 l i t e r a l DIVISION_ASSIGN = 4 ;680 l i t e r a l TIMES_ASSIGN = 5 ;681 l i t e r a l SHIFT_LEFT_ASSIGN = 6 ;682 l i t e r a l SHIFT_RIGTH_ASSIGN = 7 ;683 l i t e r a l SHIFT_ARITH_ASSIGN = 8 ;684 l i t e r a l BITWISE_OR_ASSIGN = 9 ;685 l i t e r a l BITWISE_AND_ASSIGN = 10 ;686 l i t e r a l XOR_ASSIGN = 11 ;687 l i t e r a l REMAINDER_ASSIGN = 12 ;688 }689 enum HaxeInf ixOperators { s e r i a l i z a b l e }690 {691 l i t e r a l PLUS = 1 ;692 l i t e r a l TIMES = 2 ;693 l i t e r a l MINUS = 3 ;694 l i t e r a l DIVISION = 4 ;695 l i t e r a l REMAINDER = 5 ;696 l i t e r a l SHIFT_RIGTH = 6 ;697 l i t e r a l SHIFT_LEFT = 7 ;698 l i t e r a l SHIFT_ARITH = 8 ;699 l i t e r a l LESS_THAN = 9 ;700 l i t e r a l GREATER_THAN = 10 ;701 l i t e r a l LESS_EQUALS = 11 ;702 l i t e r a l GREATER_EQUALS = 12 ;703 l i t e r a l BITWISE_OR = 13 ;704 l i t e r a l BITWISE_AND = 14 ;705 l i t e r a l XOR = 15 ;706 l i t e r a l EQ = 16 ;707 l i t e r a l NEQ = 17 ;708 l i t e r a l OR = 18 ;709 l i t e r a l AND = 19 ;710 l i t e r a l RANGE = 20 ;711 }

A.2. Metamodelo del lenguaje C/C++

1 import ecore : ' http ://www. e c l i p s e . org /emf/2002/Ecore ' ;


23 package Metamodelo_Cpp : _' org . e c l i p s e . emf . e co re .4 metamodelo_cpp ' = ' http ://metamodelo_cpp . unicen . edu . ar '5 {6 c l a s s CppModel7 {8 a t t r i b u t e name : S t r ing { id } ;9 a t t r i b u t e sourceFo lder : S t r ing = ' src ' ;10 a t t r i b u t e ta rge tFo lde r : S t r ing = ' bui ld ' ;11 property mainClass : CppClass ;12 property e lements : CppPathReferent iable [ ∗ ]13 { composes } ;14 property orphanTypes : CppType [ ∗ ] { composes } ;15 property modules : CppClassFi le [ ∗ ] { der ived16 readonly v o l a t i l e }17 {18 de r i v a t i on : e lements19 −>s e l e c t ( x | x . oc l I sKindOf (CppPackage ) )20 −>c o l l e c t ( x : CppPackage |21 x . ch i l d r enRe f e r en c e s )22 −>s e l e c t ( y | y . oc l I sKindOf ( CppClassFi le ) )23 −>c o l l e c t ( y | y . oclAsType ( CppClassFi le ) ) ;24 }25 i nva r i an t nameNotEmpty : name . s i z e ( ) > 0 ;26 i nva r i an t nameNotNull : name <> nu l l ;27 }28 abs t r a c t c l a s s CppPathReferent iable extends29 CppNamedElement30 {31 property parentReference#ch i l d r enRe f e r en c e s :32 CppPackage [ ? ] ;33 property r e f e r en c ed In#re fe rencedTermina l :34 CppPathReference [ ∗ ] { readonly v o l a t i l e } ;35 }36 abs t r a c t c l a s s CppPathReference extends37 CppModelElement38 {39 property re f e rencedTermina l#r e f e r en c ed In :40 CppPathReferent iable [ ? ] ;41 }42 c l a s s CppPackage extends CppPathReferent iable43 {44 property ch i l d r enRe f e r en c e s#parentReference :45 CppPathReferent iable [ ∗ ] { composes } ;46 property ch i ldrenPackages : CppPackage [ ∗ ] {47 der ived readonly v o l a t i l e }


48 {49 de r i v a t i on : ch i l d r enRe f e r en c e s50 −>s e l e c t ( x | x . oc l I sKindOf (CppPackage ) )51 −>c o l l e c t ( x | x . oclAsType (CppPackage ) ) ;52 }53 property containedTypes : CppType [ ∗ ] { der ived54 readonly v o l a t i l e }55 {56 de r i v a t i on : ch i l d r enRe f e r en c e s57 −>s e l e c t ( x | x . oc l I sKindOf ( CppClassFi le ) )58 −>c o l l e c t ( x : CppClassFi le | x . e lements ) ;59 }60 }61 abs t r a c t c l a s s CppModelElement ;62 ab s t r a c t c l a s s CppNamedElement extends CppModelElement63 {64 a t t r i b u t e name : S t r ing ;65 i nva r i an t nameNotEmpty : name . s i z e ( ) > 0 ;66 }67 c l a s s CppClassFi le extends CppPathReferent iable68 {69 property e lements : CppPathReferent iable [ ∗ ]70 { ordered composes } ;71 property imports : CppImportDeclaration [ ∗ ]72 { ordered composes } ;73 }74 abs t r a c t c l a s s CppType extends CppPathReferent iable75 {76 property usagesInTypeAccess#acc e s s :77 CppTypeAccess [ ∗ ] ;78 property typeParameters : CppTypeParameter [ ∗ ]79 { composes } ;80 }81 c l a s s CppTypeParameter extends CppType82 {83 annotat ion ;84 property bounds : CppTypeAccess [ ∗ ] { ordered85 composes } ;86 }87 abs t r a c t c l a s s CppC la s s i f i e r extends CppType ,88 CppFieldContainer89 {90 property cppOperations : CppMemberFunction [ ∗ ]91 { der ived readonly v o l a t i l e }92 {93 de r i v a t i on : s e l f . cppFie lds


94 −>s e l e c t ( x : CppField | x . oc lIsTypeOf (95 CppMethod) ) . oclAsType (CppMethod) ;96 }97 property cppDestructor : CppMemberFunction [ ∗ ]98 { der ived readonly v o l a t i l e }99 {100 de r i v a t i on : s e l f . cppFie lds101 −>s e l e c t ( x : CppField | x . oc lIsTypeOf (102 CppDestructor ) ) . oclAsType ( CppDestructor ) ;103 }104 property cppConstructor : CppMemberFunction [ ∗ ]105 { der ived readonly v o l a t i l e }106 {107 de r i v a t i on : s e l f . cppFie lds108 −>s e l e c t ( x : CppField | x . oc lIsTypeOf (109 CppConstructor ) ) . oclAsType ( CppConstructor ) ;110 }111 property cppAttr ibutes : CppVariable [ ∗ ] {112 der ived readonly v o l a t i l e }113 {114 de r i v a t i on : s e l f . cppFie lds115 −>s e l e c t ( x : CppField | x . oc lIsTypeOf (116 CppVariable ) ) . oclAsType ( CppVariable ) ;117 }118 }119 c l a s s CppEnum extends CppType120 {121 property l i t e r a l s : CppEnumConstructor [ ∗ ] {122 ordered composes } ;123 }124 c l a s s CppEnumConstructor extends CppNamedElement125 {126 property exp r e s s i on : CppExpression [ ? ]127 { composes } ;128 }129 c l a s s CppComment extends CppModelElement130 {131 a t t r i b u t e s i n g l eL i n e : Boolean ;132 a t t r i b u t e mult iL ine : Boolean ;133 a t t r i b u t e content : S t r ing ;134 }135 abs t r a c t c l a s s CppPrimitiveType extends CppType ;136 c l a s s CppBooleanType extends CppPrimitiveType ;137 c l a s s CppVoidType extends CppPrimitiveType ;138 c l a s s CppCharType extends CppPrimitiveType ;139 c l a s s CppShortType extends CppPrimitiveType ;


140 c l a s s CppIntType extends CppPrimitiveType ;141 c l a s s CppLongType extends CppPrimitiveType ;142 c l a s s CppFloatType extends CppPrimitiveType ;143 c l a s s CppDoubleType extends CppPrimitiveType ;144 c l a s s CppSignedType extends CppPrimitiveType ;145 c l a s s CppUnsignedType extends CppPrimitiveType ;146 c l a s s CppClass extends CppC la s s i f i e r147 {148 a t t r i b u t e i sAbs t r a c t : Boolean ;149 property superClas s : CppClass [ ∗ ] ;150 a t t r i b u t e c l a s s k ey : CppClassKey ;151 a t t r i b u t e i sGene r i c : Boolean [ ? ] { der ived } ;152 a t t r i b u t e i s F i n a l : Boolean [ ? ] ;153 }154 c l a s s CppImportDeclaration extends CppModelElement155 {156 property pathImport : CppClassFi le [ ? ] ;157 }158 abs t r a c t c l a s s CppTypedElement extends CppModelElement159 {160 property type : CppTypeAccess { composes } ;161 }162 abs t r a c t c l a s s CppExpression extends CppModelElement ;163 c l a s s CppVariable extends CppVariableDeclarat ion ,164 CppField , CppTypedElement , CppType165 {166 a t t r i b u t e i sConst : Boolean ;167 a t t r i b u t e s to rage : CppStorageType [ ? ] = 'AUTO' ;168 }169 c l a s s CppAr ray In i t i a l i z e r extends CppExpression170 {171 property exp r e s s i on s : CppExpression [+]172 { ordered composes } ;173 }174 abs t r a c t c l a s s CppFunction extends CppModelElement , CppType175 {176 property ownedParameters :177 CppSing l eVar iab leDec la rat ion [ ∗ ] { ordered178 composes } ;179 a t t r i b u t e isVarArg : Boolean ;180 a t t r i b u t e l i nkage : CppLinkageSpec i f i e r [ ? ] =181 'EXTERN' ;182 a t t r i b u t e i s I n l i n e : Boolean ;183 property functionBody : CppBlock [ ? ] { composes } ;184 }185 c l a s s CppBlock extends CppExpression


186 {187 property statements : CppExpression [ ∗ ]188 { ordered composes } ;189 }190 abs t r a c t c l a s s CppMemberFunction extends CppFunction ,191 CppField ;192 c l a s s CppConstructor extends CppMemberFunction ;193 c l a s s CppDestructor extends CppMemberFunction194 {195 a t t r i b u t e i sV i r t u a l : Boolean ;196 }197 c l a s s CppMethod extends CppMemberFunction ,198 CppTypedElement199 {200 a t t r i b u t e i s F i n a l : Boolean ;201 a t t r i b u t e i sConst : Boolean ;202 a t t r i b u t e i sV i r t u a l : Boolean ;203 a t t r i b u t e i sPureV i r tua l : Boolean ;204 }205 abs t r a c t c l a s s CppAbstractMethodInvocation extends206 CppExpression207 {208 property method : CppMemberFunction ;209 property arguments : CppExpression [ ∗ ] { ordered210 composes } ;211 }212 c l a s s CppMethodInvocation extends213 CppAbstractMethodInvocation214 {215 property exp r e s s i on : CppExpression [ ? ] { composes } ;216 }217 c l a s s CppSuperMethodInvocation extends218 CppAbstractMethodInvocation ;219 c l a s s CppSuperConstructorInvocation extends220 CppMethodInvocation ;221 c l a s s CppLabeledStatement extends CppExpression ,222 CppNamedElement ;223 ab s t r a c t c l a s s CppSelect ionStatement extends224 CppExpression225 {226 property cond i t i on : CppExpression { composes } ;227 property statement : CppExpression { composes } ;228 }229 abs t r a c t c l a s s CppIterat ionStatement extends230 CppExpression231 {


232 property theBody : CppExpression { composes } ;233 property cond i t i on : CppExpression { composes } ;234 }235 abs t r a c t c l a s s CppJumpStatement extends CppExpression ;236 c l a s s CppIfStatement extends CppSelect ionStatement ;237 c l a s s CppIfElseStatement extends CppSelect ionStatement238 {239 property e l s eStatement : CppExpression { composes } ;240 a t t r i b u t e inL ine : Boolean = ' f a l s e ' ;241 }242 c l a s s CppSwitchExpression extends CppExpression243 {244 property exp r e s s i on : CppExpression { composes } ;245 property ca s e s : CppCase [ ∗ ] { composes } ;246 property d e f au l t : CppExpression [ ∗ ] { composes } ;247 }248 c l a s s CppCase extends CppExpression249 {250 property value : CppExpression [+] { composes } ;251 property exp r e s s i on : CppExpression { composes } ;252 }253 c l a s s CppWhileStatement extends CppIterat ionStatement ;254 c l a s s CppDoWhileStatement extends CppIterat ionStatement ;255 c l a s s CppForStatement extends CppIterat ionStatement256 {257 property i n i t i a l i z e r : CppExpression { composes } ;258 property updater : CppExpression { composes } ;259 }260 c l a s s CppBreakStatement extends CppJumpStatement ;261 c l a s s CppReturnStatement extends CppJumpStatement262 {263 property re turnExpres s ion : CppExpression { composes } ;264 }265 c l a s s CppGotoStatement extends CppJumpStatement266 {267 property l a b e l : CppLabeledStatement { composes } ;268 }269 c l a s s CppContinueStatement extends CppJumpStatement ;270 c l a s s CppAssignamentStatement extends CppBinaryExpression271 {272 a t t r i b u t e operator : CppAssignmentOperator ;273 }274 c l a s s CppNul lL i tera l extends CppExpression ;275 c l a s s CppBooleanLitera l extends CppExpression276 {277 a t t r i b u t e booleanValue : Boolean ;


278 }279 c l a s s CppCharacterLitera l extends CppExpression280 {281 a t t r i b u t e charValue : S t r ing ;282 }283 c l a s s CppNumberLiteral extends CppExpression284 {285 a t t r i b u t e token : S t r ing ;286 }287 c l a s s CppStr ingL i t e ra l extends CppExpression288 {289 a t t r i b u t e l i t e r a lV a l u e : S t r ing ;290 }291 c l a s s CppRegexLiteral extends CppExpression292 {293 a t t r i b u t e pattern : S t r ing ;294 a t t r i b u t e opt ions : S t r ing ;295 }296 c l a s s CppDeclarat ionExpress ion extends CppExpression297 {298 property groups#conta ine r :299 CppVariableDeclarationGroup [+] { composes } ;300 }301 abs t r a c t c l a s s CppBinaryExpression extends CppExpression302 {303 property le f tOperand : CppExpression { composes } ;304 property rightOperand : CppExpression { composes } ;305 }306 c l a s s CppInf ixExpress ion extends CppBinaryExpression307 {308 a t t r i b u t e operator : CppOperator ;309 }310 abs t r a c t c l a s s CppUnaryExpression extends CppExpression311 {312 property exp r e s s i on : CppExpression { composes } ;313 }314 c l a s s CppPost f ixExpress ion extends CppUnaryExpression315 {316 a t t r i b u t e operator : CppPostf ixOperator ;317 }318 c l a s s CppPref ixExpress ion extends CppUnaryExpression319 {320 a t t r i b u t e operator : CppUnaryOperator ;321 }322 c l a s s CppParenthizedExpress ion extends CppExpression323 {


324 property exp r e s s i on : CppExpression { composes } ;325 }326 c l a s s CppCastExpression extends CppExpression327 {328 property type : CppTypeAccess { composes } ;329 property exp r e s s i on : CppExpression { composes } ;330 }331 c l a s s CppConstantExpression extends CppExpression ,332 CppNamedElement ;333 c l a s s CppArrayAccess extends CppExpression334 {335 property index : CppExpression { composes } ;336 property array : CppExpression { composes } ;337 }338 abs t r a c t c l a s s CppField extends CppNamedElement339 {340 property f i e l dCon t a i n e r#cppFie lds :341 CppFieldContainer { t r an s i e n t v o l a t i l e ! r e s o l v e } ;342 a t t r i b u t e a c c e s s S p e c i f i e r : CppAcces sSpec i f i e r ;343 }344 c l a s s CppFieldContainer extends CppModelElement345 {346 property cppFie lds#f i e l dCon t a i n e r : CppField [ ∗ ]347 { ordered composes ! r e s o l v e } ;348 }349 c l a s s CppTryExpression extends CppExpression350 {351 property theBody : CppExpression { composes } ;352 property catchClause : CppCatchClause [ ∗ ]353 { ordered composes } ;354 }355 c l a s s CppCatchClause extends CppExpression356 {357 property except ion#catchClause :358 CppSing l eVar iab leDec la rat ion { composes } ;359 property theBody : CppExpression { composes } ;360 }361 c l a s s CppThrowExpression extends CppExpression362 {363 property exp r e s s i on : CppExpression [ ? ] { composes } ;364 }365 c l a s s CppThisExpression extends CppExpression ;366 c l a s s CppFieldAccess extends CppExpression367 {368 property f i e l d : CppVariableAccess { composes } ;369 property exp r e s s i on : CppExpression { composes } ;


370 }371 c l a s s CppVariableAccess extends CppExpression372 {373 property va r i ab l e#usageInVar iab leAcces s :374 CppVariableDec larat ion { ! r e s o l v e } ;375 }376 c l a s s CppTypeAccess extends CppExpression377 {378 property a c c e s s#usagesInTypeAccess : CppType ;379 property parameterMapping : CppTypeAccess [ ∗ ]380 { ordered composes } ;381 }382 abs t r a c t c l a s s CppVariableDec larat ion extends383 CppNamedElement384 {385 property usageInVar iab leAccess#va r i ab l e :386 CppVariableAccess [ ∗ ] { readonly t r an s i e n t387 v o l a t i l e ! r e s o l v e } ;388 property i n i t i a l i z e r : CppExpression [ ? ]389 { composes } ;390 a t t r i b u t e vartype : CppVarType [ ? ] ;391 a t t r i b u t e i sArray : Boolean = ' f a l s e ' ;392 property dimensions : CppExpression [ ∗ ]393 { ordered composes } ;394 }395 c l a s s CppSing leVar iab l eDec larat ion extends396 CppVariableDeclarat ion , CppTypedElement397 {398 property catchClause#except ion : CppCatchClause [ ? ] ;399 }400 c l a s s CppVariableDeclarationGroup extends CppTypedElement401 {402 property conta ine r#groups :403 CppDeclarat ionExpress ion { t r an s i e n t v o l a t i l e } ;404 property fragments#var i ab l e sConta in e r :405 CppVariableDeclarationFragment [ ∗ ] { composes } ;406 }407 c l a s s CppVariableDeclarationFragment extends408 CppVariableDec larat ion409 {410 property va r i ab l e sConta ine r#fragments :411 CppVariableDeclarationGroup [ ? ] { t r an s i e n t v o l a t i l e } ;412 }413 enum CppVarType { s e r i a l i z a b l e }414 {415 l i t e r a l OBJECT = 1 ;


416 l i t e r a l REFERENCE = 2 ;417 l i t e r a l POINTER = 3 ;418 }419 enum CppAcces sSpec i f i e r { s e r i a l i z a b l e }420 {421 l i t e r a l PRIVATE = 1 ;422 l i t e r a l PROTECTED = 2 ;423 l i t e r a l PUBLIC = 3 ;424 }425 enum CppClassKey { s e r i a l i z a b l e }426 {427 l i t e r a l CLASS = 1 ;428 l i t e r a l STRUCT = 2 ;429 l i t e r a l UNION = 3 ;430 }431 enum CppLinkageSpec i f i e r { s e r i a l i z a b l e }432 {433 l i t e r a l STATIC = 1 ;434 l i t e r a l EXTERN = 2 ;435 }436 enum CppStorageType { s e r i a l i z a b l e }437 {438 l i t e r a l AUTO = 1 ;439 l i t e r a l REGISTER = 2 ;440 l i t e r a l STATIC = 3 ;441 l i t e r a l EXTERN = 4 ;442 l i t e r a l TYPEDEF = 5 ;443 l i t e r a l THREAD_LOCAL = 6 ;444 l i t e r a l MUTABLE = 7 ;445 }446 enum CppQuali f ierType { s e r i a l i z a b l e }447 {448 l i t e r a l CONST = 1 ;449 l i t e r a l VOLATILE = 2 ;450 l i t e r a l RESTRICT = 3 ;451 l i t e r a l ATOMIC = 4 ;452 }453 enum CppOperator { s e r i a l i z a b l e }454 {455 l i t e r a l GREATER_EQUALS = 1 ;456 l i t e r a l OR = 2 ;457 l i t e r a l MINUS = 3 ;458 l i t e r a l XOR_EQ = 4 ;459 l i t e r a l LESS_EQUALS = 5 ;460 l i t e r a l EQUALS = 6 ;461 l i t e r a l NOT_EQUALS = 7 ;


462 l i t e r a l AND = 8 ;463 l i t e r a l PLUS = 9 ;464 l i t e r a l GREATER_THAN = 10 ;465 l i t e r a l LESS_THAN = 11 ;466 l i t e r a l TIMES = 12 ;467 l i t e r a l DIVISION = 13 ;468 l i t e r a l SHIFT_LEFT = 14 ;469 l i t e r a l SHIFT_RIGHT = 15 ;470 l i t e r a l XOR = 16 ;471 l i t e r a l BIT_OR = 17 ;472 l i t e r a l REMAINDER = 18 ;473 l i t e r a l BIT_AND = 19 ;474 }475 enum CppUnaryOperator { s e r i a l i z a b l e }476 {477 l i t e r a l AMPERSAND = 1 ;478 l i t e r a l ASTERISK = 2 ;479 l i t e r a l PLUS = 3 ;480 l i t e r a l MINUS = 4 ;481 l i t e r a l BIT_NOT = 5 ;482 l i t e r a l NOT = 6 ;483 l i t e r a l INCREMENT = 7 ;484 l i t e r a l DECREMENT = 8 ;485 }486 enum CppAssignmentOperator { s e r i a l i z a b l e }487 {488 l i t e r a l ASSIGN = 1 ;489 l i t e r a l TIMES_ASSIGN = 2 ;490 l i t e r a l DIVISSION_ASSIGN = 3 ;491 l i t e r a l MODULO_ASSIGN = 4 ;492 l i t e r a l PLUS_ASSIGN = 5 ;493 l i t e r a l MINUS_ASSIGN = 6 ;494 l i t e r a l SHIFT_LEFT_ASSIGN = 7 ;495 l i t e r a l SHIFT_RIGHT_ASSIGN = 8 ;496 l i t e r a l AND_ASSIGN = 9 ;497 l i t e r a l XOR_ASSIGN = 10 ;498 l i t e r a l OR_ASSIGN = 11 ;499 }500 enum CppPostf ixOperator { s e r i a l i z a b l e }501 {502 l i t e r a l DECREMENT = 1 ;503 l i t e r a l INCREMENT = 2 ;504 }505 }

Apéndice B

Transformaciones ATL

1 −− @path cpp=/t h e s i s_ f i n a l /cpp . eco re2 −− @path Haxe=/t h e s i s_ f i n a l /Haxe . e co re34 module CPP2Haxe ;56 c r e a t e OUT: Haxe from IN : cpp ;78 he lpe r context cpp ! CppPackage9 de f : get_packages ( ) : Sequence ( cpp ! CppPackage ) =10 s e l f . ch i l d r enRe f e r ence s−>i t e r a t e ( elem ;11 acc : Sequence ( cpp ! CppPackage)=12 Sequence {} |13 i f ( elem . oclIsTypeOf ( cpp ! CppPackage ) )14 then acc−>append ( elem)−>15 union ( elem . get_packages ( ) )16 e l s e17 acc−>union ( Sequence {})18 end i f19 ) ;2021 he lpe r context cpp ! CppModel22 de f : ge t_al lpackages ( ) : Sequence ( cpp ! CppPackage ) =23 s e l f . e lements−>i t e r a t e ( elem ;24 acc : Sequence ( cpp ! CppPackage)=25 Sequence {} |26 i f ( elem . oclIsTypeOf ( cpp ! CppPackage ) )27 then acc−>append ( elem)−>28 union ( elem . get_packages ( ) )29 e l s e30 acc−>union ( Sequence {})

132

APÉNDICE B. TRANSFORMACIONES ATL 133

31 end i f32 ) ;3334 he lpe r context cpp ! CppPackage35 de f : g e t _ a l l c l a s s f i l e s ( ) : Sequence ( cpp ! CppClassFi le ) =36 s e l f . ch i l d r enRe f e r ence s−>i t e r a t e ( elem ;37 acc : Sequence ( cpp ! CppClassFi le ) =38 Sequence {} |39 i f ( elem . oclIsTypeOf ( cpp ! CppClassFi le ) )40 then acc−>append ( elem )41 e l s e42 acc−>union ( Sequence {})43 end i f44 ) ;4546 he lpe r context cpp ! CppModel47 de f : g e t_ c l a s s f i l e s ( ) : Sequence48 ( cpp ! CppCla s s f i l e ) =49 s e l f . ge t_al lpackages ( ) −> c o l l e c t ( package |50 package . g e t _ a l l c l a s s f i l e s ( ) ) ;5152 he lpe r context cpp ! CppPackage53 de f : g e t_ch i l d r en r e f e r en c e s ( ) : Sequence54 ( cpp ! CppPathReferent iable ) =55 s e l f . ch i l d r enRe f e r ence s−>i t e r a t e ( elem ;56 acc : Sequence ( cpp ! CppPathReferent iable ) =57 Sequence {} |58 i f ( elem . oclIsTypeOf ( cpp ! CppPackage ) )59 then acc−>append ( elem )60 e l s e61 i f ( elem . oclIsTypeOf ( cpp ! CppClassFi le ) )62 then acc−>union ( elem . e lements )63 e l s e64 acc−>append ( Sequence {})65 end i f66 end i f67 ) ;6869 he lpe r context cpp ! CppClass70 de f : ge t_superc la s s ( ) : Haxe ! HaxeC la s s i f i e rAcc e s s =71 i f s e l f . superClas s . isEmpty ( ) then72 OclUndefined73 e l s e74 thisModule . g e t_gene ra l i z a t i on ( s e l f . superClass−>75 f i r s t ( ) )76 end i f ;


7778 he lpe r context cpp ! CppClassFi le79 de f : get_imports ( ) : Sequence (Haxe ! HaxeImportDeclaration)=80 i f s e l f . imports . isEmpty ( ) then81 Sequence {}82 e l s e83 s e l f . imports−>i t e r a t e ( elem ;84 acc : Sequence (Haxe ! HaxeImportDeclaration ) =85 Sequence {} |86 i f elem . pathImport . o c l I sUnde f ined ( ) then87 acc−>append ( Sequence {})88 e l s e89 elem . pathImport . elements−>i t e r a t e ( elem2 ;90 acc2 : Sequence91 (Haxe ! HaxeImportDeclaration ) =92 Sequence {} |93 i f elem2 . oclIsTypeOf ( cpp ! CppClass )94 then95 acc2−>append ( thisModule .96 get_c lass import ( elem2 ) )97 e l s e98 acc2−>append ( Sequence {})99 end i f100 )101 end i f102 )103 end i f ;104105106 he lpe r context cpp ! CppForStatement107 de f : get_blockStatements ( ) : Sequence ( cpp ! CppExpression ) =108 i f s e l f . theBody = OclUndefined then109 Sequence {}110 e l s e111 i f s e l f . theBody . oclIsTypeOf ( cpp ! CppBlock ) then112 s e l f . theBody . get_statements ( )113 e l s e114 i f ( s e l f . theBody . oclIsTypeOf115 ( cpp ! CppAssignamentStatement )116 or s e l f . theBody . oclIsTypeOf117 ( cpp ! CppMethodInvocation )118 or s e l f . theBody . oclIsTypeOf119 ( cpp ! CppPost f ixExpress ion ) ) then120 Sequence{ thisModule . s ta t ement i z e121 ( s e l f . theBody )}122 e l s e


123 Sequence{ s e l f . theBody}124 end i f125 end i f126 end i f ;127128 he lpe r context cpp ! CppBlock129 de f : get_statements ( ) : Sequence ( cpp ! CppExpression ) =130 s e l f . statements−>i t e r a t e ( elem ;131 acc : Sequence ( cpp ! CppExpression ) = Sequence {} |132 i f ( elem . oclIsTypeOf (133 cpp ! CppAssignamentStatement )134 or elem . oclIsTypeOf135 ( cpp ! CppMethodInvocation )136 or elem . oclIsTypeOf137 ( cpp ! CppPost f ixExpress ion ) ) then138 acc−>append ( thisModule . s ta t ement i z e ( elem ) )139 e l s e140 acc−>append ( elem )141 end i f142 ) ;143144 he lpe r context cpp ! CppVariableDeclarationGroup145 de f : g e t I n i t i a l i z e r ( ) : Haxe ! HaxeExpression =146 i f ( s e l f . fragments−>notEmpty ( ) ) then147 i f ( s e l f . fragments−>asSequence()−> f i r s t ( ) =148 OclUndefined ) then149 OclUndefined150 e l s e151 s e l f . fragments−>asSequence()−> f i r s t ( ) .152 i n i t i a l i z e r153 end i f154 e l s e155 OclUndefined156 end i f ;157158 he lpe r context cpp ! CppVariableDeclarationGroup159 de f : i sPo i n t e r ( ) : Boolean =160 i f ( s e l f . fragments−>notEmpty ( ) ) then161 i f ( s e l f . fragments−>asSequence()−> f i r s t ( ) =162 OclUndefined ) then163 f a l s e164 e l s e165 ( s e l f . fragments−>asSequence()−> f i r s t ( ) .166 vartype = #POINTER)167 end i f168 e l s e


169 f a l s e170 end i f ;171172 he lpe r context cpp ! CppTypeAccess173 de f : isCharType ( ) : Boolean =174 i f ( s e l f . a c c e s s = OclUndefined ) then175 f a l s e176 e l s e177 i f ( s e l f . acces s−>oclIsTypeOf ( cpp ! CppCharType ) )178 then179 true180 e l s e181 f a l s e182 end i f183 end i f ;184185 he lpe r context cpp ! CppTypedElement186 de f : isCharType ( ) : Boolean =187 i f ( s e l f . type = OclUndefined ) then188 f a l s e189 e l s e190 s e l f . type . isCharType ( )191 end i f ;192193 he lpe r context cpp ! CppVariableDeclarationFragment194 de f : isCharType ( ) : Boolean =195 i f ( s e l f . va r i ab l e sConta in e r = OclUndefined ) then196 f a l s e197 e l s e198 s e l f . va r i ab l e sConta in e r . isCharType ( )199 end i f ;200201 he lpe r context cpp ! CppTypeAccess202 de f : i sP r im i t i v e ( ) : Boolean =203 i f ( s e l f . a c c e s s = OclUndefined ) then204 f a l s e205 e l s e206 i f ( s e l f . acces s−>oclIsKindOf ( cpp ! CppPrimitiveType ) )207 then208 true209 e l s e210 f a l s e211 end i f212 end i f ;213214 he lpe r context cpp ! CppTypedElement


215 de f : i sP r im i t i v e ( ) : Boolean =216 i f ( s e l f . type = OclUndefined ) then217 f a l s e218 e l s e219 s e l f . type . i sP r im i t i v e ( )220 end i f ;221222 he lpe r context cpp ! CppC la s s i f i e r223 de f : getTypeConstructor ( ) : cpp ! CppMemberFunction =224 s e l f . cppFie lds−>s e l e c t ( x | x . oclIsTypeOf225 ( cpp ! CppConstructor))−> f i r s t ( )226 ;227228 he lpe r context cpp ! CppTypeAccess229 de f : typeHasConstructor ( ) : Boolean =230 i f ( not s e l f . acces s−>oclIsKindOf ( cpp ! CppC la s s i f i e r ) )231 then232 f a l s e233 e l s e234 i f ( s e l f . a c c e s s . getTypeConstructor ( ) =235 OclUndefined ) then236 f a l s e237 e l s e238 true239 end i f240 end i f ;241242 he lpe r de f : assignMap : Map( cpp ! CppAssignmentOperator ,243 Haxe ! HaxeAssignmentOperator ) =244 Map{(#ASSIGN,#ASSIGN) ,245 (#PLUS_ASSIGN,#PLUS_ASSIGN) ,246 (#MINUS_ASSIGN,#MINUS_ASSIGN) ,247 (#TIMES_ASSIGN,#TIMES_ASSIGN) ,248 (#DIVISSION_ASSIGN,249 #DIVISION_ASSIGN) ,250 (#AND_ASSIGN,251 #BITWISE_AND_ASSIGN) ,252 (#OR_ASSIGN,253 #BITWISE_OR_ASSIGN) ,254 (#XOR_ASSIGN,255 #XOR_ASSIGN) ,256 (#SHIFT_LEFT_ASSIGN,257 #SHIFT_LEFT_ASSIGN) ,258 (#SHIFT_RIGHT_ASSIGN,259 #SHIFT_RIGTH_ASSIGN) } ;260


261 he lpe r de f : operatorMap : Map( cpp ! CppOperator ,262 Haxe ! HaxeInf ixOperators ) =263 Map264 {(#PLUS,#PLUS) ,265 (#MINUS,#MINUS) ,266 (#TIMES,#TIMES) ,267 (#DIVISION,#DIVISION) ,268 (#REMAINDER,#REMAINDER) ,269 (#SHIFT_RIGHT,#SHIFT_ARITH) ,270 (#SHIFT_LEFT,#SHIFT_LEFT) ,271 (#LESS_THAN,#LESS_THAN) ,272 (#GREATER_THAN,#GREATER_THAN) ,273 (#LESS_EQUALS,#LESS_EQUALS) ,274 (#GREATER_EQUALS,#GREATER_EQUALS) ,275 (#BIT_OR,#BITWISE_OR) ,276 (#BIT_AND,#BITWISE_AND) ,277 (#AND,#AND) ,278 (#OR,#OR) ,279 (#XOR,#XOR) ,280 (#EQUALS,#EQ) ,281 (#NOT_EQUALS,#NEQ)} ;282283 he lpe r de f : unaryoperatorMap : Map( cpp ! CppUnaryOperator ,284 Haxe ! HaxePref ixOperators ) = Map285 {(#NOT, #NOT) ,286 (#PLUS, #PLUS) ,287 (#MINUS, #MINUS) ,288 (#INCREMENT, #INCREMENT) ,289 (#DECREMENT, #DECREMENT) ,290 (#BIT_NOT, #ONECOMPLEMENT)} ;291292 ru l e model {293 from294 s : cpp ! CppModel295 to296 t : Haxe ! HaxeModel (297 name <− s . name ,298 sourceFo lder <− s . sourceFolder ,299 ta rge tFo lde r <− s . ta rge tFo lder ,300 r e f e r en c ed <− s . orphanTypes −> s e l e c t301 (x | x . usagesInTypeAccess −>302 notEmpty ( ) and x . oc l I sKindOf303 ( cpp ! CppType) and ( not x .304 oclIsTypeOf ( cpp ! CppClass ) ) ) −>305 c o l l e c t ( x | thisModule . Type (x ) ) −>306 asSet ( ) ,


307 e lements <− s . get_al lpackages ( ) ,308 HaxeModules <− s . g e t_ c l a s s f i l e s ( ) ,309 mainClass <− s . mainClass310 )311 }312313 abs t r a c t r u l e namedElement314 {315 from316 s : cpp ! CppNamedElement317 to318 t : Haxe ! HaxeNamedElement (319 name <− s . name320 )321 }322323 ru l e packages extends namedElement {324 from325 s : cpp ! CppPackage326 to327 t : Haxe ! HaxePackage (328 parentReference <− s . parentReference ,329 ch i l d r enRe f e r en c e s <− s . g e t_ch i l d r en r e f e r en c e s ( )330 )331 }332333 ru l e modules {334 from335 s : cpp ! CppClassFi le336 to337 t : Haxe ! HaxeModule (338 name <− s . name ,339 thePackage <− s . parentReference ,340 theElements <− s . e lements ,341 dependenc ies <− s . get_imports ( )342 )343 }344345 ru l e c l a s s e s extends namedElement {346 from347 s : cpp ! CppClass348 to349 t : Haxe ! HaxeClass (350 HaxeFields <− s . cppFie lds−>r e j e c t ( c l a s s e s |351 c l a s s e s . oc l I sKindOf ( cpp ! CppDestructor ) ) ,352 g e n e r a l i z a t i o n <− s . ge t_superc la s s ( ) ,


353 typeParameters <− s . typeParameters354 )355 }356357 ru l e typeParameter extends namedElement{358 from359 s : cpp ! CppTypeParameter360 to361 t : Haxe ! HaxeTypeParameter (362 bounds <− s . bounds363 )364 }365366 lazy ru l e g e t_gene ra l i z a t i on {367 from368 s : cpp ! CppClass369 to370 t : Haxe ! HaxeC la s s i f i e rAcc e s s (371 re f e rencedTermina l <− s372 )373 }374375 lazy ru l e get_c lass import {376 from377 s : cpp ! CppClass378 to379 t : Haxe ! HaxeImportDeclaration (380 re f e rencedTermina l <− s381 )382 }383384 ru l e enumTransformation extends namedElement{385 from386 s : cpp !CppEnum387 to388 t : Haxe !HaxeEnum (389 HaxeFields <− s . l i t e r a l s390 )391 }392393 ru l e enumConstructor extends namedElement{394 from395 s : cpp ! CppEnumConstructor396 to397 t : Haxe ! HaxeEnumConstructor (398 i n i t i a l i z e r <− s . e xp r e s s i on


399 )400 }401402 abs t r a c t r u l e abst ractFunct ion {403 from404 s : cpp ! CppFunction405 to406 t : Haxe ! HaxeAbstractFunction (407 formalParameters <− s . ownedParameters ,408 theBody <− i f not ( s . functionBody =409 OclUndefined ) then410 thisModule . generateBlock411 ( s . functionBody )412 e l s e413 OclUndefined414 end i f415 )416 }417418 abs t r a c t r u l e abst ractOperat ion extends abst ractFunct ion {419 from420 s : cpp ! CppFunction421 to422 t : Haxe ! HaxeAbstractOperation (423 i s I n l i n e <− s . i s I n l i n e424425 )426 }427428 ru l e methods extends abst ractOperat ion {429 from430 s : cpp ! CppMethod431 to432 t : Haxe ! HaxeOperation (433 i sP r i v a t e <− ( s . a c c e s s S p e c i f i e r = #PRIVATE) ,434 i s S t a t i c <− ( s . l i nkage = #STATIC) ,435 name <− s . name ,436 type <− s . type437 )438 }439440 ru l e c on s t ru c t o r s extends namedElement {441 from442 s : cpp ! CppConstructor443 to444 t : Haxe ! HaxeConstructor (


445 i sP r i v a t e <− ( s . a c c e s s S p e c i f i e r = #PRIVATE or446 ( s . f i e l dCon t a i n e r . oc l IsTypeOf447 ( cpp ! CppClass ) and s . f i e l dCon t a i n e r .448 i sAbs t r a c t ) ) ,449 name <− s . name ,450 formalParameters <− s . ownedParameters ,451 theBody <− i f not ( s . functionBody =452 OclUndefined ) then453 thisModule . generateBlock454 ( s . functionBody )455 e l s e456 OclUndefined457 end i f458 )459 }460461 ru l e methodInvocation {462 from463 s : cpp ! CppMethodInvocation464 to465 t : Haxe ! HaxeMethodInvocation (466 method <− s . method ,467 arguments <− s . arguments ,468 exp r e s s i on <− s . exp r e s s i on469 )470 }471472 ru l e superMethodInvocation {473 from474 s : cpp ! CppSuperMethodInvocation475 to476 t : Haxe ! HaxeSuperMethodInvocation477 }478479 ru l e superConst ructor Invocat ion {480 from481 s : cpp ! CppSuperConstructorInvocation482 to483 t : Haxe ! HaxeSuperConstructorInvocat ion484 }485486 ru l e c l a s sVa r i a b l e s extends namedElement {487 from488 s : cpp ! CppVariable (489 ( s . i sArray = f a l s e or ( s . isCharType ( ) ) )490 and not ( s . s t o rage = #TYPEDEF )


491 )492 to493 t : Haxe ! HaxeAttribute (494 i sP r i v a t e <− ( s . a c c e s s S p e c i f i e r = #PRIVATE) ,495 i s S t a t i c <− s . i sConst ,496 type <− s . type ,497 i n i t i a l i z e r <− i f ( not ( s . i sP r im i t i v e ( ) ) and498 ( s . i n i t i a l i z e r = OclUndefined ) and not499 ( s . vartype = #POINTER) ) then500 i f ( s . type . typeHasConstructor ( ) = true )501 then502 thisModule . generateTypeConstructor503 ( s . type )504 e l s e505 OclUndefined506 end i f507 e l s e508 s . i n i t i a l i z e r509 end i f510 )511 }512513 ru l e c l a s sVar i ab l e sAr ray extends namedElement {514 from515 s : cpp ! CppVariable (516 s . i sArray = true and not s . isCharType ( )517 and not ( s . s t o rage = #TYPEDEF )518 )519 to520 t : Haxe ! HaxeAttribute (521 i sP r i v a t e <− ( s . a c c e s s S p e c i f i e r = #PRIVATE) ,522 i s S t a t i c <− s . i sConst ,523 type <− s . type ,524 i n i t i a l i z e r <− ar r525 ) ,526 ar r : Haxe ! HaxeArrayCreation (527 dimensions <− s . dimensions ,528 i n i t i a l i z e r <− s . i n i t i a l i z e r529 )530 }531532 ru l e var iableTypeDef extends namedElement {533 from534 s : cpp ! CppVariable (535 s . s t o rage = #TYPEDEF536 )


537 to538 t : Haxe ! HaxeTypedef (539 refType <− s . type540 )541 }542543 ru l e comments {544 from545 s : cpp !CppComment546 to547 t : Haxe !HaxeComment (548 content <− s . content ,549 lineComment <− t . s i n g l e l i n e550 )551 }552553 ru l e p r e f i xExpr e s s i on {554 from555 s : cpp ! CppPref ixExpress ion556 to557 t : Haxe ! HaxePref ixExpress ion (558 operand <− s . expres s ion ,559 operator <− thisModule . unaryoperatorMap .560 get ( s . operator )561 )562 }563564 ru l e po s t f i xExp r e s s i on {565 from566 s : cpp ! CppPost f ixExpress ion567 to568 t : Haxe ! HaxePost f ixExpress ion (569 operand <− s . expres s ion ,570 i s Increment <− ( s . operator = #INCREMENT)571 )572 }573574 ru l e i n f i xExp r e s s i on {575 from576 s : cpp ! CppInf ixExpress ion577 to578 t : Haxe ! HaxeIn f ixExpress ion (579 l e f t S i d e <− s . le ftOperand ,580 r i gh tS i d e <− s . rightOperand ,581 operator <− thisModule . operatorMap .582 get ( s . operator )


583 )584 }585586 ru l e ass ignmentExpress ion {587 from588 s : cpp ! CppAssignamentStatement589 to590 t : Haxe ! HaxeAssignment (591 l e f t S i d e <− s . le ftOperand ,592 r i gh tS i d e <− s . rightOperand ,593 operator <− thisModule . assignMap .594 get ( s . operator )595 )596 }597598 lazy ru l e generateBlock {599 from600 s : cpp ! CppBlock ( not s = OclUndefined )601 to602 t : Haxe ! HaxeBlock (603 statements <− s . get_statements ( )604 )605 }606607 ru l e i fS tatement {608 from609 s : cpp ! CppIfStatement610 to611 t : Haxe ! HaxeExpressionStatement (612 exp r e s s i on <− u613 ) ,614 u : Haxe ! HaxeIfStatement (615 exp r e s s i on <− s . cond i t ion ,616 thenStatement <−617 i f ( s . statement . oclIsTypeOf ( cpp ! CppBlock ) )618 then619 thisModule . generateBlock ( s . statement )620 e l s e621 i f ( not s . statement . oc l I sKindOf (622 cpp ! CppSelect ionStatement ) ) then623 thisModule . s ta t ement i z e624 ( s . statement )625 e l s e626 s . statement627 end i f628 end i f


629 )630 }631632 ru l e i fE l s eS ta t ement {633 from634 s : cpp ! CppIfElseStatement ( not s . inL ine )635 to636 t : Haxe ! HaxeExpressionStatement (637 exp r e s s i on <− u638 ) ,639 u : Haxe ! HaxeIfStatement (640 exp r e s s i on <− s . cond i t ion ,641 thenStatement <−642 i f ( s . statement . oclIsTypeOf ( cpp ! CppBlock ) )643 then644 thisModule . generateBlock ( s . statement )645 e l s e646 i f ( not s . statement . oc l I sKindOf647 ( cpp ! CppSelect ionStatement ) ) then648 thisModule . s ta t ement i z e649 ( s . statement )650 e l s e651 s . statement652 end i f653 end i f ,654 e l s eStatement <−655 i f ( s . e l s eStatement . oclIsTypeOf656 ( cpp ! CppBlock ) ) then657 thisModule . generateBlock658 ( s . e l s eStatement )659 e l s e660 i f ( not s . e l s eStatement . oc l I sKindOf661 ( cpp ! CppSelect ionStatement ) ) then662 thisModule . s ta t ement i z e663 ( s . e l s eStatement )664 e l s e665 s . e l s eStatement666 end i f667 end i f668 )669 }670671 ru l e i fE l s e S t a t emen t I n l i n e {672 from673 s : cpp ! CppIfElseStatement ( s . inL ine )674 to


675 t : Haxe ! HaxeExpressionStatement (676 exp r e s s i on <− u677 ) ,678 u : Haxe ! HaxeTernaryExpression (679 exp r e s s i on <− s . cond i t ion ,680 thenStatement <−681 i f ( s . statement . oclIsTypeOf ( cpp ! CppBlock ) )682 then683 thisModule . generateBlock ( s . statement )684 e l s e685 s . statement686 end i f ,687 e l s eExp r e s s i on <−688 i f ( s . e l s eStatement . oclIsTypeOf689 ( cpp ! CppBlock ) ) then690 thisModule . generateBlock691 ( s . e l s eStatement )692 e l s e693 s . e l s eStatement694 end i f695 )696 }697698 abs t r a c t r u l e loopStatement {699 from700 s : cpp ! CppIterat ionStatement701 to702 t : Haxe ! HaxeLoopStatement (703 theBody <−704 i f not ( s . theBody = OclUndefined ) then705 thisModule . generateBlock ( s . theBody )706 e l s e707 OclUndefined708 end i f ,709 exp r e s s i on <− s . c ond i t i on710 )711 }712713 ru l e doWhileStatement extends loopStatement {714 from715 s : cpp ! CppDoWhileStatement716 to717 t : Haxe ! HaxeDoWhileStatement718 }719720 ru l e whi leStatement extends loopStatement {


721 from722 s : cpp ! CppWhileStatement723 to724 t : Haxe ! HaxeWhileStatement725 }726727 lazy ru l e s ta t ement i z e {728 from729 s : cpp ! CppExpression730 to731 t : Haxe ! HaxeExpressionStatement (732 exp r e s s i on <− s733 )734 }735736 ru l e forStatement {737 from738 s : cpp ! CppForStatement739 to740 t : Haxe ! HaxeExpressionStatement (741 exp r e s s i on <− u742 ) ,743 u : Haxe ! HaxeBlock (744 statements <− Sequence{ s . i n i t i a l i z e r , whi l e }745 ) ,746 whi l e : Haxe ! HaxeWhileStatement (747 exp r e s s i on <− s . cond i t ion ,748 theBody <− theBigBody749 ) ,750 theBigBody : Haxe ! HaxeBlock (751 statements <− s . get_blockStatements ( ) ,752 statements <− thisModule . s ta t ement i z e753 ( s . updater )754 )755 }756757 ru l e re turn {758 from759 s : cpp ! CppReturnStatement760 to761 t : Haxe ! HaxeExpressionStatement (762 exp r e s s i on <− u763 ) ,764 u : Haxe ! HaxeReturn (765 exp r e s s i on <− s . r e turnExpres s i on766 )


767 }768769 ru l e breakStatement {770 from771 s : cpp ! CppBreakStatement772 to773 t : Haxe ! HaxeExpressionStatement (774 exp r e s s i on <− u775 ) ,776 u : Haxe ! HaxeBreak777 }778779 ru l e continueStatement {780 from781 s : cpp ! CppContinueStatement782 to783 t : Haxe ! HaxeExpressionStatement (784 exp r e s s i on <− u785 ) ,786 u : Haxe ! HaxeContinue787 }788789 ru l e s t r i n g L i t e r a l {790 from791 s : cpp ! CppStr ingL i t e ra l792 to793 t : Haxe ! HaxeSt r ingL i t e ra l (794 escapedValue <− s . l i t e r a lV a l u e795 )796 }797798 ru l e n u l l L i t e r a l {799 from800 s : cpp ! CppNul lL i tera l801 to802 t : Haxe ! HaxeNul lL i t e ra l803 }804805 ru l e boo l e anL i t e r a l {806 from807 s : cpp ! CppBooleanLitera l808 to809 t : Haxe ! HaxeBooleanLitera l (810 value <− s . booleanValue811 )812 }


813814 ru l e numberLitera l {815 from816 s : cpp ! CppNumberLiteral817 to818 t : Haxe ! HaxeNumberLiteral (819 value <− s . token820 )821 }822823 ru l e c h a rL i t e r a l {824 from825 s : cpp ! CppCharacterLitera l826 to827 t : Haxe ! HaxeSt r ingL i t e ra l (828 escapedValue <− s . charValue829 )830 }831832833 ru l e switch {834 from835 s : cpp ! CppSwitchExpression836 to837 t : Haxe ! HaxeExpressionStatement (838 exp r e s s i on <− u839 ) ,840 u : Haxe ! HaxeSwitch (841 exp r e s s i on <− s . expres s ion ,842 ca s e s <− s . cases ,843 d e f au l t <− s . d e f au l t844 )845 }846847 ru l e case {848 from849 s : cpp ! CppCase850 to851 t : Haxe ! HaxeCase (852 va lue s <− s . value ,853 exp r e s s i on <−854 i f ( s . expres s ion−>oclIsKindOf855 ( cpp ! CppBlock ) ) then856 thisModule . generateBlock ( s . exp r e s s i on )857 e l s e858 s . exp r e s s i on


859 end i f860 )861 }862863 ru l e t ry {864 from865 s : cpp ! CppTryExpression866 to867 t : Haxe ! HaxeExpressionStatement (868 exp r e s s i on <− u869 ) ,870 u : Haxe ! HaxeTryExpression (871 theBody <− thisModule . generateBlock ( s . theBody ) ,872 catchClause <− s . catchClause873 )874 }875876 ru l e catch {877 from878 s : cpp ! CppCatchClause879 to880 t : Haxe ! HaxeCatchClause (881 theBody <− thisModule . generateBlock ( s . theBody )882 )883 }884885 ru l e throw {886 from887 s : cpp ! CppThrowExpression888 to889 t : Haxe ! HaxeExpressionStatement (890 exp r e s s i on <− u891 ) ,892 u : Haxe ! HaxeThrowExpression (893 exp r e s s i on <− s . exp r e s s i on894 )895 }896897 ru l e th i sExpr e s s i on {898 from899 s : cpp ! CppThisExpression900 to901 t : Haxe ! HaxeThisExpression902 }903904 ru l e Parenth izedExpress ion {


905 from906 s : cpp ! CppParenthizedExpress ion907 to908 t : Haxe ! HaxeParenthizedExpress ion (909 exp r e s s i on <− s . exp r e s s i on910 )911 }912913 ru l e r e g e xL i t e r a l {914 from915 s : cpp ! CppRegexLiteral916 to917 t : Haxe ! HaxeRegexLiteral (918 pat t e r <− s . pattern ,919 opt ions <− s . opt ions920 )921 }922923924 ru l e var iab leDec larat ionGroup {925 from926 s : cpp ! CppVariableDeclarationGroup927 to928 t : Haxe ! HaxeVariableDeclarationGroup (929 i n i t i a l i z e r <−930 i f ( not ( s . i sP r im i t i v e ( ) ) and931 ( s . g e t I n i t i a l i z e r ( ) = OclUndefined )932 and not ( s . i sPo i n t e r ( ) ) ) then933 i f ( s . type . typeHasConstructor ( ) =934 true ) then935 thisModule . generateTypeConstructor936 ( s . type )937 e l s e938 OclUndefined939 end i f940 e l s e941 s . g e t I n i t i a l i z e r ( )942 end i f ,943 fragments <− s . fragments ,944 type <− s . type945 )946 }947948 lazy ru l e generateTypeConstructor {949 from950 s : cpp ! CppTypeAccess


951 to952 t : Haxe ! HaxeMethodInvocation (953 method <− s . a c c e s s . getTypeConstructor ( )954 )955 }956957 abs t r a c t r u l e va r i ab l eDec l a r a t i on extends namedElement {958 from959 s : cpp ! CppVariableDec larat ion960 to961 t : Haxe ! HaxeVar iab leDec larat ion (962 i n i t i a l i z e r <− s . i n i t i a l i z e r963 )964 }965966 ru l e var iab leDec larat ionFragment extends namedElement {967 from968 s : cpp ! CppVariableDeclarationFragment (969 s . i sArray = f a l s e or s . isCharType ( )970 )971 to972 t : Haxe ! HaxeVariableDeclarat ionFragment973 }974975 ru l e var iab leDec larat ionFragmentArray extends976 namedElement {977 from978 s : cpp ! CppVariableDeclarationFragment (979 s . i sArray = true and not ( s . isCharType ( ) )980 )981 to982 t : Haxe ! HaxeVariableDeclarat ionFragment (983 i n i t i a l i z e r <− ar r984 ) ,985 ar r : Haxe ! HaxeArrayCreation (986 dimensions <− s . dimensions ,987 i n i t i a l i z e r <− s . i n i t i a l i z e r988 )989 }990991 ru l e s i n g l eVa r i ab l eDe c l a r a t i on extends va r i ab l eDec l a r a t i on {992 from993 s : cpp ! CppSing l eVar iab leDec larat ion994 to995 t : Haxe ! HaxeS ing l eVar iab l eDec la ra t i on (996 catchClause <− s . catchClause ,


997 type <− s . type998 )999 }10001001 ru l e de c l a r a t i onExpr e s s i on {1002 from1003 s : cpp ! CppDeclarat ionExpress ion1004 to1005 t : Haxe ! HaxeExpressionStatement (1006 exp r e s s i on <− u1007 ) ,1008 u : Haxe ! HaxeVar iab leDec larat ionExpress ion (1009 groups <− s . groups1010 )1011 }10121013 ru l e arrayAccess {1014 from1015 s : cpp ! CppArrayAccess1016 to1017 t : Haxe ! HaxeArrayAccess (1018 array <− s . array ,1019 index <− s . index1020 )1021 }10221023 ru l e a r r a y I n i t i a l i z e r {1024 from1025 s : cpp ! CppAr ray In i t i a l i z e r1026 to1027 t : Haxe ! HaxeAr r ay In i t i a l i z e r (1028 exp r e s s i on s <− s . e xp r e s s i on s1029 )1030 }10311032 ru l e f i e l dAc c e s s {1033 from1034 s : cpp ! CppFieldAccess1035 to1036 t : Haxe ! HaxeFieldAccess (1037 f i e l d <− s . f i e l d ,1038 exp r e s s i on <− s . exp r e s s i on1039 )1040 }10411042 ru l e va r i ab l eAcce s s {


1043 from1044 s : cpp ! CppVariableAccess1045 to1046 t : Haxe ! HaxeS ing leVar iab leAccess (1047 va r i ab l e <− s . v a r i ab l e1048 )1049 }10501051 ru l e typeAccessClass {1052 from1053 s : cpp ! CppTypeAccess (1054 not ( s . a c c e s s = OclUndefined ) and ( s . acces s−>1055 oc l I sKindOf ( cpp ! CppC la s s i f i e r ) or s . acces s−>1056 oc l I sKindOf ( cpp ! CppVariable ) )1057 )1058 to1059 t : Haxe ! HaxeC la s s i f i e rAcc e s s (1060 re f e rencedTermina l <− s . acces s ,1061 parameterMapping <− s . parameterMapping1062 )1063 }10641065 ru l e castRule {1066 from1067 s : cpp ! CppCastExpression1068 to1069 t : Haxe ! HaxeCastingExpress ion (1070 type <− s . type ,1071 exp r e s s i on <− s . exp r e s s i on1072 )1073 }10741075 ru l e typeAcces sPr imi t ive {1076 from1077 s : cpp ! CppTypeAccess (1078 not ( s . a c c e s s = OclUndefined ) and s . acces s−>1079 oc l I sKindOf ( cpp ! CppPrimitiveType )1080 )1081 to1082 t : Haxe ! HaxeC la s s i f i e rAcc e s s (1083 re f e rencedTermina l <− thisModule . Type1084 ( s . a c c e s s )1085 )1086 }10871088 unique lazy ab s t r a c t r u l e Type {


1089 from1090 s : cpp ! CppType (1091 s . usagesInTypeAccess −> notEmpty ( )1092 )1093 to1094 t : Haxe ! Hax eC l a s s i f i e r1095 (1096 )1097 }10981099 unique lazy ru l e pr imi t iveVo id extends Type{1100 from1101 s : cpp ! CppVoidType1102 to1103 t : Haxe !HaxeEnum (1104 name <− ' Void '1105 )1106 }11071108 unique lazy ru l e p r im i t i v e I n t e g e r extends Type{1109 from1110 s : cpp ! CppIntType1111 to1112 t : Haxe ! HaxeClass (1113 name <− ' Int '1114 )1115 }11161117 unique lazy ru l e pr imit iveLong extends Type{1118 from1119 s : cpp ! CppLongType1120 to1121 t : Haxe ! HaxeClass (1122 name <− ' Int '1123 )1124 }11251126 unique lazy ru l e p r im i t i v eSho r t extends Type{1127 from1128 s : cpp ! CppShortType1129 to1130 t : Haxe ! HaxeClass (1131 name <− ' Int '1132 )1133 }1134


1135 unique lazy ru l e pr imi t iveBoo lean extends Type{1136 from1137 s : cpp ! CppBooleanType1138 to1139 t : Haxe ! HaxeClass (1140 name <− ' Bool '1141 )1142 }11431144 unique lazy ru l e pr imit iveChar extends Type{1145 from1146 s : cpp ! CppCharType1147 to1148 t : Haxe ! HaxeClass (1149 name <− ' Str ing '1150 )1151 }11521153 unique lazy ru l e p r im i t i v eF l oa t extends Type{1154 from1155 s : cpp ! CppFloatType1156 to1157 t : Haxe ! HaxeClass (1158 name <− ' Float '1159 )1160 }11611162 unique lazy ru l e pr imit iveDouble extends Type{1163 from1164 s : cpp ! CppDoubleType1165 to1166 t : Haxe ! HaxeClass (1167 name <− ' Float '1168 )1169 }11701171 unique lazy ru l e p r im i t i v eS igned extends Type{1172 from1173 s : cpp ! CppSignedType1174 to1175 t : Haxe ! HaxeClass (1176 name <− ' Int '1177 )1178 }11791180 unique lazy ru l e pr imit iveUns igned extends Type{


1181 from1182 s : cpp ! CppUnsignedType1183 to1184 t : Haxe ! HaxeClass (1185 name <− ' UInt '1186 )1187 }

Índice general - ridaa.unicen.edu.ar

Documents

Transcript of Índice general - ridaa.unicen.edu.ar