ingenieria dirigida por modelos -...

Ingeniería dirigida por modelos (MDA) y casos prácticos

Carlos Enrique Montenegro Marín

© Universidad Distrital Francisco José de Caldas© Doctorado en Ingeniería© Carlos Enrique Montenegro Marín

ISBN: 978-958-8972-89-3ISBN: 978-958-8972-90-9

Primera edición: Bogotá, marzo de 2017

Corrección de estilo y diseño gráfico:Hographics Impresores

Impresión:Hographics Impresores

Doctorado en IngenieríaCarrera 7 # 40B-53BogotáCorreo electrónico: [email protected]

Todos los derechos reservados. Esta publicación no puede ser reproducida ni total ni parcialmente o transmitida por un sistema de recuperación de información, en ninguna forma ni por ningún medio, sin el permiso previo del Doctorado en Ingeniería de la Universidad Distrital Francisco José de Caldas.

Hecho el depósito legal.

Impreso y hecho en ColombiaPrinted and made in Colombia

Montenegro Marín, Carlos E.Ingeniería dirigida por modelos (MDA) y casos prácticos /

Carlos Enrique Montenegro Marín. -- Bogotá : UniversidadDistrital Francisco José de Caldas, 2017.

206 páginas ; 24 cm.ISBN 978-958-8972-89-3 1. Ingeniería de sistemas - Enseñanza superior 2. Ingeniería

de software 3. Programación de computadores 4. AutomatizaciónI. Tít. 005.43 cd 21 ed.A1565747

CEP-Banco de la República-Biblioteca Luis Ángel Arango

CONTENIDO

I. Introducción ....................................................................................................................................11

II. Ingeniería dirigida por modelos (MDA) ........................................................................132.1. Introducción ............................................................................................................................132.2. Ingeniería dirigida por modelos (MDA) ......................................................................132.3. Metamodelos ..........................................................................................................................17

2.3.1 Metamodelos y arquitectura de metadatos .....................................................182.4. Especificación para el intercambio de modelos usando XML (XMI)...............192.5. Espacios de modelado ........................................................................................................202.6. Espacio técnico .....................................................................................................................202.7. Transformaciones entre modelos (M2M)...................................................................21

2.7.1. Clasificación de los lenguajes de transformaciones ....................................212.7.2. Lenguajes de transformaciones ..........................................................................22

2.8. Lenguajes de dominio específico (DSL) ......................................................................242.8.1. Tipos de lenguajes de dominio específico (DSL) ..........................................262.8.2. Partes de un lenguaje de dominio específico (DSL) ....................................27

2.9. Ingeniería dirigida por modelos (MDA) con Eclipse .............................................272.9.1. Meta-metamodelo Ecore de Eclipse ...................................................................272.9.2. El metamodelo .............................................................................................................292.9.3. Construcción del editor para el modelo o lenguaje de

dominio específico (DSL) ................................................................................................292.9.4. El modelo .......................................................................................................................292.9.5. Proceso de generación de código ........................................................................30

2.10. Modelado de dominio específico (DSM) ..................................................................302.10.1. Elementos necesarios para DSM .......................................................................312.10.2. Herramientas DSM ..................................................................................................322.10.3. MDE versus desarrollo tradicional ..................................................................36

III. Transformación de modelos ..............................................................................................393.1. Introducción ............................................................................................................................393.2. Visión alternativa de MDA .................................................................................................39

3.2.1. Representación directa ............................................................................................403.2.1. Automatización ...........................................................................................................403.2.2. Estándares abiertos ...................................................................................................40

3.3. Transformación de modelos ............................................................................................403.3.1. QVT (Query/View/Transformation) ..................................................................413.3.2. VIsual Automated model TRAnsformation (VIATRA) ................................463.3.3. ATLAS Transformation Language (ATL) ..........................................................473.3.4. Motor de transformaciones de BOA 2 ...............................................................473.3.5. Model-To-Model Transformation (M2M) .........................................................483.3.6. Sistemas de generación de código ......................................................................49

3.4. Implementaciones de Model Driven Architecture (MDA) ...................................523.5. Análisis de implementaciones de MDA .......................................................................54

3.5.1. AndroMDA ...................................................................................................... 54

IV. Casos prácticos apoyados en MDA ...................................................................................694.1. Introducción ............................................................................................................................694.2. TALISMAN: metodología ágil con MDA .......................................................................69

4.2.1. Proceso de desarrollo utilizando MDA ..............................................................694.2.2. Adaptación de los MDA a los métodos de desarrollo ágil

de software: TALISMAN ...................................................................................................734.2.3. Análisis ............................................................................................................................744.2.4. Diseño ..............................................................................................................................754.2.5. XMI + Extensiones ......................................................................................................774.2.6. TALISMAN .....................................................................................................................774.2.7. Persistencia ...................................................................................................................78

4.3. Model-Driven Continuous Integration (MDCI) ........................................................794.3.1. Construcción de un prototipo MDCI ..................................................................794.3.2. Soluciones parciales propuestas..........................................................................804.3.3. Elección de una iniciativa MDE ............................................................................844.3.4. Detección de nuevas versiones en los VCS ......................................................844.3.5. Integración de MDE con herramientas de CI ..................................................85

4.3.6. Generación incremental de artefactos ..............................................................854.3.7. Aspectos generales de MDCIP ...............................................................................86

4.3.8. Arquitectura básica de MDCIP ..........................................................................................894.4. Herramienta para el desarrollo rápido de videojuegos con MDA ....................994.5. Manuales del sistema ....................................................................................................... 100

4.5.1. Manual de instalación............................................................................................ 1004.5.2. Manual de ejecución............................................................................................... 1004.5.3. Manual de usuario .................................................................................................. 1034.5.4. Manual del programador ..................................................................................... 1154.5.5. Diagramas de clases de la aplicación .............................................................. 116

4.6. Modelado específico de dominio para la construcción de learning objects independientes de la plataforma ............................................ 120

4.6.1. Metamodelo para sistemas de gestión del aprendizaje .......................... 1204.6.2. KiwiDSM v. 2.0: mejora a la herramienta DSL gráfica para

la construcción de módulos de un LMS ................................................................. 1274.6.3. Transformación a texto y despliegue de la solución ................................ 133

Bibliografía ....................................................................................................................................... 135

Anexos ................................................................................................................................................. 143

Listado de figuras

Fig. 1. Modelo, metamodelo y meta-metamodelo .................................................................14Fig. 2. Espacios de modelado .........................................................................................................15Fig. 3. Ciclo de vida del desarrollo de software con MDA ..................................................16Fig. 4. Proceso de despliegue de una solución completa con MDE ................................17Fig. 5. Arquitectura de metadatos en MOF ...............................................................................19Fig. 6. Espacios de modelado RDF, MOF y EBNF ....................................................................20Fig. 7. Transformaciones entre modelos ...................................................................................21Fig. 8. Arquitectura de QVT .............................................................................................................24Fig. 9. Modelos generados en MDA ..............................................................................................28Fig. 10. Modelo Ecore con sus relaciones, atributos y operaciones ..............................28Fig. 11. GMF Overview ......................................................................................................................29Fig. 12. Arquitectura básica de una solución de dominio específico ............................31Fig. 13. Aspecto general de MetaEdit+ .......................................................................................33Fig. 14. Aspecto general de General Modeling Environment (GME) .............................34Fig. 15. Aspecto general de DSL Tools ........................................................................................35Fig. 16. Aspecto general de Graphical Modeling Framework (GMF) ............................36Fig. 17. Arquitectura de AndroMDA versión 4 .......................................................................59Fig. 18. Especificación e implementación de aplicaciones con MDA ............................71Fig. 19. Proceso de desarrollo iterativo con MDA .................................................................72Fig. 20. Esquema del proceso de desarrollo ágil con TALISMAN ...................................74Fig. 21. Detalle del Análisis en TALISMAN ...............................................................................75Fig. 22. Detalle del análisis en TALISMAN ................................................................................76Fig. 23. Detalle de la arquitectura de TALISMAN ..................................................................77Fig. 24. Motor de persistencia .......................................................................................................79Fig. 25. Prototipo MDCI ....................................................................................................................86Fig. 26. Otra vista del prototipo MDCI ........................................................................................87Fig. 27. Arquitectura básica de MDCIP ......................................................................................88Fig. 28. Archivo de configuración de Cruise Control (ccnet.config) ..............................89Fig. 29. Ccnet.config (repositorio 1) ...........................................................................................91Fig. 30. Ccnet.config (repositorio 2) ...........................................................................................92Fig. 31. Ccnet.config (repositorio 3) ...........................................................................................93Fig. 32. Ccnet.config (repositorio 4) ...........................................................................................95Fig. 33. Estructura de espacio de trabajo (ejemplo) ............................................................96Fig. 34. Archivo oAWcsproj .............................................................................................................98Fig. 35. Archivo SvnCommit.csproj ..............................................................................................98Fig. 36. Archivo TheBeerHouse.sln ..............................................................................................99Fig. 37. Ejemplo de carga de un programa en Visual Studio ......................................... 101

Fig. 38. Selección de proyectos en Visual Studio ................................................................ 101Fig. 39. Generar solución en Visual Studio ............................................................................ 102Fig. 40. Compilación correcta en Visual Studio ................................................................... 102Fig. 41. Inicio de depuración en Visual Studio..................................................................... 102Fig. 42. Pantalla principal ............................................................................................................. 103Fig. 43. Pasos para la creación de personaje ........................................................................ 104Fig. 44. Personaje creado .............................................................................................................. 105Fig. 45. Pasos para la creación de personajes no jugadores .......................................... 105Fig. 46. Creación de objetos de escenario .............................................................................. 107Fig. 47. Escenario principal ......................................................................................................... 107Fig. 48. Selección de plantilla ...................................................................................................... 109Fig. 49. Juego creado ....................................................................................................................... 109Fig. 50. Directorios creados en la operación de guardar ................................................ 110Fig. 51. Objetos creados en la operación de guardar ........................................................ 111Fig. 52. Ficheros de arranque del videojuego ...................................................................... 112Fig. 53. Abrir solución en Visual Studio ................................................................................. 112Fig. 54. Generar solución en Visual Studio ............................................................................ 113Fig. 55. Generación correcta de la solución .......................................................................... 113Fig. 56. Ejecución del juego .......................................................................................................... 114Fig. 57. Aspecto general de un videojuego ............................................................................ 114Fig. 58. Diagrama de paquetes ................................................................................................... 116Fig. 59. Diagrama de clases del paquete Analyzer ............................................................. 117Fig. 60. Diagrama de clases del paquete Game Template ............................................... 118Fig. 61. Diagrama de clases del paquete Interfaz ............................................................... 119Fig. 62. Diagrama general de clases ......................................................................................... 119Fig. 63. Propuesta de integración de una ontología a un metamodelo,

en la arquitectura de cuatro niveles propuesta por la OMG para MDA ............................................................................................................................ 121

Fig. 64. Representación y correspondencia de la EClass User entre la vista gráfica y el explorar de Ecore, que ofrece el plugin de modelado n Eclipse .................................................................................................. 122

Fig. 65. Correspondencia de la EClass User entre la vista gráfica y el código XMI, que ofrece el plugin de modelado en Eclipse.................... 122

Fig. 66. Composición de las EClass Tools Course, Communications y Administration .............................................................................................................. 123

Fig. 67. Composición de las EClass Questions y Answers ............................................... 123Fig. 68. Composición de la EClass Course .............................................................................. 124Fig. 69. Composición de la EClass Communications ......................................................... 125

Fig. 70. Composición de la EClass Administration ............................................................. 125Fig. 71. Metamodelo LMS.............................................................................................................. 126Fig. 72. Patrón de diseño fábrica abstracta ........................................................................... 128Fig. 73. Correspondencia entre el metamodelo de Kiwi v. 1.0,

la paleta de herramientas y el área de trabajo ................................................... 129Fig. 74. Correspondencia entre el metamodelo de Kiwi v. 2.0,

la paleta de herramientas y el área de trabajo ................................................... 129Fig. 75. Cambio del figure descriptor de ComunicationsFigure

por una Ellipse .................................................................................................................. 129Fig. 76. Cambio del Figure Descriptor de para los módulos

Forum, Chat, Wiki, Announcement, News y Note .............................................. 130Fig. 77. Cambio del despliegue de módulos Forum, Chat,

Wiki, Announcement, News y Note en el área de trabajo .............................. 131Fig. 78. Modificación en el árbol de directorios y en Pallet del Tooling

Def Model, para que las imágenes de la barra de herramientas sean las mismas del área de trabajo ........................................................................ 132

Fig. 79. Cambio del Figure Descriptor para la conexión de los módulos ................. 132Fig. 80. Apariencia final de la herramienta KiwiDSM v. 2.0 ........................................... 133

I. INTRODUCCIÓN

Aunque son muchos los esfuerzos realizados para que exista una mayor can-tidad de personas con la competencia de poder solventar los problemas con el apoyo de sistemas informáticos, es una realidad que los resultados no han sido los esperados; se presume que una de las problemáticas es la alta difi-cultad en la curva de aprendizaje que tienen los diversos lenguajes de pro-gramación de propósito general. En este sentido, un reto enorme es abstraer esa complejidad de los lenguajes de programación de uso general a lengua-jes específicos, de forma tal que las personas no dediquen la mayor parte del tiempo a comprender un lenguaje, sino a solventar el problema y a que la sintaxis de ese lenguaje esté acorde con el contexto de dicho problema.

De poder conseguir esto, se eliminaría una gran barrera en cuanto al aprendizaje de una nueva sintaxis y hasta lógica de programación, lo cual implicaría centrarse en dar una solución al problema con el contexto que ya se maneja en la problemática. Así, se espera que el tiempo y los esfuerzos que se dedican a crear un sistema informático se reduzcan drásticamente. Esto, por supuesto, tiene sus implicaciones, pues ahora el problema se tras-lada a construir ese lenguaje en el que la sintaxis esté acorde con el con-texto del problema; a esto se le ha llamado lenguaje de dominio específico (DSL), que está enmarcado dentro de la propuesta de ingeniería dirigida por modelos (MDA).

12


Todo el trabajo que se presenta a continuación es el resultado de varios años de investigación realizada en el interior del grupo de investigación MDA Research Group, de la Universidad de Oviedo (España), que es dirigido por el Dr. Juan Manuel Cueva Lovelle. Esta publicación recopila algunas de las apor-taciones más importantes que el grupo generó en los últimos años.

Desde hace varios años, el autor del presente libro trabajó de manera activa en dicho grupo de investigación, que en la actualidad es uno de los que más aportaciones ha hecho en el área de MDA. De todo el trabajo del grupo se han derivado más de diez artículos publicados en las revistas de mayor relevancia en el área de ingeniaría de software en el ámbito mundial (revistas que poseen un alto factor de impacto, según el Journal Citacion Report [JCR]). De estas publicaciones, el autor de este libro ha contribuido con tres, además de una serie de artículos para otras revistas internaciona-les, ponencias en diversas conferencias que manejan el tema, libros y capítu-los de libros, manuales, tutoriales y toda una base de datos documental que ha servido para que el grupo continúe trabajando en el área y vinculando a nuevos investigadores en el ámbito mundial.

II. INGENIERÍA DIRIGIDA POR MODELOS (MDA)

2.1. Introducción

Este capítulo pretende dar una panorámica general de lo que es la ingenie-ría dirigida por modelos; por ello, se abarcan temas como su definición, los metamodelos, la arquitectura de metadatos, la especificación para el inter-cambio de modelos usando XML (XMI) y la definición de lo que es el espa-cio de modelado y el espacio técnico. Luego se ahondará un poco más en el proceso, para lo cual se estudian temas comas las transformaciones entre modelos (M2M), la clasificación de los lenguajes de transformaciones, los lenguajes de transformaciones, los lenguajes de dominio específico (DSL), sus tipos y sus partes. Posteriormente se abordará la ingeniería dirigida por modelos (MDA) con Eclipse, el meta-metamodelo Ecore de Eclipse, y por úl-timo se presenta un estado del arte acerca del modelado de dominio especí-fico (DSM), con sus componentes y algunas herramientas.

2.2. Ingeniería dirigida por modelos (MDA)

La ingeniería dirigida por modelos (MDA) surge como la respuesta de la in-geniería de software a la industrialización del desarrollo de software. MDA es la propuesta del Object Management Group (OMG), que centra sus esfuerzos en reconocer que la interoperabilidad es fundamental y que el desarrollo

14


de modelos permite la creación de otros más que luego, al ser unidos, pro-veerían la solución a todo un sistema e independizarían el desarrollo de las tecnologías empleadas [1].

Se ha visto cómo el nivel de abstracción de los diferentes lenguajes de programación se ha incrementado durante décadas. Esto se puede conside-rar una evolución en los lenguajes de programación; así, antes se hablaba de lenguajes en binario; luego, del lenguaje ensamblador; más adelante, de los lenguajes procedimentales; posteriormente, de la orientación a objetos, apoyada en diversos artefactos, como lenguaje unificado de modelado (UML); y ahora se habla de construcción de esos modelos como UML, a lo cual se le ha llamado precisamente ingeniería dirigida por modelos (MDA). Y aunque el nivel de abstracción aumente, este se acerca más al dominio específico sobre el cual se trabajará. Así, cualquier persona podría llegar a realizar un modelo empleando los conocimientos de su contexto, y la complejidad se traslada a ver cómo ese modelo se convierte en una solución desplegable y funcional sobre cualquier tecnología específica.

Una buena interpretación de lo que es un modelo, un metamodelo y un meta-metamodelo se encuentra en [2]: un metamodelo se define como esas herramientas que permiten la creación de un modelo; este, a su vez, es una descripción de uno o varios elementos del dominio o el mundo real; final-mente, el meta-metamodelo describe a esos metamodelos planteados y ge-nera un grado de abstracción supremamente alto en el cual coinciden todos los modelos (Fig. 1).

Elementos del mundo real(dominio)

Modelo Metamodelo Meta-metamodelo

describe describe describe

Fig. 1. Modelo, metamodelo y meta-metamodelo

Según [2], básicamente hay cuatro espacios de modelamiento: a) los ni-veles base M0, que son los elementos del mundo real; b) los niveles M1, que son las clases UML, los programas informáticos, entre otros; c) los niveles

Ingeniería dirigida por modelos (MDA)

15

M2, que serían la especificación de UML, ODM, Java, C#, XML, etc., y d) los niveles M3, que son los de mayor abstracción. Básicamente hay dos meta-metamodelos planteados: el Meta-Object Facility (MOF) y el Extended Backus-Naur Form (EBNF), como se muestra en la Fig. 2.

M3

M2

M1

M0

Instancia de

Representado por

MOF

MOF

UML., classes, objects

UML., ODM, ...

Elemenos del mundo real

EBNF

EBNF

Java, Cii, XML...

Programas informáticos

Elementos del mundo real

Fig. 2. Espacios de modelado

La idea de generar estos niveles de abstracción tan altos es proveer un mecanismo común que permita, a través de la transformación de un modelo a otro, la interoperabilidad de los sistemas. Una definición explícita de lo que es MDA se encuentra en [3], a saber:

The Model Driven Architecture (MDA) is a framework for software development defined by the Object Management Group (OMG). Key to MDA is the importance of models in the software development process. Within MDA the software development process is driven by the activity of modeling your software system.

MDA se centra en la generación de modelos; por ello, su ciclo de vida se enfoca hacia la creación de modelos y no modifica para nada el ciclo tra-dicional de vida de desarrollo de software. No obstante, la generación de artefactos cambia, y algunos de ellos —como el paso de un PIM (modelo in-dependiente de la plataforma) a PSM (modelo específico de la plataforma)

16


y luego a código— se realizan de manera automática y recibe el nombre de transformaciones a partir de los modelos generados. De esta forma, si hay un cambio en el sistema, se realiza en el modelo más global, y para desplegar la solución se vuelve a repetir el proceso de trasformaciones entre modelos. En la Fig. 3 se muestra el ciclo de vida del desarrollo de software con MDA.

Fig. 3. Ciclo de vida del desarrollo de software con MDA [3]

El artefacto que reúne los requerimientos del sistema se llama modelo independiente de la computación (CIM); el resultado de modelar este sistema es un PIM, que se hace a través de de un DSL (Domain Specific Language) construido previamente. Este DSL genera, a través de un proceso de trans-formación, un PSM, que por último, y nuevamente a través de otra transfor-mación, se convierte en código desplegable o modelo específico de imple-mentación (ISM). Este proceso se visualiza en la Fig. 4.


17

Modelo

Independiente de la Computación

(CIM)

Requerimientos del sistema

Modelo Independiente de la

Plataforma(PIM)

Modelado del sistema

Domain Specific

Languaje(DSL)

Se hace con

Modelo Específico de la Plataforma

(PSM)

Proceso de transformación

Modelo Específico de Implementación

(ISM)

Proceso de transformación

Fig. 4. Proceso de despliegue de una solución completa con MDE [3]

2.3. Metamodelos

Los metamodelos [4] son uno de los pilares del desarrollo de software di-rigido por modelos (DSDM); sin embargo, cuando se trabaja con modelos, se suelen encontrar dificultades en la definición de los metamodelos, por la

18


gran variedad de representaciones posibles para estos y la ausencia de ma-nuales que guíen su definición.

2.3.1. Metamodelos y arquitectura de metadatos

Un modelo es una abstracción de la realidad, que la presenta de una manera simplificada. Por su parte, un metamodelo es un modelo que describe un lenguaje de modelado (LM), con el que se describen otros modelos. La no-ción de metamodelo se basa en la arquitectura de metadatos que se muestra en la Fig. 5, adoptada por el consorcio Object Management Group (OMG) en la especificación del Meta-Object Facility (MOF) [5]. Esta figura muestra la diferencia entre información, modelos, metamodelos y meta-metamodelos. MOF nombra cada una de estas capas o niveles con los nombres M0, M1, M2 y M3, respectivamente (Fig. 5). De ahora en adelante se usarán los términos M0, M1, M2 y M3 para referirse a las capas de MOF. Es importante fijarse en que estos conceptos están en capas diferentes y poseen significados distin-tos, aunque usen la misma notación.

El nivel más alto es el nivel de los meta-metamodelos, M3. Algunos ejem-plos de lenguajes en este nivel son MOF [5] usado por OMG, EMF (Eclipse Modeling Framework) [6] y GOPRR (Grafo, Objeto, Propiedad, Relación y Rol) [7]. Las instancias de los lenguajes de M3 son los metamodelos, que definen los LM y corresponden al nivel M2. Un ejemplo bien conocido de metamodelos es la definición de UML [8]. Luego están los modelos que re-presentan, por ejemplo, diseños de aplicaciones, que son instancias de los metamodelos y constituyen el nivel M1; cualquier diseño concreto de una aplicación en UML podría servir como ejemplo. Por último, se encuentra el nivel M0, que sería la implementación de los diseños; para decirlo en térmi-nos de programación orientada a objetos, en el nivel M0 se considerarían los objetos de las clases en ejecución, y en el nivel M1 estarían las definiciones de las clases de objetos.


19

Fig. 5. Arquitectura de metadatos en MOF

2.4. Especificación para el intercambio de modelos usando XML (XMI)

El estándar de la OMG XMI [5] es una especificación basada en XML para compartir metadatos MDA. Actualmente, XMI es la base para conseguir inte-roperabilidad entre herramientas de apoyo a MDA. Una de las grandes ven-tajas de XMI es que sobre él se pueden almacenar todos los modelos basados en MOF, utilizando un mismo esquema; sin embargo, tiene inconvenientes, como su complejo formato para ser comprendido por humanos o que mu-chas herramientas que trabajan con XMI no se ajustan a las especificaciones de la recomendación.

20


2.5. Espacios de modelado

Un espacio de modelado o modeling space (MS) es una determinada arqui-tectura de modelado basada en un meta-metamodelo específico. Todos los conceptos de las capas inferiores (empezando por la M0) se definen me-diante los conceptos de capas superiores, hasta llegar a la última capa, la cual contiene el meta-metamodelo que es autodefinido. Si el meta-metamo-delo se definiese con conceptos de otro metamodelo, entonces no sería un meta-metamodelo.

La Fig. 6 muestra una serie de MS conocidos. El más difundido quizás es MOF MS, que se define mediante el meta-metamodelo MOF y, a su vez, deter-mina varios metamodelos como UML y ODM. Otro ejemplo de MS es el que tiene EBNF [9] como meta-metamodelo para definir gramáticas libres de con-texto. Debajo de EBNF estarían los lenguajes como Java, C#, XML, y por último, en la capa M1 estarían los programas o ficheros escritos en esos lenguajes.

RDF(S) MOF EBNF

OWLRDF(S) UML ODM Javagrammar

XMLgrammar

RDF(S) space MOF space EBFN space

RDF(S)model

OWLmodel

UMLmodel

ODMmodel

Javaprogram

XMLdocument

M0

M1

M2

M3

Real-worldthings

Rep

rese

nts

Def

ines

Def

ines

Fig. 6. Espacios de modelado RDF, MOF y EBNF

2.6. Espacio técnico

Los espacios de modelado son un concepto inspirado en los espacios técni-cos o technical spaces (TS) [10]. Se puede definir un TS como un contexto


21

de trabajo que incluye varios MS relacionados. Por ejemplo, un TS podría ser MDA TS, el cual incluye al MOF MS; pero también incluye parcialmente a otros MS como EBNF MS, para darle soporte a la construcción de los archivos en formato XMI.

2.7. Transformaciones entre modelos (M2M)

Una transformación de modelos significa convertir un modelo de entrada (o un conjunto de modelos descritos por un determinado metamodelo) en otro modelo descrito por un segundo metamodelo (Fig. 7).

Fig. 7. Transformaciones entre modelos

Esta conversión se realiza definiendo una serie de reglas que concuerdan con los elementos del modelo de entrada y producen elementos del modelo de salida. Las transformación en sí misma es un modelo descrito por un de-terminado metamodelo de transformación [11].

2.7.1. Clasificación de los lenguajes de transformaciones

Un lenguaje de transformación es declarativo si las definiciones de las trans-formaciones escritas especifican relaciones entre los elementos del modelo

22


origen y destino, sin importar el orden de ejecución. Las relaciones se pue-den especificar en términos de funciones o funciones de inferencia. Por otro lado, un lenguaje de transformaciones es imperativo si especifica una deter-minada secuencia de pasos para ser ejecutados en orden, con la finalidad de producir un determinado resultado. Puede existir una categoría intermedia conocida como lenguajes de transformaciones híbridos, los cuales tienen una mezcla de contracciones declarativas e imperativas.

Algunos lenguajes permiten especificar las definiciones de las transfor-maciones en un único sentido: de un modelo origen a un modelo destino. A estos lenguajes se les conoce como unidireccionales. Otros lenguajes (nor-malmente declarativos) permiten especificar las definiciones en los dos sen-tidos y se les conoce como bidireccionales. Esta característica es importante cuando se necesita que dos modelos estén sincronizados.

Un escenario típico toma un modelo origen y produce un modelo destino como salida (transformaciones 1-1). Generalmente existen tres casos más: 1-N, N-1 y N-M. El más general es el 1-N, donde se toma un modelo de origen y se crean varios modelos (por ejemplo, de un modelo se puede generar có-digo Java y ficheros XML para intercambio de datos). Por último, se pueden definir tres tipos de transformaciones [2]:

a. Refactoring transformations. Manejan la reorganización de un mode-lo base de acuerdo con una serie de criterios bien definidos. En este caso, el modelo destino es una revisión del modelo original.

b. Model-to-model transformations. Convierten la información de un modelo origen (o un conjunto de modelos) a un modelo destino (o un conjunto de modelos).

c. Model-to-text tranformations. Convierten cada elemento del modelo origen en definiciones de texto.

2.7.2. Lenguajes de transformaciones

Básicamente, existen dos lenguajes para las transformaciones entre mode-los: Query View Transformation (QVT), que ha sido creado por OMG, y Atlas Tranformation Language (ATL), que se enmarca dentro de EMF.


23

2.7.2.1. Query View Transformation (QVT)

QVT [12] es un estándar propuesto por la OMG para resolver el problema de la transformación de modelos. Define tres abstracciones cuyas letras inicia-les forman el acrónimo que le da su nombre:

a. Query o consulta. Es una expresión que se evalúa sobre un modelo. Los resultados de aplicar esta expresión sobre un modelo son una o varias instancias de los tipos definidos en el modelo transformado o en el propio lenguaje de consulta.

b. View o vista. Es un modelo obtenido a partir de otro modelo base.c. Transformation o transformación. Es una operación que obtiene un

modelo (destino) a partir de otro (fuente).A partir de las abstracciones anteriores se definieron dos tipos de len-

guaje: a) uno de consulta, que cubriría las vistas y consultas, y b) otro de transformaciones, que se corresponde con la abstracción del mismo nombre. Estos lenguajes deben estar definidos como metamodelos de MOF; a su vez, todos los modelos manipulados por las transformaciones deben ser instan-cias de ese metamodelo.

QVT está compuesto por un conjunto de lenguajes estándar de dominio específico (DSL), propuesto por la OMG para la transformación de modelos. Las transformaciones que se definen están basadas en metamodelos MOF. Los lenguajes que componen esta especificación son:

a. Core. Es el lenguaje declarativo de menor nivel de abstracción dentro de QVT; soporta reconocimiento/coincidencia de patrones sobre un conjunto de variables.

b. Relations. Es un lenguaje declarativo de QVT; proporciona formas de declarar restricciones que deben satisfacer los elementos de los mo-delos candidatos.

c. Operational maping. Es un lenguaje imperativo de QVT; proporciona extensiones OCL con efectos laterales que permiten una programa-ción de tipo procedimental y una sintaxis concreta que es más fami-liar para los programadores acostumbrados a este tipo de lenguajes.

24


Relations

Relationsto Core

Transformation

Core

Blac

k Bo

xIm

plem

enta

tion

Ope

ratio

nal

Map

ping

Fig. 8. Arquitectura de QVT

Es importante destacar que QVT se centra en transformaciones model-to-model; por ello, las transformaciones model-to-text quedan fuera del estándar.

2.7.2.2. Atlas Tranformation Language (ATL)

ATL es un lenguaje para transformaciones de modelos; especifica un meta-modelo y una sintaxis concreta de tipo textual. En el contexto de MDE, ATL proporciona una forma de especificar cómo producir un conjunto de mode-los destino a partir de un conjunto de modelos origen.

ATL es un lenguaje híbrido, aunque el estilo preferido es el declarativo, porque posibilita expresar mapeos entre los elementos del modelo destino y los del modelo origen de forma sencilla. Por otro lado, se proporcionan construcciones imperativas para poder especificar aquellos mapeos que di-fícilmente son expresables mediante construcciones declarativas. Una trans-formación ATL se compone de reglas que definen sobre qué elementos del modelo origen se aplican y qué elementos del modelo destino se producen.

2.8. Lenguajes de dominio específico (DSL)

Muchos de los problemas que aparecen durante el desarrollo del software surgen una y otra vez de forma repetitiva; además, en muchas ocasiones


25

estos problemas pertenecen a un dominio concreto. Para dar solución a es-tos problemas se puede utilizar un GPL (general purpose language) como es Java y C#, o bien, se puede recurrir a la utilización de un DSL (domain specific language); este último no es más que un lenguaje definido específicamente para resolver los problemas de un dominio concreto.

A partir del contexto de DSL se puede hablar de DSM (modelado de do-minio específico), que tiene su origen en la existencia de muchos desarrollos similares para un mismo dominio: una parte común y una parte variable. La parte común podría desarrollarse por medio de técnicas de desarrollo tra-dicionales, en tanto la parte variable podría hacerlo a través de un DSL. Un ejemplo sería la realización de sistemas para la realización de encuestas, que pueden compartir un mismo motor y una misma base de datos, pero que tie-nen que adaptarse a la estructura de las diferentes encuestas. Como la única parte variable es la encuesta, se podría crear un DSL para definirlas.

La unificación de la parte fija y la parte variable se puede hacer mediante dos aproximaciones:

a. Interpretativa. La parte es “leída” mediante un intérprete que se en-cuentra en la parte común; esta aproximación proporciona una ma-yor flexibilidad, pero acarrea inconvenientes como la pérdida evi-dente de rendimiento.

b. Generativa de código. La parte común y la parte variable se unen y se compilan para generar una solución como un todo; es una aproxi-mación más complicada de realizar, pero evita las desventajas de la aproximación interpretativa.

Los DSL intercambian generalidad por expresividad en un dominio limi-tado. Ofrecen además notaciones y construcciones orientadas a un dominio particular, lo cual representa ganancias sustanciales en términos de expre-sividad y facilidad de uso, en comparación con los GPL para el dominio en cuestión. Estas ganancias consisten en mejoras de la productividad y reduc-ción de los costes de mantenimiento. Algunos lenguajes de dominio específi-co se listan a continuación:

• EBNF: especificación de sintaxis • Excel: hojas de cálculo • HTML: páginas web de hipertexto

1

26


• Make: construcción de software • Matlab: matemáticas computacionales • SQL: consultas a bases de datos • VHDL: diseño de hardware

2.8.1. Tipos de lenguajes de dominio específico (DSL)

Se pueden distinguir tres clasificaciones para los DSL: desde el punto de vis-ta de la construcción, el formato y el dominio.

Desde un punto de vista de la construcción del lenguaje, se clasifican en:a. Internos. Utilizan un determinado lenguaje anfitrión para darle la

apariencia de otro lenguaje concreto. Un ejemplo claro es lo que ac-tualmente se conoce como fluent interfaces [13].

b. Externos. Tiene su propia sintaxis y es necesario un parser para po-der procesarlos. Un ejemplo claro de DSL externo es SQL.

Desde el punto de vista del formato del lenguaje, se clasifican en:a. Textuales. La mayoría de los lenguajes informáticos son textuales y

están formados por un conjunto ordenado de sentencias. Un ejemplo muy conocido de DSL textual es SQL, utilizado para realizar consultas a una base de datos. Una forma de generar DSL textuales es mediante la creación de una determinada gramática (por ejemplo, utilizando EBNF) y posteriormente crear o utilizar un parser para dicha gramá-tica, para en etapas posteriores poder interpretar el DSL o generar código.

b. Gráficos. En los últimos años están ganando gran aceptación los len-guajes gráficos; podría citarse como ejemplo UML. La creación de un lenguaje gráfico es similar a la de un lenguaje textual; la única dife-rencia es que en lugar de usar texto para representar los conceptos, se utilizan conectores y figuras simples.

Desde el punto de vista del dominio del problema, se clasifican en:a. Horizontales. Son aquellos en los que el cliente que utilizará el len-

guaje no pertenece a ningún dominio específico. Un ejemplo son los editores visuales de entornos de desarrollo, que permiten generar


27

interfaces de usuario de manera automática (por ejemplo, Windows Forms, de Visual Studio).

b. Vertical. A diferencia de los DSL horizontales, el cliente que utilizará el lenguaje pertenece al mismo dominio que el lenguaje en sí. Como en el ejemplo anterior, para un lenguaje de definición de encuestas, los usuarios finales serían los expertos en estadística encargados de definirlas.

2.8.2. Partes de un lenguaje de dominio específico (DSL)

Los DSL son el elemento principal de cualquier solución de este dominio. El lenguaje se define como un metamodelo, una notación específica y, gene-ralmente, una herramienta que lo soporta para facilitar la usabilidad. La idea básica es no utilizar conceptos de lenguajes de programación de propósito general; en su lugar, se utilizan conceptos y reglas de dominio.

La sintaxis abstracta de un lenguaje especifica su estructura, es decir, las construcciones, las propiedades y los conectores que pueda tener dicho lenguaje. La sintaxis concreta es necesaria para definir la notación específi-ca con la que los usuarios del lenguaje podrán utilizarlos. Idealmente, cada concepto del dominio y del lenguaje se mapearán a una representación en la notación específica. Es importante reseñar que una misma sintaxis abs-tracta podría tener diferentes sintaxis concretas.

2.9. Ingeniería dirigida por modelos (MDE) con Eclipse

2.9.1. Meta-metamodelo Ecore de Eclipse

El meta-metamodelo que se empleará será Ecore, que se encuentra en el paquete org.eclipse.emf.ecore y es la especificación más alta que existe en la pirámide de los modelos (M3) de la Fig. 9; sobre ella se construirá el meta-modelo del proyecto. La especificación de Ecore se puede consultar en [14] (Fig. 10).

28


Fig. 9. Modelos generados en MDA

Fig. 10. Modelo Ecore con sus relaciones, atributos y operaciones [14]


29

2.9.2. El metamodelo

Para la utilización de Ecore en Eclipse es necesario tener instalado el plugin de EMF (Eclipse Modeling Framework), el cual provee básicamente dos he-rramientas para construir un modelo basado en Ecore: por un lado, el Ecore Model, que es un editor manual que funciona en un estilo de árbol de na-vegación para la creación del modelo basado en Ecore; por otro, el Ecore Diagram, un editor gráfico similar a las herramientas gráficas para la creación de diagramas de clases UML. Cualquiera de las dos formas que se utilice para crear el diagrama basado en Ecore genera un fichero XMI 5] (XML Metadata Interchange), que es una especificación para el intercambio de diagramas.

2.9.3. Construcción del editor para el modelo o lenguaje de dominio específico (DSL)

Como se está trabajando bajo Eclipse, para esta etapa se debe emplear GMF Tooling (Graphical Modeling Framework Tooling), que forma parte del pro-yecto GMP (Graphical Modeling Project) [15]. El proceso para la construc-ción del DSL gráfico se visualiza en la Fig. 11.

Fig. 11. GMF Overview [16]

2.9.4. El modelo

El diagrama que se obtenga como resultado de emplear el editor de DSL tendrá asociado un fichero XM [17] que basará su sintaxis en el metamodelo creado.

30


2.9.5. Proceso de generación de código

En este último paso existen varias tecnologías que se integran a Eclipse, como Acceleo [18], Jet, Xpand [19] y MOFScript [20]. Todas emplean el mis-mo principio: la creación de reglas de transformación con base en un me-tamodelo. Estas reglas serán aplicadas al modelo para generar código en el lenguaje deseado; este tipo de tecnologías reciben el nombre M2T o model- to-text. La transformación de un modelo a otro se llama de M2M o model-to-model; algunas herramientas como ATL [21] o OperationalQVT realizan esta tarea.

Finalmente, aplicando las tecnologías de transformación sobre el modelo creado, se obtiene el código en el formato definido para su despliegue.

2.10. Modelado de dominio específico (DSM)

Cuando se tiene cierta experiencia en el desarrollo de software, se observa que muchos problemas son repetitivos. Además, en muchas ocasiones estos problemas pertenecen a un dominio concreto de conocimiento. Como solu-ción se puede utilizar un GPL (General Purpose Language, o lenguaje de pro-pósito general) como Java y C#, o bien, se puede recurrir a la utilización de un DSL.

A partir del concepto de DSL (Domain-Specic Language, o lenguaje de dominio específico) [22] se puede hablar también de DSM (Domain-Specic Modeling, o modelado de dominio específico) [23], que tiene su origen en la existencia de muchos desarrollos de software similares para un mismo dominio de conocimiento y comprenden una parte común y una parte varia-ble (en algunas ocasiones, la parte común no existe). La parte común podría desarrollarse utilizando las técnicas de desarrollo tradicionales, en tanto la parte variable podría hacerlo por medio de un DSL pensado para ese domi-nio específico, a fin de aumentar la productividad.

Los conceptos de DSM y DSL son fundamentales para trabajar con MDE. La idea básica es crear lenguajes especialmente pensados para solucionar un problema en un dominio muy concreto y permitir así que las construcciones del lenguaje sean muy cercanas a los conceptos del propio dominio. Para


31

unificar la parte fija o común y la parte variable del software, se presentan dos posibles aproximaciones [24]

a. Interpretativa. La parte común tiene un intérprete para procesar la parte variable. De ese modo se consigue extensibilidad, pero se pre-sentan inconvenientes como la pérdida evidente de rendimiento y la dificultad para realizar la depuración o debug.

b. Generativa. La parte común y la parte variable se unen y se compilan para generar la solución como un todo. Aunque es más compleja de realizar, evita las desventajas de la aproximación interpretativa.

2.10.1. Elementos necesarios para DSM

Existen varios elementos imprescindibles para lograr crear con éxito una so-lución de dominio específico [25]. Básicamente, se utiliza una arquitectura en capas (Fig. 12) que puede variar dependiendo del caso; incluso se llega a eliminar la plataforma base o framework de dominio en algunas ocasiones:

DSM Lenguaje

Generador

Plataforma base

Entorno objetivo

Fig. 12. Arquitectura básica de una solución de dominio específico

32


a. Lenguajes y modelos. La clave en DSM consiste en crear un modelo que conforme un metamodelo mediante el empleo de un DSL. Como los lenguajes y los modelos ya han sido abordados en este documen-to, no se entrará en más detalle.

b. Generadores. Los generadores tienen que obtener la información de los modelos y generar artefactos (por ejemplo, código fuente) a par-tir de ellos. En los casos más sencillos se mapea cada símbolo del lenguaje a un determinado fragmento de código; el código generado también podría ser variable dependiendo de los valores de las en-trada. La idea es que a partir del modelo se generen artefactos sin necesidad de intervención manual.

c. Plataforma base. Es la interfaz entre el código generado y la plata-forma o el entorno objetivo. En algunos casos, la relación es directa y no hace falta añadir más código que el que se haya generado auto-máticamente. En otros casos, sin embargo, es necesario utilizar pla-taformas base para añadir código, de forma que todas las soluciones utilicen un código común fijo creado previamente. Las plataformas base habitualmente reciben otros nombres como framework arqui-tectónico, framework base o framework de dominio.

d. Entorno objetivo. El entorno objetivo es la máquina física o virtual para la cual se pretende desarrollar un sistema; por ejemplo, un en-torno objetivo podría ser una determinada versión de la máquina virtual de Java.

2.10.2. Herramientas DSM

A continuación se mencionan algunas de las herramientas software que se utilizan en la actualidad para dar soporte a DSM.

2.10.2.1. MetaEdit+

Esta herramienta está basada en la herramienta MetaEdit, pero mejora as-pectos arquitecturales que no habían sido resueltos correctamente y que ahora aumentan la escalabilidad y la eficiencia de la herramienta. Se puede

ingenieria dirigida por modelos -...

Documents