PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos

Facultad de Informática Informatika Fakultatea

TITULACIÓN: Ingeniería Informática

Analisis de Lenguajes Específicos de Dominio para Sistemas Embebidos

Alumno/a: D./Dña. Ander Zubizarreta Garcia

Director/a: D./Dña. Oscar Diaz Garcia

Proyecto Fin de Carrera, julio de 2009

Facultad de Informática de San Sebastián Donostiako Informatika Fakultatea ACTA DE CALIFICACIÓN KALIFIKATZEKO AKTA

IKASTURTEA

CURSO KODEA

CÓDIGO

IKASLEA

ALUMNO/A N.A.N.

D.N.I.

Reunido el tribunal examinador en el día de la fecha, constituido por:

Egunean bildurik ondorengo partaideek osatutako epaimahiak:

Presidentea / Presidente/a:

Idazkaria / Secretario/a:

Batzordekidea / Vocal:

para juzgar el siguiente proyecto de Fin de Carrera:

ondorengo Karrera Bukaerako Proiektua epaitzeko:

presentado por

-k aurkeztua

dirigido por

-k zuzendua

acordó otorgar la siguiente calificación:

ondorengo kalifikazioa ematea erabaki zuen:

Y para que conste, y a los efectos oportunos, extiende, firmada por todos los comparecientes del tribunal, la presente acta

Horrela ager dadin, eta dagozkion ondorioak sor ditzan, bertaraturiko batzordekideek sinatutako ebaluazio-akta hau ematen du

Donostian, __________(e)ko ______________________ren _____(e)(a)n

En Donostia, a _____ de _______________________ de __________

Presidentea / El/La Presidente/a Batzordekidea / Vocal Idazkaria / El/La Secretario/a

________________________________ ________________________________ ________________________________

Facultad de Informática Informatika Fakultatea

TITULACIÓN: Ingeniería Informática

Analisis de Lenguajes Específicos de Dominio para Sistemas Embebidos

Alumno/a: D./Dña. Ander Zubizarreta Garcia

Director/a: D./Dña. Oscar Diaz Garcia

Proyecto Fin de Carrera, julio de 2009

Resumen

Un lenguaje específico de dominio (DSL) es un lenguaje creado para dar solución aun problema de un dominio determinado. Los DSL permiten expresar problemas o solu-ciones más claramente que otros lenguajes de propósito general. Normalmente son menoscompletos, pero más expresivos, permitiendo un mayor nivel de abstracción.

El desarrollo dirigido por modelos (MDD) es un paradigma para la automatización dela generación de código. Los programas son representados mediante modelos que con-forman a un metamodelo. Mediante el uso de transformaciones, los modelos pueden sertransformados en otros modelos o en código de implementación.

El uso del desarrollo dirigido por modelos en las líneas de producto software (SPL)introduce la variabilidad al MDD.

En este proyecto se analizan el estado del arte de estos paradigmas y las herramientasdisponibles para trabajar con ellos, mediante casos de estudio. También se muestra cómopuede ser introducida la variabilidad al MDD.

Palabras clave: lenguajes específicos de dominio, desarrollo dirigido por modelos, sis-temas embebidos

Laburpena

Domeinuko lengoaia espezifikoak (DSL) domeinu jakin bateko arazoari soluzioa ema-teko garatutako lengoaiak dira. DSLek bai problemak eta baita soluzioak ere beste xedeorokorreko lengoaiek baino modu argiagoan irudikatzea ahalbidetzen dute. Normaleansinpleagoak izan arren, adierazgarriagoak dira, abstrakzio maila altuagoa onartzen dute-larik.

Modelo bidezko software garapena (MDD) inplementazio kodea modeloetatik au-tomatikoki sortzea helburu duen paradigma bat da. Softwarea metamodelo jakin batezzehaztutako modelo bidez irudikatzen da. Transformazioen erabilerarekin modelo batsistema beraren beste modelo batean eraldatu daiteke, sistemaren beste irudikapen batizateko, edo inplementazio kodea sor daiteke.

Modelo bidezko software garapenaren eta software produktu lerroen (SPL) artekokonbinaketarekin MDDaren arloan aldakortasuna ahalbidetzen da.

Proiektu honetan paradigma hauen artearen egoera eta beraiekin lan egitea ahalbide-tzen duten tresnak analizatzen dira, kasu-azterketen bitartez. Aldakortasuna MDDarenarloan nola gauzatu ere erakusten da.

Gako-hitzak: domeinuko lengoaia espezifikoak, modelo bidezko software garapena,sistema txertatuak

Summary

A domain specific language (DSL) is a language created to solve a problem in a spe-cific domain. The DSL allow to express problems or solutions more clearly than othergeneral purpose languages. They are usually more expressive, allowing a higher level ofabstraction.

Model driven development (MDD) is a paradigm for the automation of code genera-tion from models. The programs are represented by models that conform to a metamodel.Using transformations, models can be transformed into other models or implementationcode.

The use combination of MDD with software product lines (SPL) introduces variabilityto the MDD.

This project analyzes the state of the art of these paradigms and the tools available towork with them, through case studies. It also shows how the variability can be introducedto the MDD.

Keywords: domain specific languages, model driven development, embedded systems

Índice general

Índice general I

Índice de figuras V

Índice de tablas VII

1. Introducción 11.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4. Organización del documento . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Documento de Objetivos del Proyecto 72.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3. Alcance: entregas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4. Diagrama EDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5. Asignación de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6. Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6.1. Gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6.2. Estudio de estado del arte . . . . . . . . . . . . . . . . . . . . . 10

2.6.3. Análisis de herramientas . . . . . . . . . . . . . . . . . . . . . . 10

2.6.4. Desarrollo de prototipo . . . . . . . . . . . . . . . . . . . . . . . 10

2.6.5. Cierre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.7. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.8. Factores de riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.9. Método de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.9.1. Miembros del equipo del proyecto . . . . . . . . . . . . . . . . . 12

I

ÍNDICE GENERAL

2.9.2. Reuniones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.9.3. Seguimiento del proyecto. . . . . . . . . . . . . . . . . . . . . . 12

3. Conceptos básicos 133.1. Sistemas embebidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1. Características de los sistemas embebidos . . . . . . . . . . . . . 13

3.1.2. Ejemplo de sistema embebido . . . . . . . . . . . . . . . . . . . 15

3.2. Ingeniería de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1. Fases en el desarrollo de software . . . . . . . . . . . . . . . . . 16

3.2.2. Automatización del desarrollo . . . . . . . . . . . . . . . . . . . 17

3.2.3. Ingeniería de software vs. ingeniería de sistemas . . . . . . . . . 20

4. Lenguajes Específicos de Dominio 214.1. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.1. Introducción a los DSL . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.2. Diseño de DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.3. Uso de DSL en la industria . . . . . . . . . . . . . . . . . . . . . 25

4.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1. MetaEdit+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.2. EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.3. Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.2. Definición del lenguaje de modelado . . . . . . . . . . . . . . . . 33

4.3.3. Utilización del lenguaje de modelado . . . . . . . . . . . . . . . 34

4.3.4. Beneficios obtenidos . . . . . . . . . . . . . . . . . . . . . . . . 35

5. Desarrollo de Software Dirigido por Modelos 375.1. Conceptos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.1. MDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.3. Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.4. Transformaciónes de modelos . . . . . . . . . . . . . . . . . . . 39

5.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.1. MetaEdit+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.2. Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . . 43

5.2.3. ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

II

ÍNDICE GENERAL

5.2.4. MOFScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.5. MDWorkbench . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.6. IBM Telelogic Rhapsody . . . . . . . . . . . . . . . . . . . . . . 51

5.2.7. RulesComposer . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.2.8. Comparativa y conclusiones . . . . . . . . . . . . . . . . . . . . 54

5.3. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3.2. Transformación de modelo a texto con MOFScript . . . . . . . . 55

5.3.3. Transformación de modelo a modelo con ATL . . . . . . . . . . 56

5.3.4. Ejemplo con Rhapsody y RulesComposer . . . . . . . . . . . . . 57

5.3.5. Beneficios obtenidos . . . . . . . . . . . . . . . . . . . . . . . . 59

6. Variabilidad en el MDD 616.1. Conceptos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.1.1. MDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.1.2. SPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.2. Necesidad de la variabilidad . . . . . . . . . . . . . . . . . . . . . . . . 64

6.2.1. Escenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.2.2. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.3. Refinamiento de transformaciones . . . . . . . . . . . . . . . . . . . . . 65

6.3.1. Transformación base . . . . . . . . . . . . . . . . . . . . . . . . 66

6.3.2. Refinamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.3.3. Composición de la base y el refinamiento . . . . . . . . . . . . . 69

6.4. Trabajo relacionado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7. Gestión del proyecto 717.1. EDT inicial vs EDT final . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.2. Estimación de recursos inicial vs recursos invertidos . . . . . . . . . . . . 72

7.2.1. Tabla de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.2.2. Diagrama de Gantt real . . . . . . . . . . . . . . . . . . . . . . . 74

8. Conclusiones 758.1. Contribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8.2.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . 76

8.2.2. Conclusiones personales . . . . . . . . . . . . . . . . . . . . . . 77

III

ÍNDICE GENERAL

8.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Bibliografía 79

IV

Índice de figuras

2.1. Diagrama EDT inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2. Diagrama de Gantt inicial . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1. Sistema embebido en un aerogenerador . . . . . . . . . . . . . . . . . . 15

3.2. Fases en el desarrollo de software . . . . . . . . . . . . . . . . . . . . . 16

3.3. Línea de Producto Software . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1. Ejemplos de DSL textual y gráfico . . . . . . . . . . . . . . . . . . . . . 22

4.2. Diagrama de tres niveles . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3. DSL para aplicaciones Nokia . . . . . . . . . . . . . . . . . . . . . . . . 25

4.4. Metamodelado utilizando GOPPRR en MetaEdit+ . . . . . . . . . . . . . 27

4.5. Modelado con MetaEdit+ . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.6. Metamodelado con Ecore . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.7. Modelado con EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.1. Escenario MDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.2. Transformacion MetaEdit+ . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.3. Transformación ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.4. Transformación MOFScript . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.5. Transformacion utilizando TGL . . . . . . . . . . . . . . . . . . . . . . 49

5.6. Plantilla para generar documentación en Word . . . . . . . . . . . . . . . 50

5.7. Representación del sistema UK01 en Rhapsody . . . . . . . . . . . . . . 51

5.8. Navegación de modelos en RulesComposer . . . . . . . . . . . . . . . . 53

5.9. Fichero TenpKont.cpp generado con MOFScript . . . . . . . . . . . . . . 56

5.10. Modelo UML generado con ATL . . . . . . . . . . . . . . . . . . . . . . 57

5.11. Documentación generada con RulesComposer . . . . . . . . . . . . . . . 58

6.1. Modelo de control de temperatura . . . . . . . . . . . . . . . . . . . . . 62

6.2. Definición de transformación con MOFScript . . . . . . . . . . . . . . . 63

V

ÍNDICE DE FIGURAS

6.3. Transformación base (representación XMI) . . . . . . . . . . . . . . . . 666.4. Refinamiento para Ada con XAK . . . . . . . . . . . . . . . . . . . . . . 676.5. Composición de la transformación . . . . . . . . . . . . . . . . . . . . . 686.6. Código generado: (a) Ada; (b) Java . . . . . . . . . . . . . . . . . . . . . 69

7.1. Diagrama EDT final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.2. Diagrama de Gantt real . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

VI

Índice de tablas

2.1. Asignación de recursos en la planificación inicial . . . . . . . . . . . . . 9

4.1. Elementos del diagrama de 3 niveles en cada herramienta . . . . . . . . . 27

5.1. Características del las herramientas de MDD . . . . . . . . . . . . . . . . 54

7.1. Tabla comparativa de horas planificadas frente a horas invertidas . . . . . 73

VII

ÍNDICE DE TABLAS

VIII

Capítulo 1

Introducción

En las siguientes líneas se presenta el contexto en el que se sitúa este proyecto, mos-trando una visión general del mismo. Se detallan los objetivos que persigue el proyecto yla metodología utilizada para cumplirlos.

1.1. Contexto

El desarrollo de software ha ido evolucionando, introduciendo nuevos lenguajes yparadigmas que ofrecen mejoras al desarrollo. Simultáneamente también los lenguajes ylas herramientas de modelado han ido adquiriendo cada vez más importancia. No obstanteestos últimos son muchas veces utilizados como herramientas de documentación y nocomo herramientas de diseño de software.

La mayoría de los lenguajes utilizados actualmente en el desarrollo de software, tantolenguajes de programación (Java, C/C++, etc.) como lenguajes de modelado (UML, etc.),son lenguajes de propósito general. Aunque la utilización de cada lenguaje pueda sermás o menos apropiada en una situación determinada, todos los lenguajes de este tipopermiten, en general, dar solución a cualquier problema, sin que importe el dominio en elque se sitúa el mismo.

Aunque los lenguajes hayan ido evolucionando, la forma de desarrollar el software noha sufrido grandes cambios. Con la introducción de los lenguajes específicos de dominioo DSL (Domain Specific Languages) y el desarrollo dirigido por modelos o MDD (ModelDriven Development), se pretende dar un salto cualitativo en la evolución del desarrollode software.

Los DSL son lenguajes definidos para dar solución a problemas en un dominio deter-minado. Estos lenguajes permiten representar la solución a un problema en un nivel de

1

CAPÍTULO 1. INTRODUCCIÓN

abstracción y términos propios del dominio, lo cual facilita su aprendizaje por parte depersonas familiarizadas con ese dominio.

El MDD es un paradigma en el que el software es representado mediante modelos,a partir de los cuales, aplicando transformaciones, se pueden obtener nuevos modelos,o bien código de implementación. En el MDD los modelos no son utilizados sólo paradiseñar o documentar el software, sino con el objetivo de generar el código automática-mente a partir de los mismos. Al igual que con los programas, los modelos pueden serrepresentados utilizando lenguajes de modelado de propósito general o específicos de do-minio. Estos últimos tienen la ventaja de permitir un mayor nivel de abstracción en larepresentación gráfica de un programa.

Actualmente, en el desarrollo de software, es frecuente hablar de familias de pro-gramas que consisten en un mismo producto que admite distintas variaciones. En estecontexto se sitúan las Líneas de Producto Software o SPL (Software Product Lines). LasSPL permiten la reutilización de código, mediante la definición de distintos componentesque se componen en distintas combinaciones para generar diferentes productos finales.

La combinación de las SPL con el MDD añade a este último el concepto de la varia-bilidad. En este caso se modela la parte común de los distintos productos por una parte,y las posibles variaciones por otra, pudiendo crear los modelos de los distintos productosfinales mediante la composición del modelo base con diferentes variaciones.

Este proyecto se sitúa en un contexto en el que se quiere generar de forma automáticael código para una familia de programas para sistemas embebidos a partir de modelos, enun dominio específico. La utilización del MDD es esencial en el modelado del softwarepara la posterior generación automática de código, y su combinación con los DSL y lavariabilidad puede ofrecer una solución interesante al problema. Es precisamente esa lacuestión que se aborda en este trabajo.

1.2. Objetivos

El objetivo principal que persigue el proyecto es analizar los lenguajes específicos dedominio. En particular, analizar el estado del arte y las herramientas existentes, centrán-dose en el tema de Desarrollo Dirigido por Modelos y generación de código para sistemasembebidos. Los objetivos del proyecto se pueden dividir en tres partes:

2

1.3. METODOLOGÍA

Estado del arte

Por una parte se quiere analizar el estado del arte tanto de los DSL como del MDD.Aunque no sean conceptos novedosos, su implantación en el mundo de la ingeniería desoftware no está muy extendida todavía. Aún así, son conceptos que van adquiriendocada vez más importancia, y es por ello por lo que es conveniente conocer qué se hahecho y cómo se han utilizado hasta ahora, así como analizar qué herramientas existen enel mercado para trabajar con ellos. El objetivo es estudiar qué ventajas nos pueden ofrecertanto los DSL como el MDD respecto a cómo se desarrolla el software habitualmente.

Herramientas

Existen diversas herramientas para MDD. Algunas ofrecen utilidades para generaciónautomática de código desde modelos definidos con lenguajes de propósito general, ta-les como UML. Otras combinan el MDD con los DSL, pudiendo utilizar lenguajes demodelado diseñados por uno mismo. También existen herramientas que ofrecen ambasposibilidades.

En este proyecto se plantea analizar una serie de herramientas, tanto comerciales comode licencia libre, con el objetivo de conocer las capacidades que ofrecen, y comparar lasventajas y desventajas de cada una de ellas.

También se analiza cómo se puede introducir la variabilidad en el MDD utilizandoalguna de las herramientas.

Variabilidad

La combinación del MDD con los SPL introduce la variabilidad a los modelos, pu-diendo tener familias de productos representados por modelos. Otro de los objetivos quese persigue en este proyecto es analizar cómo se puede introducir la variabilidad en otroselementos del MDD, tales como metamodelos o transformaciones de modelos.

1.3. Metodología

A continuación se explica la metodología que se ha seguido a la hora de realizar esteproyecto.

El proyecto empezó a finales de octubre de 2008. En una primera reunión entre elalumno y el tutor de la empresa se hizo una planificación de cómo transcurriría el pro-yecto, marcando los objetivos y las tareas a realizar durante el transcurso del mismo. Se

3


acordó realizar una reunión de seguimiento del proyecto cada semana con el tutor, paraanalizar el trabajo realizado y los compromisos a adquirir para la siguiente semana. Trascada reunión se redactaba su correspondiente acta.

El primer trabajo tras iniciar el proyecto fue el de documentación. Dada la novedad delos conceptos de DSL y MDD para el alumno, el trabajo de las primeras semanas consis-tió en buscar documentación y definiciones de los distintos conceptos dentro del MDD.También se leyeron diversos artículos con el fin de contextualizar adecuadamente el pro-yecto. La lectura de artículos y trabajos de investigación ha sido una constante durantetodo el proyecto.

La lectura acaparó gran parte del tiempo durante el inicio del proyecto (aunque nohaya sido poco el tiempo que se le ha dedicado posteriormente), con el fin de, por unaparte entender bien todos los conceptos que se trabajarían durante el proyecto, y por otra,ver el trabajo que se había realizado hasta el momento en el tema, y cuál era el estado delarte.

A continuación se procedió a la instalación de diversas herramientas y a aprender autilizarlas realizando pequeños ejemplos con ellas. Las primeras herramientas utilizadasfueron MetaEdit+ y Eclipse Modeling Framework (EMF) para diseñar DSL de modelado.Posteriormente se utilizaron MDWorkbench, ATL y MOFScript, todas ellas herramientaspara definir transformaciones de modelos. Por último, se ha utilizado la herramienta demodelado IBM Telelogic Rhapsody, la cual ofrece un potente entorno para el modeladode sistemas o software, y que junto con su complemento RulesComposer para la trans-formación de modelos facilita la generación automática de código desde los modelosdefinidos. Los primeros ejemplos realizados con las herramientas fueron ejemplos peque-ños, normalmente sacados de sus propios tutoriales, con el fin de aprender cómo usarlas.Posteriormente, se han venido realizando ejemplos más grandes, con el fin de analizar lasposibilidades que ofrece cada herramienta y hacer un análisis más detallado de cada unade ellas para obtener sus capacidades y limitaciones de uso.

Sin dejar a un lado el análisis de las diferentes herramientas, durante los últimos me-ses del proyecto se ha introducido una parte de investigación. La base de la investigaciónha sido la introducción de la variabilidad en el MDD. Se ha analizado cómo puede afectarla variabilidad a los distintos elementos que forman parte del MDD, especialmente có-mo pueden ser refinados, y se han escrito varios artículos sobre ello que se especificaránen su correspondiente capítulo. En esta parte del proyecto, ha sido el tutor quien ha pro-puesto las ideas a trabajar, mientras que el alumno ha elaborado ejemplos para ver quéherramientas usar y cómo avanzar en el tema.

Tal y como se había previsto en la planificación del proyecto, éste acaba con la redac-

4

1.4. ORGANIZACIÓN DEL DOCUMENTO

ción de este documento y su respectiva presentación.

1.4. Organización del documento

El resto del documento se organiza de la siguiente forma.El capítulo 2 es el documento de objetivos del proyecto, donde se indican los objetivos

principales y la planificación del mismo.En el capítulo 3 se ofrece una definición de los conceptos básicos para situar el proyec-

to. En una primera sección dentro de este capítulo se introducen los sistemas embebidos.Después se hace una introducción a la ingeniería de software, donde se presentan algunosconceptos que ayudarán en la comprensión del trabajo.

En el capítulo 4 se introducen los DSL. El capítulo está dividido en tres secciones.Primero se explica el estado del arte. A continuación se detalla qué herramientas se hananalizado y cómo se trabaja con ellas. Seguidamente, se hace una comparativa de losdistintos aspectos de las herramientas y para finalizar se muestra un caso de estudio conun ejemplo.

En el siguiente capítulo se hace una introducción al MDD. Este cuarto capítulo siguela misma estructura que el anterior: conceptos básicos, herramientas, caso de estudio.

En el capítulo 6 se muestra la parte de investigación de este proyecto, es decir, la in-troducción de la variabilidad en el MDD. Este capítulo está basado en uno de los artículosescritos como resultado de la investigación y en él se presenta una solución para aplicarla variabilidad a las transformaciones de modelo a texto.

En el capítulo 7 se ofrecen detalles sobre la gestión del proyecto, donde se comparanlas alteraciones sufridas en la planificación respecto al plan inicial detallado en el capítulo2.

El capítulo 8 recoge las contribuciones que se han realizado en este trabajo, las prin-cipales conclusiones que se han sacado durante la ejecución del proyecto y las líneas detrabajo futuro.

5


6

Capítulo 2

Documento de Objetivos del Proyecto

2.1. Descripción

Continuamente se buscan nuevas técnicas para el desarrollo de software con el obje-tivo de aumentar la productividad. En este proyecto se analiza cómo pueden ayudar loslenguajes específicos de dominio (DSL) y el desarrollo dirigido por modelos (MDD) enel cumplimiento de ese objetivo.

Los DSL no son muy utilizados actualmente en la industria del software. Aún asíexisten cada vez más casos exitosos de su utilización en el desarrollo de software. En esteproyecto se analizará cuál es el estado de arte, cómo se han utilizado, los beneficios queaportan, y sus limitaciones. También se utilizarán varias herramientas para trabajar conDSL con el objetivo de analizar sus capacidades y limitaciones.

Para analizar la viabilidad de la utilización de DSL en el contexto del proyecto, seimplementará un prototipo demostrador. Para realizar el prototipo demostrador se utilizaráun DSL ya existente o se definirá uno, y se definirán transformaciones del DSL a códigode implementación, con los cuales el código será generado automáticamente.

2.2. Objetivos

Los objetivos que se plantean en este proyecto son los siguientes:

Analizar el estado del arte de los DSL y del MDD. Analizar el trabajo que se harealizado en estos áreas y cómo se han utilizado para desarrollar software. Estudiarsus ventajas y desventajas.

Analizar las herramientas disponibles para trabajar con DSL y MDD para estudiar

7

CAPÍTULO 2. DOCUMENTO DE OBJETIVOS DEL PROYECTO

su utilización, sus capacidades y sus limitaciones.

Desarrollar un prototipo demostrador utilizando los DSL y MDD.

2.3. Alcance: entregas

A continuación se detallan las entregas referentes a las diferentes tareas que se irándesarrollando durante la realización del proyecto:

Entregable: planificación del proyecto

Tipo: documento Word

Fecha: 5/11/2008

Entregable: informe de seguimiento del proyecto


Fecha: cada cuatro semanas

Entregable: documento de resultado del análisis del estado de arte


Fecha: 28/01/2009

Entregable: análisis de herramientas


Fecha: 25/03/09

Entregable: comparativa de herramientas


Fecha: 25/03/2009

Entregable: presentación de las ideas del prototipo

Tipo: presentación PPT

Fecha: 18/12/2008

Entregable: código y modelos del prototipo

Tipo: código fuente y modelos de diseño

Fecha: 1/06/2009

8

2.4. DIAGRAMA EDT

Entregable: memoria y presentación

Tipo: documento PDF y presentación PPT

Fecha: 15/07/2009

2.4. Diagrama EDT

Figura 2.1: Diagrama EDT inicial

2.5. Asignación de recursos

Tabla 2.1: Asignación de recursos en la planificación inicial

9


2.6. Tareas

2.6.1. Gestión

Documento de objetivos del proyecto: realización de la planificación del proyecto.

Reuniones: reuniones semanales con el tutor de la empresa.

Seguimiento: análisis del estado del proyecto y posibles replanificaciones.

2.6.2. Estudio de estado del arte

Análisis de DSL: concepto, diferentes tipos, paradigmas, DSM, MDD.

Estudio de mercado de herramientas existentes: estudio de mercado de herra-mientas existentes para trabajar con DSL.

2.6.3. Análisis de herramientas

Instalar herramientas: instalación de las distintas herramientas a analizar.

Realizar ejemplos existentes: realización de ejemplos ya existentes para aprendera utilizar las herramientas.

Definir ejemplos nuevos: definición de un ejemplo para analizar las capacidades ylimitaciones de las herramientas.

2.6.4. Desarrollo de prototipo

Concepción: definición de la idea.

Captura de requisitos: requisitos del prototipo demostrador.

Diseño: diseño del prototipo.

Implementación: definición de transformaciones de DSL a código.

Testeo: testeo del funcionamiento del prototipo.

10

2.7. DIAGRAMA DE GANTT

2.6.5. Cierre

Memoria: realización del documento que se entregará como resultado final delproyecto.

Presentación: realización de la presentación que se utilizará en la defensa del pro-yecto.

2.7. Diagrama de Gantt

Figura 2.2: Diagrama de Gantt inicial

2.8. Factores de riesgo

A continuación se muestran los posibles factores de riesgo que se preveen durante larealización del proyecto y las respuestas que se darán si se producen.

Que la herramienta no provea las capacidades esperadas para la realización delprototipo demostrador.

Probabilidad: baja

Acciones a llevar a cabo: analizar la posibilidad de usar otra herramienta parahacer el prototipo o cambiar la definición del prototipo

Que los requisitos del prototipo no sean completos.

Probabilidad: media

Acciones a llevar a cabo: definir el prototipo más exhaustivamente hasta lograrunos requisitos completos

11


Que haya demasiada carga de trabajo y que no de tiempo a finalizar las tareas

Probabilidad: media

Acciones a llevar a cabo: ajustar el alcance del proyecto al tiempo disponible

2.9. Método de trabajo

2.9.1. Miembros del equipo del proyecto

El equipo del proyecto constará de tres personas: director, tutor en la empresa yalumno. El contacto entre el alumno y el tutor de la empresa sera directo o por correoelectrónico. El contacto entre alumno y director, o tutor de la empresa y director se reali-zará por correo electrónico. Los miembros del proyecto son los siguientes:

Director del proyecto: Oscar Diaz ([email protected])

Tutor en la empresa: Salvador Trujillo ([email protected])

Alumno: Ander Zubizarreta ([email protected])

2.9.2. Reuniones

Cada miércoles se realizará una reunión entre el tutor de la empresa y el alumno con elobjetivo de analizar el trabajo realizado durante la semana y definir nuevos compromisos.En caso de que no sea posible la realización de una reunión en la fecha indicada, éstapodrá ser cambiada a otra fecha cercana. Después de cada reunión el alumno redactará surespectivo acta.

2.9.3. Seguimiento del proyecto.

Cada cuatro semanas se realizará una reunión de seguimiento del proyecto entre elalumno y el tutor de la empresa con el objetivo de analizar el estado del proyecto y definiruna replanificación si fuese necesario. Estas reuniones darán como resultado documentosde seguimiento.

12

Capítulo 3

Conceptos básicos

En este capítulo se introducen algunos conceptos básicos que ayudarán a situarnos enel proyecto. En la primera sección se hace una introducción a los sistemas embebidos. Enla segunda se introduce brevemente la ingeniería de software, describiendo dentro de sucontexto algunos conceptos que facilitarán la comprensión de este trabajo.

3.1. Sistemas embebidos

Los microprocesadores han ido evolucionando con el tiempo. Existen microprocesa-dores cada vez más pequeños y baratos. Esto ha hecho que hayan sido “embebidos” enuna gran gama de productos que usamos a diario, con la intención de hacerlos “inteligen-tes” (Simon, 1999). Productos tales como relojes digitales, teléfonos móviles, ascensores,equipamiento de control industrial etc. son controlados mediante estos microprocesadoresy su software. Se suele llamar sistema embebido a cualquier sistema de computación queesté “escondido” dentro de otro producto, es decir, que sea una parte integral del sistemaentero.

3.1.1. Características de los sistemas embebidos

A diferencia de los ordenadores personales, que pueden usarse para una gran variedadde tareas dependiendo de su programación, los sistemas embebidos suelen ser normal-mente sistemas creados para un propósito específico, con el objetivo de cumplir con al-gunas funciones concretas, por lo que suelen ser normalmente sistemas preprogramados.Pueden ser sistemas muy simples, con un solo microcontrolador, o sistemas grandes ycomplejos que pueden estar compuestos de varias unidades de procesamiento, periféricosy redes, pudiendo ser encontrados tanto en un reloj digital de pulsera, como en el sistema

13

CAPÍTULO 3. CONCEPTOS BÁSICOS

de control de una central nuclear. A la hora de trabajar con sistemas embebidos encon-tramos características propias que no son compartidas con los ordenadores personales oservidores. Estas son algunas de sus principales características:

Los sistemas embebidos se construyen para un propósito específico, por lo quenormalmente ofrecen un mayor rendimiento en las tareas para las que han sidodiseñados.

Muchas veces pueden requerir restricciones de tiempo real. Es decir, en determi-nadas situaciones deben reaccionar en un intervalo de tiempo definido, ya sea porcuestiones de seguridad o de usabilidad.

Los recursos de hardware son normalmente limitados para reducir costes. Se buscael equilibrio entre el rendimiento y el coste según cuál sea el cometido del sistema.

La interfaz de usuario suele ser normalmente dedicada y puede ser desde nula (sinratón, monitor, teclado...) o muy limitada (LEDs, displays digitales...) en sistemassimples preprogramados para realizar pocas tareas, a conexiones de serie para inter-actuar desde un ordenador personal o hasta complejos sistemas gráficos con panta-llas táctiles. Hoy en día muchos sistemas embebidos permiten interactuar con ellosmediante una interfaz web a través de una conexión de red (e.g. configuración derouters).

Están frecuentemente conectados a ambientes físicos mediante sensores para reco-lectar la información y actuadores para controlarla.

Deben ser eficientes, tanto energéticamente como en el tamaño de código a ejecutar.

Los sistemas embebidos son muchas veces creados para estar trabajando continua-mente durante años, por lo que tienen que ser confiables. La confiabilidad reúne lossiguientes aspectos de un sistema (Marwedel, 2006):

1. Fiabilidad: Probabilidad de que el sistema trabaje correctamente y no falle.

2. Mantenibilidad: Probabilidad de que el sistema vuelva a trabajar correctamen-te en un intervalo dado de tiempo después de un fallo.

3. Disponibilidad: Probabilidad de que el sistema esté funcionando en un mo-mento dado.

4. Seguridad física: Que un fallo en el sistema no cause ningún daño.

14

3.1. SISTEMAS EMBEBIDOS

Figura 3.1: Sistema embebido en un aerogenerador

5. Seguridad informática: Confidencialidad y autenticación de las comunicacio-nes.

No todos los sistemas embebidos cumplen todas las características anteriormente comen-tadas, ya que éstas pueden variar bastante dependiendo de la utilización que se le va a daral sistema. Por ejemplo en el sistema de control de una central nuclear lo más importantepuede ser tener un sistema confiable, aunque ésto requiera utilizar un sistema menos efi-ciente. En cambio, en un teléfono móvil un sistema eficiente energéticamente puede sermás importante.

En Beuche (2003) se describen también las características de este tipo de sistemas;se muestra cuales son las diferencias entre el software para sistemas embebidos y noembebidos, y cuáles son los requisitos a seguir a la hora de desarrollar software parasistemas embebidos.

3.1.2. Ejemplo de sistema embebido

A continuación se muestra un ejemplo de sistema embebido imaginario y simplifica-do, pero basado en un caso real. Durante el proyecto se ha utilizado como ejemplo unsistema para el control de un aerogenerador, es decir, un sistema embebido en un molinode viento que se encarga de controlarlo.

La figura 3.1 muestra los principales elementos por los que se compone un aerogene-rador. Como se puede apreciar, el sistema de control va insertado dentro del propio molinoy forma parte del aerogenerador.

15


Figura 3.2: Fases en el desarrollo de software

Un aerogenerador puede tener varios elementos que tienen que ser controlados y mo-nitorizados. En este caso el sistema hace uso de distintos sensores colocados en distintospuntos del aerogenerador para recavar información del ambiente, como pueden ser la tem-peratura, la velocidad, etc. Entre los requisitos que tiene que cumplir el sistema embebidoen el aerogenerador están el de que tiene que ser un sistema en tiempo real y que tieneque estar trabajando continuamente los 24 horas al día, los 7 días de la semana.

3.2. Ingeniería de software

El mundo que nos rodea depende cada vez más de ordenadores y de software quelos controle. Grandes infraestructuras, sistema financiero y procesos industriales estáncomputerizados en su mayor parte. Por eso, la producción y el mantenimiento de softwarede calidad a un coste reducido adquiere gran importancia.

La ingeniería de software es la disciplina que trata todos los aspectos relacionadoscon la producción de software, desde las primeras etapas de especificación, hasta el man-tenimiento una vez puesto en marcha el sistema (Sommerville, 2007). A fin de mejorarla productividad durante el desarrollo y la calidad del software, desde hace tiempo se haintentado encontrar metodologías que sean sistemáticas, predecibles y repetibles para laproducción de software.

3.2.1. Fases en el desarrollo de software

El proceso de desarrollo de software se divide normalmente en las siguientes fases:

16

3.2. INGENIERÍA DE SOFTWARE

Análisis de requisitos: La primera etapa del software es la extracción de requisi-tos. Partiendo de los requisitos especificados por el cliente y evitando que hayarequisitos incompletos, ambiguos o contradictorios se obtiene como resultado laEspecificación de los Requisitos del Sistema.

Especificación: Es la tarea de describir el comportamiento esperado en el softwareque va a ser desarrollado.

Diseño y arquitectura: En esta etapa se determina cómo funcionará el sistema deforma general y las funciones que realizará.

Programación: Es la etapa donde se implementa el código en un lenguaje de pro-gramación, a partir del diseño

Prueba: Consiste en comprobar que el software realiza correctamente las tareasindicadas en la especificación del problema.

Documentación: Consiste en la documentación del software, del proceso de desa-rrollo y de la gestión del proyecto, con el fin de facilitar la inserción de correcciones,usabilidad, mantenimiento futuro o ampliaciones al sistema.

Mantenimiento: Una vez finalizado el producto de software es importante el mante-nimiento. Éste puede consistir en corregir errores o extender el sistema para cumplirnuevos requisitos.

Dependiendo del paradigma que se siga, estas fases pueden seguir una orden secuencial ono. Por ejemplo el desarrollo en cascada define el orden estrictamente secuencial, dondeuna fase no empezará hasta que se haya terminado la anterior (ver Figura 3.2). En cambio,en el desarrollo en espiral se vuelve una y otra vez a la misma fase.

3.2.2. Automatización del desarrollo

Desde los inicios de la ingeniería de software se ha tratado de automatizar en la medidade lo posible la producción de software. Con este objetivo se han utilizado diferentesmétodos, paradigmas y herramientas.

CASE

CASE es el acrónimo de Computer Aided Software Engineering o Ingeniería de Soft-

ware Asistida por Ordenador y se ha utilizado durante años para referirse a las herramien-tas utilizadas en la ingeniería de software. Existen programas para ayudar en las distintas

17


etapas del desarrollo de software, tanto en el análisis de requisitos, diseño y modelado delsistema, como en la fase de documentación, prueba y mantenimiento con herramientasde generación de documentación, testeo o debugging. Cada vez más herramientas CA-SE incluyen además generadores que pueden generar, al menos en parte, el código deimplementación a partir de los modelos.

MDD

MDD es el acrónimo de Model Driven Development o Desarrollo de Software Diri-

gido por Modelos. Éste es un paradigma emergente, donde el desarrollo del software secentra en los modelos con el objetivo de elevar el nivel de abstracción y automatizar la ge-neración del código de implementación. Aunque en el Capítulo 5 se profundiza sobre esteparadigma, a continuación se hace una breve exposición de los elementos que participanen él.

Modelos: Los modelos son utilizados para representar un sistema. Se utilizan paraello lenguajes de modelado que normalmente son gráficos, y que pueden ser tanto depropósito general como específicos de dominio. Los elementos que pueden ser definidosen un modelo se especifican en el metamodelo.

Metamodelos: Un metamodelo es el modelo de un lenguaje de modelado. Los len-guajes de modelado se definen utilizando metamodelos, en los cuales se especifica quéelementos puede tener un modelo, sus atributos, relaciones, restricciones etc. Es decir, unmetamodelo define la sintaxis abstracta de un lenguaje de modelado.

Transformaciones de modelos: Las transformaciones de modelos definen transforma-ciones de unos modelos en otros, o generar código desde los modelos. Dependiendo dela salida de la transformación éstas pueden ser transformaciones de modelo a modelo, ode modelo a texto. Con una transformación de modelo a modelo se obtiene un modelodistinto del mismo sistema. Con una transformación de modelo a texto, en cambio, lasalida obtenida es texto, y normalmente suele usarse para generar código de implementa-ción. Las transformaciones se definen a nivel de metamodelado, mapeando los elementosdefinidos en él.

18

3.2. INGENIERÍA DE SOFTWARE

Figura 3.3: Línea de Producto Software

UML

Unified Modeling Language (UML) es el lenguaje de modelado propuesto por el Ob-

ject Management Group (OMG) para el modelado de sistemas de software (OMG, 2005).UML ofrece 13 tipos de diagramas divididos en dos grupos para modelar un sistema desoftware. Por una parte están los diagramas de estructura, que son utilizadas para repre-sentar la estructura estática del sistema. Entre ellos el diagrama de clases es uno de losmás utilizados, sobre todo cuando se trabaja en programación orientada a objetos. Por otraparte están los diagramas de comportamiento que son utilizados para describir el compor-tamiento dinámico del sistema. Entre ellos se encuentran el diagrama de casos de uso, deestados y de secuencia.

SPL

SPL es el acrónimo de Software Product Lines o Líneas de Producto Software. LasSPL proponen un sistema de producción basado en la reutilización de componentes enun determinado dominio. Ofrecen un paradigma para la creación de una familia de pro-ductos de software, donde se definen por un lado partes comunes de todos lo productos ypor otro las distintas variantes. Los distintos productos finales se consiguen mediante lacomposición de diferentes componentes.

Una Linea de Producto Software puede ser definido como una colección de sistemasde software enmarcados en un dominio o segmento de mercado específico que compartenvarias características (Clements & Northrop, 2001; Pohl et al., 2006).

La Figura 3.3 ilustra la idea de las Líneas de Producto Software, donde existen varioscomponentes que se componen dependiendo de las decisiones de producto, dando comoresultado diferentes productos finales (Krueger, 2008).

Las SPL introducen la variabilidad en el desarrollo del software. Se profundiza sobreeste tema en el Capítulo 6.

19


3.2.3. Ingeniería de software vs. ingeniería de sistemas

La ingeniería de sistemas es la disciplina que engloba todos los aspectos del desarrolloy evolución de un sistema complejo, donde el software puede jugar un rol importante.La ingeniería de sistemas engloba aparte de la ingeniería de software, el desarrollo delhardware y la puesta en marcha de todo el sistema. El trabajo de un ingeniero de sistemasconsiste en especificar el sistema, definir su arquitectura general e integrar las distintaspartes del sistema, sin participar en las partes específicas del sistema como pueden ser elhardware o software (Sommerville, 2007).

La ingeniería de sistemas es una disciplina más antigua que la ingeniería de software.Pero con el incremento del uso del software en distintos sistemas, muchas veces se usantécnicas parecidas para ambas disciplinas. Ejemplo de ello es SysML (OMG, 2008a), unlenguaje de modelado de sistemas, creado como perfil de UML que se usa para modelarsoftware.

20

Capítulo 4

Lenguajes Específicos de Dominio

4.1. Estado del arte

4.1.1. Introducción a los DSL

Dentro del mundo de la informática los lenguajes son clasificados en distintas catego-rías. Por una parte se hace la distinción entre lenguajes de programación y lenguajes demodelado, por ejemplo Java y UML. La frontera entre estas dos categorías es cada vezmás borrosa debido a que muchas veces los programas son tratados como modelos, o losmodelos pueden ser ejecutables. Por otra parte, se distingue entre lenguajes de propósi-to general y lenguajes específicos de dominio, también llamados DSL, y en los que secentrará este capítulo. Tanto UML como Java pueden ser algunos ejemplos de la primeracategoría, mientras que SQL o HTML pueden ser ejemplos de DSL. Aún así, al igual queen la anterior clasificación, en este caso la frontera tampoco es tan clara ya que existenlenguajes específicos de dominio que han evolucionado hasta convertirse en lenguajes depropósito general. Tanto los lenguajes de propósito general, como los específicos de do-minio pueden clasificarse dentro de otras categorías, dependiendo de que sean gráficos otextuales, el paradigma que sigan, o sean imperativos o declarativos.

Aunque el de los DSL no sea un concepto nuevo, ha sido en la última década cuandoha aumentado el interés por ellos, gracias sobre todo al surgimiento del paradigma dedesarrollo dirigido por modelos, donde se trabaja muchas veces con modelos específicosde dominio, y que es donde se centrará sobre todo este trabajo.

21

CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO

<html><body>

<h1>My F i r s t Heading< / h1>

<p>My f i r s t p a r a g r a p h . < / p>

< / body>< / html>

(a)

(b)

Figura 4.1: Ejemplos de DSL. (a) textual; (b) gráfico

Ventajas y desventajas

A diferencia de los lenguajes de propósito general, que son diseñados para ser utili-zados en una gran variedad de tareas, los DSL son diseñados para ser útiles en un deter-minado area o dominio (e.g. SQL en bases de datos). Los DSL son normalmente menoscompletos, pero más expresivos en su dominio. Al usar el lenguaje términos propios deldominio para el que ha sido diseñado, se obtiene un mayor nivel de abstracción, facili-tando la expresión de problemas o soluciones más claramente que con otros lenguajes depropósito general. Esto facilita su aprendizaje por parte de las personas que trabajan en elámbito del dominio.

La popularidad de los DSL va incrementando gracias al auge del modelado específicode dominio, ya que sus ventajas son numerosas. La utilización de los DSL ayuda a mejo-rar la calidad, productividad, fiabilidad, mantenibilidad, portabilidad y reutilización. Noobstante, no todos son ventajas, sobre todo a la hora de diseñar el lenguaje, ya que esta-blecer el alcance apropiado del lenguaje puede ser una tarea difícil y requiere un análisismuy profundo del dominio, al que hay que sumarle el coste de diseño, implementación ymantenimiento.

DSL gráficos vs DSL textuales

Como ya se ha comentado, los lenguajes específicos de dominio pueden ser tantográficos como textuales. Ejemplos de DSL textuales pueden ser SQL para la interaccióncon bases de datos, o HTML para visualización de páginas web, mostrado en la Figura4.1a. En este ejemplo se puede ver como se define la visualización de un título o de unpárrafo en un documento HTML (W3C, 1999).

22

4.1. ESTADO DEL ARTE

Figura 4.2: Diagrama de tres niveles

La utilización de DSL gráficos va muy unido al desarrollo de software dirigido pormodelos. Normalmente los DSL gráficos suelen ser lenguajes de modelado, desde los quese puede generar código de implementación o documentación, y que se analizará más afondo en el siguiente capítulo. La utilización de lenguajes de modelado específicos dedominio permite elevar aún más el nivel de abstracción. Como ejemplo de DSL gráficosse puede comentar por ejemplo SPEM (Software Process Engineering Meta-Model), quees un lenguaje para la definición de procesos de ingeniería de software (OMG, 2008b). Enla Figura 4.1b se puede ver un ejemplo de la definición de un proceso mediante SPEM.

4.1.2. Diseño de DSL

El diseño de lenguajes específicos de dominio requiere aparte de conocimientos rela-cionados con el desarrollo de lenguajes, un profundo conocimiento del dominio para elque se va a diseñar el lenguaje. Esto supone un gran esfuerzo, por lo que es importantesaber cuándo conviene utilizar un DSL y cuándo no. Además, no hay ninguna metodolo-gía definida para el diseño de estos lenguajes, aunque sí que se ha escrito sobre algunaspropuestas de pasos a seguir y buenas prácticas (Mernik et al., 2005; Völter, 2008).

Mernik et al. (2005) diferencian cinco fases en el proceso de desarrollo de un DSL:decisión, análisis, diseño, implementación, y puesta en marcha. Este proceso no tieneporque ser secuencial, ya que, por ejemplo, la decisión de crear un DSL puede ser conse-cuencia de un análisis previo.

Decisión: Tomar la decisión de crear un DSL no es una tarea fácil, y puede dependerde muchos factores. Un DSL se crea con la intencionalidad de mejorar la producti-vidad, ahorrando costes en el desarrollo y mantenimiento de software, pero su usono está siempre justificado, ya que el coste de la creación del DSL puede ser mayorque el ahorro que supondrá en un futuro. La adopción de un DSL ya existente puede

23


resultar una opción más económica, por lo que es conveniente buscar alternativasantes de empezar el diseño de un DSL desde cero.

Análisis: En la fase de análisis se identifica el dominio del problema y se obtiene elconocimiento necesario desde diversas fuentes, como pueden ser documentos téc-nicos, conocimiento de los expertos del dominio, código ya existente en lenguajesde propósito general, etc. Como resultado del análisis se obtiene una terminologíaespecífica del dominio y una semántica expresada de manera más o menos abstrac-ta.

Diseño: El diseño de un DSL puede hacerse partiendo desde cero, pero esto puederesultar una tarea extremadamente difícil. Una opción más fácil es la de partir de unlenguaje ya existente, ya sea utilizando parte de sus características, restringiéndolopara hacerlo más simple, o extendiéndolo para añadirle nuevas características. Cua-drado et al. (2006) y Hudak (1996) presentan algunos ejemplos de DSL embebidosen otros lenguajes de propósito general.

Implementación: La implementación de un DSL como si fuese un lenguaje de pro-pósito general puede ser algo muy costoso. En este trabajo la implementación seha realizado mediante técnicas de metamodelado, es decir, creando modelos dellenguaje.

Puesta en marcha: Para la puesta en marcha de un DSL después de realizar lospasos previos es muy importante facilitar al usuario la implantación del DSL en suentorno de desarrollo.

Como se ha comentado, durante el transcurso de este proyecto se han utilizado las he-rramientas de metamodelado para crear los DSL. En el siguiente capítulo, dedicado aldesarrollo dirigido por modelos, se profundizará más en el concepto de metamodelo, pe-ro éste es básicamente un modelo del DSL. En un metamodelo se definen los elementosque puede tener un DSL o modelo, y cómo se relacionan entre ellos, es decir, una sinta-xis abstracta. El metamodelo es definido utilizando los elementos que han sido definidosanteriormente en el meta-metamodelo. Los elementos comentados se representan en undiagrama de tres niveles, tal y como muestra la Figura 4.2 (Kurtev et al., 2006). Al diseñarun DSL se trabaja en el nivel M2, es decir, hay que crear el metamodelo. El usuario finaldel DSL trabajará en el nivel M1.

24

4.1. ESTADO DEL ARTE

Figura 4.3: DSL para desarrollar aplicaciones para Nokia

4.1.3. Uso de DSL en la industria

Aunque la implantación de los DSL en la industria no es muy grande, existen ejemplosexitosos de su utilización (DSM-Forum, 2008). Un ejemplo de uso de DSL en empresases el de Nokia, compañía dedicada a los aparatos de telefonía móvil (MetaCase, 2007).

Ejemplo: Nokia

Con el aumento de usuarios de telefonía móvil en los últimos años, éste se ha conver-tido en un sector realmente competitivo. Los aparatos de telefonía móvil continuamenteincluyen nuevas características, y el software que lleva el aparato se ha convertido en unaspecto crítico desde el punto de vista del consumidor, ya que es el que proporcionarálas distintas características del teléfono. Para los fabricantes, el tiempo de salida al mer-cado es sumamente importante, ya que el lanzamiento de un producto un mes antes queel competidor se puede traducir en grandes cantidades de ingresos. En este sentido, laproductividad en el proceso de desarrollo es vital.

Con el objetivo de incrementar su competitividad, Nokia buscaba un método paramejorar la productividad aplicando las siguientes estrategias:

Trabajar a un mayor nivel de abstracción, centrándose en el diseño en vez de en laimplementación.

25


Trabajar en términos del dominio, permitiendo a los desarrolladores un aprendizajemas rápido de las herramientas de desarrollo, gracias a su familiarización con eldominio.

Generación automática de código desde los diseños.

La solución implementada por Nokia ha sido el de crear su propio DSL de modeladoy definir generadores de código y documentación que automaticen el proceso de imple-mentación. Para ello, Nokia ha utilizado la herramienta MetaEdit+, que se presenta enla siguiente sección. Esta solución permite a los desarrolladores de Nokia trabajar direc-tamente con conceptos propios del dominio en los modelos que diseñan, sin tener querelacionar cada concepto del dominio con un elemento del lenguaje de modelado comoocurriría al usar UML. La Figura 4.3 muestra un modelo definido con un DSL para desa-rrollar aplicaciones para teléfonos Nokia.

La aplicación de los DSL ha supuesto importantes beneficios a esta compañia entrelos que se encuentran los siguientes:

Disminución de tiempo de desarrollo y aumento de productividad por 10 veces.

Posibilidad de centrarse en la funcionalidad del software a producir, y no en laimplementación.

Generación automática desde los modelos casi al 100%.

Generación automática de documentación.

Reducción de costes de formación para nuevos desarrolladores de 6 meses a 2 se-manas, gracias al nivel de abstracción y la familiaridad con el dominio.

Viendo los grandes beneficios en la producción que ha traído a varias compañias la incor-poración de los DSL, es previsible que su utilización vaya en aumento los próximos años,ligado probablemente a la utilización del MDD.

4.2. Herramientas

Existen varias herramientas para la creación de DSL. En este trabajo se han analizadodos de ellos, que permiten la creación de lenguajes específicos de modelado medianteel metamodelado. La primera herramienta utilizada ha sido MetaEdit+, una herramien-ta comercial que facilita el diseño de DSL gráficos. La otra ha sido Eclipse Modeling

26

4.2. HERRAMIENTAS

MetaEdit+ Eclipse EMFM3 GOPPRR EcoreM2 DSL definido con GOPPR DSL definido con EcoreM1 Modelo definido con DSL Modelo definido con DSL

Tabla 4.1: Elementos del diagrama de 3 niveles en cada herramienta

Figura 4.4: Metamodelado utilizando GOPPRR en MetaEdit+

Framework (EMF), herramienta libre, integrada en Eclipse, que ofrece un entorno paratrabajar con modelos. Ambas herramientas permiten definir los metamodelos utilizandoun lenguaje de metamodelado o meta-metamodelo.

En este capítulo solo se analiza parte de las herramientas, ya que éstas ofrecen másfuciones aparte del diseño de DSL. Se hace una breve descripción de las herramientas y semuestran sus características más importantes relacionadas con el diseño de lenguajes demodelado. Las ventajas y limitaciones de cada herramienta se detallan en el siguiente ca-pítulo, dedicado al MDD, donde se completa el análisis de las herramientas. Para finalizaresta sección se hace una breve comparativa de ambas herramientas.

27


Figura 4.5: Modelado con MetaEdit+

4.2.1. MetaEdit+

Descripción

MetaEdit+ es una herramienta comercial desarrollada por MetaCase1. Esta herramien-ta ofrece un entorno para diseñar lenguajes de modelado específicos de dominio, con loscuales se pueden definir modelos y generar código de implementación a partir de ellos.Este capítulo se centra sólo en la parte de diseño de DSL que ofrece esta herramienta,dejando la parte de la generación de código para el siguiente capítulo.

Características

MetaEdit+ permite definir gráficamente y de manera fácil un DSL de modelado. Dis-pone para ello de su propio lenguaje de metamodelado llamado GOPPRR (Graph, Object,Property, Port, Relationship, Role), que engloba todos los tipos de elementos que se pue-den definir en un metamodelo.

Con GOPPRR se definen los diferentes tipos de elementos que podrá tener un modelo,con sus propiedades. Se definen también las relaciones entre los distintos tipos de objetos,y el rol que cada objeto jugará en una relación. También se pueden definir puertos en losobjetos, para especificar la forma que tendrán las relaciones, como por ejemplo de quéparte de un objeto podrá salir una relación.

1http://www.metacase.com/

28

4.2. HERRAMIENTAS

Aparte de la herramienta gráfica para definir metamodelos, MetaEdit+ también ofreceuna herramienta basada en formularios para el mismo propósito. Esta herramienta estáen realidad compuesta por seis herramientas, y permite definir más detalles a la hora dediseñar un DSL:

Object tool: para especificar tipos de objetos del metamodelo

Relationship tool: para indicar los conectores entre tipos de objetos

Role tool: para indicar el rol que juega un determinado tipo de objeto en una deter-minada relación

Port tool: para especificar cómo los tipos de roles se conectan con los tipos deobjetos

Graph tool: para establecer las reglas para la conexión de objetos, relaciones, rolesy puertos definidos

Property tool: para modificar las propiedades de cualquier tipo de elemento y paracrear nuevos tipos de datos

Otra utilidad de la que dispone esta herramienta es la de diseñar figuras propias parautilizarlas en los modelos, pudiéndose crear de esta manera elementos con aparienciarelacionada con lo que representan dentro del dominio, haciendo que el lenguaje diseñadosea más intuitivo y más representativo.

Una vez definido el lenguaje de modelado, podemos exportarlo en formato MetaEdit+

XML Types (MXT). Al exportarlo se crea un fichero con la extensión .mxt, que contie-ne toda la información del lenguaje de modelado definido. Importando el metamodelootra vez a MetaEdit+ podremos utilizar el lenguaje diseñado para crear nuestros modelosespecíficos de dominio.

Los formatos utilizados por MetaEdit+ para exportar metamodelos y modelos sonpropios, por lo que no son compatibles con otras herramientas. Aún así, esta herramientaofrece una API que permite acceder a la información de los modelos definidos en ella.

La Figura 4.4 muestra un metamodelo creado con MetaEdit+ que se describirá másprofundamente más adelante, en la seccíon donde se muestra un caso de estudio. La Fi-gura 4.5 muestra un modelo creado utilizando el lenguaje definido en la Figura 4.4. Ladefinición de modelos es también totalmente gráfica y se realiza con el editor de diagra-mas que para ello ofrece la herramienta.

En resúmen, esta herramienta ofrece un lenguaje de metamodelado, con el que defi-nimos un DSL de modelado que se usará para definir modelos específicos de dominio.

29


Figura 4.6: Metamodelado con Ecore

Estos elementos se muestran en la Tabla 4.1, cada uno en uno de los niveles descritos enla Figura 4.2.

4.2.2. EMF

Descripción

Eclipse Modeling Framework (EMF) es también una herramienta que permite definirDSL de modelado gráficamente. Esta herramienta es el framework que ofrece Eclipsepara el MDD (Eclipse, 2009) y es software libre. Es una herramienta extensible medianteplugins, que ofrece también herramientas para transformaciones de modelos y generaciónde código. En este capítulo nos centramos en la utilidad de esta herramienta para crearDSL de modelado, para el cual dispone del lenguaje de metamodelado llamado Ecore.

Características

El diseño de un DSL de modelado con EMF se puede realizar gráficamente medianteel lenguaje de metamodelado Ecore. La herramienta dispone para ello de un editor dediagramas donde se permite definir diagramas Ecore. Un diagrama Ecore consiste básica-mente en un diagrama de clases, donde se definen mediante clases los tipos de elementosque se podrán incluir en un modelo con el lenguaje creado. También se definen en eldiagrama los atributos que tendrán los distintos elementos, y cómo estarán relacionadosentre ellos.

La Figura 4.6 muestra el metamodelo creado en EMF utilizando ecore, para definir

30

4.2. HERRAMIENTAS

Figura 4.7: Modelado con EMF

un lenguaje de modelado que permita representar sistemas. Este metamodelo se describemás adelante en la sección donde se muestra un caso de estudio.

Aparte de crear los DSL utilizando directamente Ecore, es posible importar DSL dise-ñados en otros lenguajes. Es posible definir un lenguaje utilizando el diagrama de clasesde UML, el lenguaje de metamodelado KM3 o XML Schema, e importarlo a EMF, el cualgenerará automáticamente un modelo Ecore desde el fichero importado.

Una vez definido el metamodelo, EMF ofrece la opción de generar un plugin parapoder utilizar el editor de modelos para definir modelos específicos de dominio. La Figura4.7 muestra el editor de modelos para crear modelos en el lenguaje definido en la Figura4.6. El modelo de la Figura 4.7 conforma al metamodelo de la Figura 4.6.

EMF también ofrece la posibilidad de crear un editor totalmente gáfico con la aparien-cia de los elementos personalizada, al estilo de lo que ofrece MetaEdit+. Dispone para ellode la herramienta Graphical Modeling Framework (GMF). Esta herramienta permite crearun editor de diagramas para el lenguaje de modelado definido con Ecore, especificandopara ello cuáles serán los elementos y relaciones que podrán aparecer en un diagrama delmodelo y cómo.

El formato utilizado para exportar e importar metamodelos y modelos por EMF esXML Metadata Interchange (XMI). XMI (OMG, 2007) es una especificación definidapor MOF y que es también implementada por otras herramientas, lo que hace posible la

31


interoperabilidad de EMF con ellas.

4.2.3. Comparativa

Aunque el lenguaje de metamodelado disponible en cada herramienta sea distinto, elproceso de definición de un lenguaje de modelado es muy similar con ambas herramien-tas. Este proceso trata básicamente de definir elementos, propiedades y relaciones que sepodrán utilizar en un modelo. Se puede decir, en este aspecto, que la facilidad de uso deambas herramientas es más o menos la misma.

Donde existe más diferencia entre las dos herramientas analizadas, es a la hora deutilizar el DSL de modelado diseñado. Mientras MetaEdit+ ofrece automáticamente uneditor gráfico de diagramas para dibujar modelos con el lenguaje diseñado, el editor demodelos ofrecido por EMF no es tan expresivo, ya que en éste el modelo se define enforma de árbol, y no con un diagrama. Como se ha comentado, EMF ofrece la posibilidadde crear un editor de diagramas con GMF para nuestro lenguaje de modelado, pero estatarea puede resultar bastante difícil. Se puede decir que en este aspecto la herramientaMetaEdit+ es más completa y está bastante más lograda. Durante el proyecto hacer unejemplo con MetaEdit+ ha requerido menos tiempo que hacer el mismo ejemplo conEMF.

Una baza a favor de EMF es su extensibilidad, ya que mediante el uso de pluginsse puede obtener una herramienta muy completa con una gran variedad de utilidades.Además dispone de una gran comunidad de desarrolladores y usuarios que mantienenmuy activo el portal de noticias de EMF, donde se puede obtener ayuda de cualquier tipo.También comentar a favor de esta herramienta su compatibilidad con otras herramientastanto libres como comerciales gracias al formato XMI que utiliza.

Otro aspecto a favor de EMF y que ha sido muy útil durante la realización de esteproyecto es la posibilidad de crear DSL desde XML Schema, pudiendo tratar ficherosXML que conforman al Schema como modelos.

Existen trabajos que muestran cómo hacer compatibles las dos herramientas presen-tadas. En Kern (2008) se muestra cómo se pueden intercambiar metamodelos y modelosentre ambas herramientas.

Como conclusión se puede decir que aunque EMF sea una herramienta más completay versátil, la facilidad ofrecida por MetaEdit+ para la definición y utilización de DSL demodelado es superior a la ofrecida por EMF. Es importante analizar para qué se va a usarla herramienta y qué se quiere obtener de ella antes de decidirse por una u otra. Ademásal ser una comercial y la otra libre, el precio y el soporte ofrecido pueden ser también

32

4.3. CASO DE ESTUDIO

factores muy influyentes.

4.3. Caso de estudio

A continuación se muestra un caso de estudio simplificado para ilustrar cómo se defineun DSL de modelado para diseñar un sistema de control de inundaciones. Primero sedescribe el caso de estudio y se presenta cuál es el sistema a definir. A continuación semuestra cómo hemos definido un lenguaje de modelado con MetaEdit+ y otro con EMFpara describir este tipo de sistemas y cómo se han utilizado.

4.3.1. Descripción

Este caso de estudio se basa en un sistema de control de inundaciones. Se trata deun sistema embebido compuesto por varios subsistemas que controlan diferentes partesdel sistema. Este sistema de control de inundaciones recoge información del ambiente, ybasándose en los datos recopilados fija unos niveles de alerta y ejecuta unas determinadasacciones. Por ejemplo, puede disponer de un subsistema que controle las precipitaciones,y que puede indicar un nivel de alerta alto en caso de que sean abundantes.

Un sistema está básicamente compuesto por subsistemas que reciben unos datos deentrada y en base a los cuales generan unos datos de salida o ejecutan alguna acción.Es decir, los elementos principales de un sistema son los subsistemas, las entradas y lassalidas, y son éstos los que serán definidos en los metamodelos.

4.3.2. Definición del lenguaje de modelado

MetaEdit+

La Figura 4.4 muestra el metamodelo definido en MetaEdit+ utilizando su lenguajeGOPPRR. En este metamodelo se han definido los elementos principales que puede tenerun sistema mediante objetos, a los que se les han añadido sus respectivos atributos. Tam-bién se han añadido las diferentes relaciones entre los distintos objetos. En cada relaciónse ha definido a su vez el rol que juega cada objeto que participa en él, y donde se indica lacardinalidad. Como se puede ver, un subsistema estará compuesto de varios subsistemasque tendrán al mismo tiempo varias entradas y salidas.

Para poder utilizar el lenguaje definido primero hay que importarlo a MetaEdit+. Estose puede hacer con el botón Build (ver Figura 4.4), el cual exporta el metamodelo en unfichero MXT y lo importa a MetaEdit+ para poder empezar a usarlo.

33


En este ejemplo, después de definir el metamodelo se ha personalizado la aparienciaque tendrá cada objeto en los modelos con la herramienta Object Tool.

EMF

La Figura 4.6 muestra el metamodelo que se ha definido utilizando Ecore en EMF,donde se han utilizado clases, atributos y relaciones. Se ha definido una clase para cadatipo de elemento que tendrá un modelo que represente un sistema de control de inun-daciones. Como se puede ver, se ha especificado una clase llamada System que tiene unnombre y una descripción. Tal y como se ve en la Figura 4.6, el sistema puede tener variossubsistemas y siempre tendrá al menos uno. Igualmente, un subsistema también tiene unnombre y una descripción, y se compone de varias entradas y salidas, que se definen conlas clases Input y Output respectivamente. A cada una de estas clases se le han definidotres atributos para indicar el nombre, la descripción y el tipo de datos.

Una vez definido el metamodelo con EMF se genera el plugin para crear el editorde modelos que se utilizará para diseñar nuestro tipo de sistemas. Utilizando este editorpodemos definir diferentes sistemas de control de inundaciones.

4.3.3. Utilización del lenguaje de modelado

MetaEdit+

Una vez definido el metamodelo, MetaEdit+ ofrece un editor de diagramas para definirmodelos que conformen al metamodelo. En la Figura 4.5 se muestra el modelo de unsistema de control de inundaciones llamado UK01. Este modelo contiene los elementosdefinidos en el metamodelo, y como se puede apreciar, cada tipo de elemento tiene unaapariencia diferente que hemos definido utilizando el Object Tool.

En el modelo se puede ver que el sistema UK01 está compuesto por tres subsistemasque sirven para controlar la temperatura, las precipitaciones, y el nivel de la presa. Elprimero recibe como entrada los valores de temperatura medidas en tres puntos diferentesy devuelve como salida un nivel de alarma. El segundo hace lo propio, pero en este casorecibe como entrada datos de precipitaciones. El tercero controla la compuerta de la presabasándose en sus estado y en el nivel del agua.

Es posible extender el sistema añadiendo más subsistemas al modelo, o añadiéndolemás entradas o salidas a los subsistemas existentes.

34


EMF

La Figura 4.7 muestra el modelo del sistema de control de inundaciones UK01 defini-do con EMF. Este modelo conforma al metamodelo definido anteriormente. Este modelocontiene los mismos elementos definidos en el modelo de MetaEdit+, es decir, tres sub-sistemas, de temperatura, de precipitaciones y de la presa, cada uno con sus entradas ysalidas.

Este modelo es una instancia particular del metamodelo definido con Ecore. Se pue-den definir tantos sistemas como se quiera, cada uno con sus subsistemas, entradas ysalidas correspondientes. También se puede completar el modelo definido añadiéndolemás subsistemas que controlen otros componentes.

4.3.4. Beneficios obtenidos

Con el estudio de este caso se pueden observar algunos de los beneficios obtenidospor la utilización de un DSL.

Aunque la definición de un DSL requiera esfuerzo y tiempo, se ha conseguido definirun sistema con términos propios del dominio. Eso hace que el nivel de abstracción con-seguido sea mayor, obteniendo como resultado una mayor expresividad en los modelos.Utilizando UML, por ejemplo, podríamos empezar enseguida a definir nuestro sistema,pero tendríamos que asociar cada elemento de UML a un elemento del dominio, y laexpresividad lograda no sería muy alta. En cambio, con la utilización de un DSL repre-sentamos directamente elementos del dominio con elementos del lenguaje.

La expresividad lograda permite reducir el tiempo de formación de nuevos desarrolla-dores, ya que utilizar el DSL se hace más intuitivo. Eso permite, además, reducir el costede desarrollo, que se traduce en un incremento de la productividad. Si añadimos a todo loanterior la generación automática de código, los beneficios pueden ser aún mayores, tal ycomo se verá en el siguiente capítulo.

35


36

Capítulo 5

Desarrollo de Software Dirigido porModelos

El Desarrollo de Software Dirigido por Modelos o Model Driven Development (MDD)es un paradigma de desarrollo de software donde éste se centra en los modelos. En estecapítulo se presentan los principales elementos que participan en el MDD. Seguidamentese analiza una serie de herramientas para la definición de modelos y generación de código,y finalmente se muestra un caso de estudio que se ha realizado durante el proyecto.

5.1. Conceptos básicos

5.1.1. MDD

El MDD es un paradigma donde el desarrollo de software está dirigido por modelosy transformaciones de modelos. Los programas son representados mediante modelos quepueden ser transformados en otros modelos o en texto. En este paradigma los modelos

Figura 5.1: Escenario MDD

37

CAPÍTULO 5. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS

tienen especial importancia, ya que no son solo elementos de diseño o documentación,sino que son también parte de la implementación. Las transformaciones se definen nor-malmente para la generación automática de código desde los modelos. Esta generaciónautomática permite al desarrollador centrarse en definir “qué” hace un sistema de softwa-re en vez de definir “cómo” lo hace, sin entrar en detalles de la implementación ademásde facilitar tareas muy repetitivas a la hora de implementación y evitar la inserción invo-luntaria de errores que se puede producir al escribir código a mano. Además, al trabajar anivel de modelos se consigue un mayor nivel de abstracción.

Según Kontio (2005), los beneficios que ofrece el MDD son el aumento de la pro-ductividad, la reducción de costes, la reducción de tiempo de desarrollo, y una mejoríade la calidad. Generalmente la razón más importante para utilizar el MDD es el aumentode la productividad, por las ventajas económicas que ello supone (OMG, 2009; Herst &Roman, 2003).

Los modelos utilizados en el MDD son mayoritariamente específicos de dominio, porlo que el MDD va muy unido a los DSL. La utilización de modelos durante el diseño delsoftware ha ido creciendo, sobre todo gracias a UML, y los intentos de generar códigoautomáticamente desde los modelos UML también han sido muchos. Pero al ser UML unlenguaje de modelado de propósito general no es fácil definir una transformación generalque valga para generar código de implementación desde cualquier modelo. Existen he-rramientas que lo hacen parcialmente, sobre todo la generación de la estructura o de lasclases, pero no todo el programa. Al definir los programas utilizando modelos específicosdel dominio, es más fácil definir transformaciones que puedan generar el código deseado,además de que el nivel de abstracción se eleva aún más y se consigue mayor expresivi-dad. Los elementos que pueda tener un modelo específico de dominio son definidos pormetamodelos.

La Figura 5.1 muestra los principales elementos que participan en el MDD, que sonlos modelos, metamodelos y transformaciones de modelos.

5.1.2. Modelo

Un modelo es una representación de la realidad mediante abstracciones. Un modelomuestra la representación de un sistema o parte de él con el objetivo de ofrecer infor-mación para un propósito específico (Kurtev, 2005). Para ello se utiliza un lenguaje demodelado, que es definido mediante un metamodelo. En las Figuras 4.5 y 4.7 se mostra-ban dos modelos de un mismo sistema.

38

5.1. CONCEPTOS BÁSICOS

5.1.3. Metamodelo

Un modelo es normalmente una instancia que conforma a un metamodelo (Figura4.2). Un metamodelo es el modelo de un lenguaje de modelado en el que el lenguajees especificado (Kurtev, 2005). En otras palabras, el metamodelo describe los elementosdel dominio, sus relaciones y algunas restricciones básicas. En el Capítulo 4 se mostrabacómo se definía un metamodelo para crear un lenguaje de modelado (ver Figuras 4.4 y4.6).

5.1.4. Transformaciónes de modelos

Las transformaciones de modelos son un elemento clave en el MDD. Una transfor-mación es el proceso de convertir un modelo en otro modelo del mismo sistema (OMG,2003). Generalmente mediante una definción de transformación de modelos se generaun modelo de salida a partir de un modelo de entrada. El modelo de salida puede seruna representación distinta del mismo sistema, o bien la implementación del mismo. Lastransformaciones son definidas mediante lenguajes de transformación, que permiten defi-nir mapeos entre el modelo de entrada y de salida, o entre el modelo de entrada y el textode salida (Kurtev, 2005; Sendall & Kozaczynski, 2003).

Dependiendo de la salida, una transformación de modelos se puede clasificar comotransformación de modelo a modelo, o transformacion de modelo a texto. El primero tomacomo entrada uno o varios modelos que conforman a un metamodelo, y devuelve comosalida uno o varios modelos que conforman al mismo u otro metamodelo. El segundoproduce texto como salida, que puede ser código de implementación, documentación ocualquier otro tipo de texto.

Transformación de modelo a modelo

Las transformaciones de modelo a modelo normalmente definen mapeos entre losmetamodelos de entrada y salida. Los metamodelos de entrada y salida pueden ser losmismos o diferentes, y aplicando la transformación al modelo de entrada se consiguecomo salida otra representación del sistema. Las transformaciones se definen utilizandolenguajes de transformación. Algunos lenguajes son declarativos y permiten mapear ele-mentos del metamodelo de entrada con el de salida. Otros son imperativos y permitengenerar el modelo de salida mediante la utilización de reglas. Muchos lenguajes permi-ten la definición de transformaciones usando ambos estilos de programación. Existen unagran variedad de lenguajes, tanto libres como comerciales, para definir transformaciones

39


entre modelos. Algunos ejemplos son ATL (Bézivin et al., 2003), RubyTL (Cuadradoet al., 2006), y ATC (Sánchez-Barbudo et al., 2008). En este trabajo se han utilizado ATLy MQL que es el lenguaje que utilizan las herramienta comerciales MDWorkbench (So-dius, 2009a) y RulesComposer (Sodius, 2009b).

Transformación de modelo a texto

Las transformaciones de modelo a texto definen el mapeo entre uno o varios metamo-delos de entrada y texto de salida. Normalmente son definidos mediante la combinaciónde reglas y plantillas de texto. Suelen ser utilizados, en general, para la generación au-tomática de código de implementación a partir de un modelo de entrada, pero tambiénpueden ser utilizados para generar documentación a base de la información que ofreceel modelo, o para generar cualquier otro tipo de texto. Los lenguajes de transformaciónde modelo a texto analizados durante el proyecto han sido MERL utilizada por MetaE-dit+ (MetaCase, 2009), MOFScript (SINTEF, 2009) y TGL, éste ultimo utilizado por lasherramientas MDWorkbench y RulesComposer anteriormente citadas.

5.2. Herramientas

Durante el transcurso de este proyecto se han utilizado varias herramientas para traba-jar con MDD. Algunas de esas herramientas ya se han analizado en parte en el Capítulo 4,dedicado a los lenguajes específicos de dominio, ya que combinan ambos conceptos. Eneste capítulo se analizarán las herramientas desde el punto de vista del MDD. Tambiénse analizan otras herramientas; algunas de ellas incorporan el entorno completo para eldesarrollo dirigido por modelos; otras son plugins o add-ons que trabajan conjuntamentecon otras herramientas y dependen de ellas. En esta sección se analizarán todas inde-pendientemente, pero especificando como interactúan con otras y se hará una pequeñacomparativa.

5.2.1. MetaEdit+

Descripción

En el capítulo anterior se mostraba cómo utilizar esta herramienta para crear DSLgráficos que podían ser utilizados para definir modelos de un sistema. MetaEdit+ ofrecetambién un generador de texto que permite generar ficheros textuales desde los modelos.

40

5.2. HERRAMIENTAS

Figura 5.2: Transformacion MetaEdit+

Características

MetaEdit+ trae algunas transformaciones ya definidas que pueden ser útiles para ob-tener información de los modelos; entre ellas se encuentran las que generan listas con loselementos del modelo, o exportan el modelo a un fichero HTML o a un documento Word.Aparte de estas transformaciones, MetaEdit+ también permite definir transformaciones demodelo a texto utilizando su propio lenguaje de transformaciones llamado MERL (Me-taEdit+ Reporting Language).

La Figura 5.2 muestra la herramienta de MetaEdit+ utilizada para definir las transfor-maciones. La forma de definir una transformación en MetaEdit+ es realizando una itera-ción de todos los objetos del modelo, obteniendo la información de los distintos elementose introduciéndolos en una plantilla de texto. El lenguaje MERL ofrece varios comandospara acceder a los distintos elementos de un modelo. Una transformación comienza conla definición de la transformación y del fichero de salida. Normalmente toda la definiciónde la transformación va dentro de una sentencia foreach() donde se itera en un tipo deelementos definidos en el modelo. Por ejemplo, en la Figura 5.2 se itera en los objetosdel tipo Controllable que se encuentran en el modelo. A partir de ahí se navega sobretodo el modelo obteniendo la información de los diferentes elementos. El lenguaje MERLofrece algunas sentencias de control y navegación existentes en la mayoria de lenguajes,

41


tales como if, foreach o dowhile. También ofrece algunos comandos para obtener lainformación de los elementos del modelo que se están recorriendo, tales como type, id,objectid etc.

Se puede generar cualquier tipo de texto utilizando el generador de MetaEdit+ yasea código, documentación o cualquier otro fichero textual, pero en cambio no ofrece laposibilidad de definir transformaciones entre modelos.

En Kelly & Tolvanen (2008) se pueden encontrar varios ejemplos realizados con estaherramienta.

Ventajas y limitaciones

Entre los aspectos positivos de esta herramienta cabe destacar la facilidad de uso aldefinir lenguajes específicos de modelado con GOPPRR. La definición de modelos conel DSL creado es también muy fácil. La herramienta permite realizar todas las tareasgráficamente de forma muy sencilla, además de facilitar la creación de iconos propios parautilizar en los modelos, haciendo que éstos sean identificados fácilmente como elementosdel dominio. La expresividad conseguida a la hora de modelar con esta herramienta esmuy alta.

Otro aspecto positivo a comentar es que la herramienta está muy bien documentadacon varios ejemplos y tutoriales, lo que posibilita su fácil entendimiento y uso..

Así como la creación de lenguajes y el modelado se hacen sin dificultad con estaherramienta, no ocurre lo mismo a la hora de generar código. La definición de una trans-formación utilizando el lenguaje MERL resulta más complicada que cuando se utilizanotros lenguajes de transformación que ofrecen más posiblidades a la hora de navegar entrelos elementos de los modelos. La sintaxis tampoco es tan clara como en otros lenguajes, yel estilo de programación difiere bastante, al definir toda la transformación dentro de unaiteración donde la navegación entre los elementos del modelo puede resultar complicadoen muchos casos.

Otro aspecto negativo de la herramienta es el uso de formatos propios para exportarmodelos y metamodelos, haciendo incompatible su uso en otras herramientas, a no serque estos permitan la importación de modelos de MetaEdit+. La interoperabilidad conotras herramientas sería más fácil si se utilizara el formato XMI. De este modo seríaposible importar modelos de MetaEdit+ en otras herramientas y utilizar otros lenguajespara definir las transformaciones.

Finalmente, como ya se ha comentado, con está herramienta se puede transformar demodelo a texto, pero no así de modelo a modelo. El punto fuerte de esta herramienta

42

5.2. HERRAMIENTAS

reside más en la creación de metamodelos y modelos que en la definición de las transfor-maciones.

5.2.2. Eclipse Modeling Framework

Descripción

Eclipse Modeling Framework (EMF) es el framework que ofrece Eclipse para MDD.En el capítulo anterior se ha visto como utilizar el lenguaje de metamodelado Ecore queofrece EMF para definir lenguajes de modelado específicos de dominio. Eclipse es unentorno de desarrollo extensible al que se le pueden añadir gran variedad de plugins1,que fue desarrolado inicialmente por IBM y en la actualidad se distribuye como softwarelibre.

Características generales

En el anterior capítulo se ha descrito cómo utilizar esta herramienta para diseñar len-guajes específicos de modelado y crear un editor para definir modelos.

Como se ha comentado, esta herramienta es extensible, lo que significa que se le pue-den añadir nuevas funcionalidades para trabajar en el mismo entorno. Es posible exten-derlo para trabajar con modelos de UML, para los que ofrece un editor, y que se puedenutilizar en distintas transformaciones. Aunque EMF trae algunas herramientas para definirlas transformaciones de modelos, en nuestro caso se le han añadido ATL para transfor-maciones entre modelos y MOFScript para transformaciones de modelo a texto. Esasherramientas serán analizadas posteriormente de forma individual.


Entre los aspectos positivos de esta herramienta hay que resaltar su extensibilidad.Existe una gran variedad de plugins que pueden ser añadidos para extender la funcio-nalidad de la herramienta. Esto posibilita hacerlo “todo” en el mismo entorno, desde ladefinición del metamodelo hasta la generación de código, o incluso la edición y compila-ción del código generado.

La documentación de la herramienta es bastante completa, aunque dependa mucho decada plugin, ya que estos tienen documentación propia. Además la ayuda ofrecida por lacomunidad resulta muy útil. Durante el transcurso del proyecto se han utilizado los grupos

1http://www.eclipseplugincentral.com/

43


Figura 5.3: Transformación ATL

de noticias de Eclipse2, en los que la actividad es muy alta, lo que posibilita la obtenciónde ayuda casi instantáneamente.

El uso de XMI como representación textual de los modelos y metamodelos también esun aspecto positivo a comentar, ya que facilita la interoperabilidad con otras herramientasde modelado o generadores de código.

En EMF, al igual que en MetaEdit+ la creación de un lenguaje de modelado medianteel metamodelado es muy fácil e intuitivo. En cambio, con EMF no es tan fácil la definiciónde un editor gráfico para modelos. Mientras ésto era automático en MetaEdit+, en EMFhay que hacer uso de la herramienta GMF, la cual no es tan fácil de usar.

En resumen, se puede decir que aunque EMF permita realizar casi todo tipo de tareas,la realización de algún tipo específico de tareas puede resultar más difícil, y al ser unaherramienta con tantas opciones su aprendizaje ha resultado más costoso.

5.2.3. ATL

Descripción

Es una herramienta desarrollada por ATLAS Group3 para la transformación entre mo-delos, es decir, de modelo a modelo. Esta herramienta permite definir las transformacionesutilizando el lenguaje de su mismo nombre, ATL (ATLAS Trasnformation Language). Esuna herramienta integrada como plugin dentro de EMF que permite definir transforma-ciones entre metamodelos definidos con éste.

2http://www.eclipse.org/newsportal/3http://www.sciences.univ-nantes.fr/lina/ATLAS/

44

5.2. HERRAMIENTAS


ATL es una herramienta que permite definir transformaciones entre uno o varios me-tamodelos de entrada y uno o varios metamodelos de salida. Para ello ofrece una máquinavirtual, un editor, un debugger y un lenguaje de transformaciones.

El lenguaje de transformaciones ATL es un lenguaje que permite definir las transfor-maciones tanto en un estilo de programación declarativo como en un estilo imperativo.Aún así, el estilo preferido y utilizado mayoritariamente con este lenguaje es el declarati-vo, con el cual se definen los mapeos entre los elementos de los metamodelos de entrada ysalida. Aunque se puede utilizar el estilo imperativo para definir mapeos que difícilmentese pueden hacer con el estilo declarativo.

Una transformación ATL es al mismo tiempo un modelo, que conforma al metamo-delo de ATL. Es decir, la sintaxis abstracta del lenguaje ATL está definida mediante unmetamodelo. Eso permite tratar las propias transformaciones como modelos.

Una definición de transformación en ATL se compone de varias reglas en las cualesse definen los mapeos. Cada regla puede estar dividida en tres secciones: from, to y do.En la sección from se especifica el elemento del metamodelo de entrada. En la secciónto se define el elemento del metamodelo de salida, y se hace el mapeo entre la entrada yla salida. Para finalizar, en la sección do se puede escribir código imperativo. Para la pro-gramación imperativa, ATL ofrece las estructuras disponibles en la mayoría de lenguajesde programación. Aparte de reglas, en las transformaciones de ATL también se puedendefinir los llamados helpers, que son fuciones de ayuda.

Una transformación ATL puede tener varios modelos de entrada y de salida, del mismoo de diferentes metamodelos.

Otra característica ofrecida por esta herramienta es la superimposición, que permitecombinar varias definiciones de transformaciones en una misma ejecución superimpo-niendo una encima de otra, algo similar a la herencia, y posibilitando así la reutilizaciónde código.


Entre los aspectos positivos a destacar sobre esta herramienta está su gran extensión.Al ser una de las herramientas más utilizadas para la transformación entre modelos ladocumentación es muy completa y el soporte ofrecido por la comunidad también. Aligual que con EMF existe un grupo de noticias muy activo.

Otro aspecto positivo es la existencia de librerías de transformaciones ya definidas

45


Figura 5.4: Transformación MOFScript

para varios casos prácticos4.

Como aspecto negativo habría que señalar su dificultad de aprendizaje. Aunque lastransformaciones puedan parecer muy intuitivas en algunos caso típicos, el estilo de pro-gramación en este lenguaje difiere bastante de otros lenguajes, lo que dificulta su com-prensión y aprendizaje. Ha sido uno de los lenguajes más difíciles de aprender durante elproyecto.

5.2.4. MOFScript

Descripción

MOFScript es una herramienta de libre distribución para transformaciones de mode-lo a texto, aunque también pueda usarse para transformaciones entre modelos. Se instalacomo plugin de EMF y permite definir transformaciones para cualquier metamodelo de-finido por el usuario, además de algunos metamodelos predefinidos. Ofrece para ello unlenguaje de transformaciones también llamado MOFScript.


Esta herramienta se utiliza para generar ficheros de texto partiendo de uno o variosmodelos de entrada que pueden conformar a su vez a uno o varios metamodelos. Gene-ralmente es usado para generar código de implementación o documentación, pero puede

4http://www.eclipse.org/m2m/atl/atlTransformations/

46

5.2. HERRAMIENTAS

generarse cualquier tipo de fichero textual.

El lenguaje MOFScript está basado en reglas, y una definición de transformación eneste lenguaje está normalmente compuesta por varias reglas (ver Figura 5.4). La ejecuciónde la transformación siempre comienza por la regla main(). Las reglas pueden disponerde un punto de entrada, que define para que tipo de elemento se ejecutará esa regla. En elcuerpo de las reglas puede ir texto que se imprimirá en el fichero de salida, junto con otrassentencias o llamadas a funciones, para completar el texto. MOFScript ofrece las típicassentencias de control disponibles en cualquier lenguaje imperativo. Al ser un lenguajeorientado a producir texto, también dispone de funciones ya predefinidas para trabajarcon cadenas de caracteres o strings. El nombre del fichero de salida se define con lasentencia file().

Este lenguaje también implementa aspectos con el objetivo de reutilizar código, aun-que ésta sea una incorporación reciente y la implementación no sea completa.

La herramienta dispone de un editor de texto específico para este lenguaje. Dispone deun asistente de código que permite identificar fácilmente los diferentes elementos defini-dos en el metamodelo de entrada. Las transformaciones son compiladas por el compiladordel que dispone la herramienta, y posteriormente ejecutadas. A la hora de la ejecución sepide al usuario seleccionar los modelos de entrada.

Al igual que existía un metamodelo de ATL, también existe uno de MOFScript. Lapropia herramienta dispone de una utilidad que permite transformar una definición detransformación en MOFScript a un modelo MOFScript que conforma al metamodelo an-terormente indicado. Un modelo de MOFScript también puede ser ejecutado directamen-te, o puede ser convertido de nuevo en una definición de transformación en el lenguajeMOFScript. Esa característica nos ha permitido durante este proyecto aplicar la variabili-dad a las transformaciones, pero eso se trata en el siguiente capítulo.


Como aspectos positivos de esta herramienta se pueden destacar por una parte quesu integración con EMF hace posible trabajar de manera fácil con cualquier metamodelocreado con éste. Por otra parte, al igual que con las dos herramientas anteriores la ayudaofrecida por la comunidad es muy completa.

Otro aspecto positivo a resaltar es la de su uso. El lenguaje es muy parecido a otroslenguajes, y empezar a hacer las primeras transformaciones con él ha resultado una tarearelativamente fácil. Ademas, dispone de la posibilidad de invocar programas Java dentrode las transformaciones.

47


Como aspecto negativo se pueden comentar algunas dificultades encontradas a la horade dar el formato deseado al texto de salida, con tabulaciones, saltos de línea, etc. Retocarel texto de salida definido dentro de las reglas hace a veces que la definición de la trans-formación quede algo ilegible, haciendo difícil intuir lo que se obtendrá en el fichero desalida.

5.2.5. MDWorkbench

Descripción

MDWorkbench es una herramienta desarrollada por Sodius5 para transformaciones demodelos. Entre las posibilidades que ofrece están la transformación de modelo a modelo,generación de texto y generación de documentación en Microsoft Word. Es una herra-mienta basada en EMF, que puede ser instalada tanto como plugin de este último o comopaquete completo.


Esta herramienta está específicamente pensada para transformaciones de modelos.Aunque ofrezca la posibilidad para definir modelos, su utilidad reside en la posibilidadque ofrece para la transformación de modelos creados con otras herramientas.

MDWorkbench contiene algunos metamodelos predefinidos que permiten definir di-rectamente transformaciones para modelos definidos en UML, Relational o Ecore, porejemplo. Pero aparte de eso ofrece también la posibilidad de importar cualquier meta-modelo que el usuario haya creado para definir un lenguaje de modelado específico dedominio, ya sea utilizando EMF, RationalRose, UML, KM3 o XSD. Es decir, es posibledefinir un metamodelo utilizando los lenguajes citados e importarlo a MDWorkbench paradefinir transformaciones para modelos que conforman a nuestro metamodelo.

Una vez importado un metamodelo a MDWorkbench, podemos abrir modelos especí-ficos de dominio que conformen a él. La herramienta ofrece varias posibilidades.

Navegación de modelos: La herramienta ofrece una utilidad para navegar fácilmenteentre los elementos del modelo. El navegador muestra todos los elementos que contieneel modelo, qué atributos tienen, y cómo están relacionados con otros elementos. El na-vegador muestra estas relaciones en forma de árbol. Este navegador de modelos facilitael trabajo a la hora de definir las transformaciones, ya que permite ver fácilmente qué

5http://www.sodius.com/

48

5.2. HERRAMIENTAS

Figura 5.5: Transformacion utilizando TGL

propiedades tiene cada elemento, sin tener que conocer el metamodelo. En la Figura 5.8se puede ver el aspecto del navegador de modelos, que es el mismo del que disponibleRulesComposer.

MDWorkbench también dispone de un navegador de metamodelos, que ofrece la po-sibilidad de ver los elementos del metamodelo, con sus atributos y relaciones.

Transformaciones de modelo a modelo: El lenguaje para transformaciones de modeloa modelo utilizado por MDWorkbench se llama MQL (Model Query Language). Es unlenguaje basado en reglas que permite acceder a los distintos elementos definidos en unmetamodelo. Al principio de una transformación se definen los metamodelos de entrada yde salida como parámetros. El editor de la herramienta dispone de un asistente de código,que ayuda a navegar sobre los distintos elementos, aparte de mostrar funciones que laherramienta trae ya implementadas en su librería.

La herramienta ofrece una librería bastante completa que dispone de funciones paraactuar sobre los elementos de distinto tipo que se pueden encontrar en los metamode-los importados. Gracias a su integración con la plataforma Java, la herramienta tambiénpermite la utilización de código Java en las transformaciones.

MDWorkbench también ofrece la posibilidad de definir scripts que se pueden invocardesde la transformaciones, y que evitan la escritura del mismo código en distintas partesde la transformación. Los scripts se definen para un tipo de elemento concreto definido enel metamodelo, y pueden ser implementados tanto en MQL como en Java.

Transformaciones de modelo a texto: La transformación de modelo a texto en MD-Workbench se basa en plantillas de texto, combinándolas con el lenguaje TGL (Text Ge-

49


Figura 5.6: Plantilla para generar documentación en Word

neration Language). Utilizando este lenguaje se especifican los elementos de entrada deuna plantilla de texto y el fichero de salida. El lenguaje permite acceder a los distintoselementos de los modelos para ir introduciéndolos como texto en la plantilla (ver Figura5.5).

Al igual que en el caso de la definición de transformaciones entre modelos, en estecaso también ofrece gran cantidad de funciones predefinidas a las que se puede accederfácilmente con el asistente de código. También en este caso es posible la utilización decódigo Java, y la definición de scripts, que pueden estar implementados en los lenguajesJava, MQL o TGL.

Siendo un lenguaje orientado a generar texto, TGL también ofrece sentencias especí-ficas para dar formato al texto, controlando tabulaciones, espacios, saltos de línea etc.

La utilidad de transformaciones de modelo a texto en MDWorkbench se utiliza mayo-ritariamente para generar código de implementación, ya que esta herramienta dispone deotra utilidad aparte que sirve para la generación de documentación.

Generación de documentación: Gracias a la integración con Microsoft Word, MD-Workbench ofrece la posibilidad de generar documentación en documentos Word. Paraello ofrece la posibilidad de crear una plantilla en word, de forma parecida a una plantillade una transformación de modelo a texto. La diferencia reside en que en este caso tambiénse pueden emplear utilidades de word, tales como tablas, estilos de texto, etc. y que losficheros generados son documentos Word. Esto hace posible obtener como resultado unadocumentación clara del sistema.

50

5.2. HERRAMIENTAS

Figura 5.7: Representación del sistema UK01 en Rhapsody


Esta herramienta ha destacado por su facilidad de uso. Es una herramienta muy in-tuitiva para todo tipo de transformaciones, y la navegación de modelos, el asistente decódigo, las funciones predefinidas, y la integración con Java hacen que su utilización seamuy sencilla, posibilitando la definición de transformaciones nada más empezar a usarla.

Hay que mencionar también la utilidad de generar la documentación, que permitecrear una documentación muy completa del sistema de forma muy sencilla.

Otra característica positiva de esta herramienta es que instalándolo como plugin deEMF es posible realizar todas las tareas desde la definición del DSL hasta las transforma-ciones y la generación dentro del mismo entorno.

Como aspecto negativo se puede mencionar que algunas veces ha resultado necesariomodificar a mano alguna parte del código del metamodelo importado para que el modelode salida de una transformación tuviese la representación textual deseada.

5.2.6. IBM Telelogic Rhapsody

Descripción

Rhapsody es una herramienta comercial para el desarrollo dirigido por modelos, orien-tada especialmente a sistemas de tiempo real o embebidos. Permite modelar software uti-lizando UML y sistemas con SysML, el cual es pun perfil de UML para el modelado de

51


sistemas; ofrece asimismo varias utilidades como la generación de código, generación detests etc. Además, es una herramienta que se puede extender mediante add-ons.


Rhapsody es una herramienta muy completa que ofrece muchas posibilidades, pero alcentrarse este proyecto en el MDD el análisis se ha enfocado a la definición de modelosy a la generación de código.

Rhapsody ofrece un entorno para definir modelos utilizando UML o SysML comolenguajes de modelado. Además de disponer de un editor de diagramas para definir losmodelos, también permite añadir gran cantidad de información a éstos, lo que resulta degran ayuda a la hora de generar código. Se puede especificar el cuerpo de las operaciones,las descripciones, definir nuevos tipos, estereotipos, etc.

Rhapsody dispone de un generador de código para transformar los modelos defini-dos con la herramienta en código de implementación. Durante este proyecto la versiónutilizada ha sido la de C++, por lo que hemos generado código en ese lenguaje, peroRhapsody también ofrece la posibilidad de generar C, Java o Ada. El generador internode Rhapsody permite generar el código de implementación completo del sistema. Aúnasí, la transformación aplicada por esta herramienta es una transformación predefinida, yaunque el código resultante pueda ser de utilidad, muchas veces éste puede no ser la im-plementación deseada. Para eso Rhapsody permite utilizar transformaciones externas, yofrece la posibilidad de ser extendido por la herramienta RulesComposer, que se analizaráposteriormente, y que permite definir transformaciones personalizadas.

Entre otras características que ofrece esta herramienta, pero que no se han utilizadodurante el proyecto, se encuentran la generación de tests, la ejecución de los modelos, laingeniería inversa etc.


Como aspecto positivo de Rhapsody cabe destacar que es una herramienta muy com-pleta que ofrece gran multitud de opciones. Los modelos definidos con esta herramientacontienen gran cantidad de información que facilitan la generación de código.

Empezar a hacer cosas básicas con esta herramienta, como definir distintos modelospuede ser fácil, pero dado el alto precio de la misma no resulta recomendable plantear suuso para utilizarla sólo para dibujar modelos. Es una herramienta con un gran potencial,pero aprender a utilizarla para sacarle el máximo provecho puede requerir mucho tiempo.

52

5.2. HERRAMIENTAS

Figura 5.8: Navegación de modelos en RulesComposer

Otro aspecto negativo de Rhapsody es la imposibilidad de trabajar con modelos espe-cíficos de dominio, y también la dependencia que muchas veces pueden tener los modelosde la plataforma para la que se van a implementar.

5.2.7. RulesComposer

Descripción

RulesComposer es una herramienta desarrollada por Sodius, y que funciona como unaextensión de Rhapsody. Esta herramienta es básicamente la misma que MDWorkbench,pero con la posibilidad de trabajar con modelos definidos en Rhapsody. Es decir, añadelas funcionalidades de MDWorkbench a Rhapsody.


Esta herramienta ofrece las mismas funcionalidades que MDWorkbench. El entornoes parecido, pero RulesComposer lleva incorporado el metamodelo de Rhapsody. Al abrirla herramienta RulesComposer desde Rhapsody, se abre un entorno parecido al de MD-Workbench, donde se puede navegar por el modelo con el que se está trabajando en Rhap-sody.

Al igual que con MDWorkbench es posible definir transformaciones de modelo a mo-

53


MetaEdit+ EMF ATL MOFScript MDWorkbench Rhapsody RulesComposerVersión 4.5 2.4 2.0 1.3 3.0 7.3 2.3

Desarrollador MetaCase Eclipse Foundation ATLAS SINTEF Sodius SAS IBM Sodius SASLicencia Propietaria Libre Libre Libre Propietaria Propietaria Propietaria

Metamodelado " " - - - - -Modelado " " - - " " "

Modelo a modelo - " " " " - "

Modelo a texto " " - " " " "

Table 5.1: Características del las herramientas de MDD

delo con MQL, transformaciones de modelo a texto con TGL, y generar documentaciónen Microsoft Word. También es posible añadirle metamodelos propios para trabajar connuestros modelos específicos de dominio.

Rhapsody ofrece la opción de ejecutar transformaciones de modelo externas, lo queposibilita invocar un generador definido con RulesComposer desde el entorno de trabajode Rhapsody.


RulesComposer comparte todos los aspectos positivos de MDWorkbench, pero ade-más hay que destacar que junto a Rhapsody ofrece una plataforma muy completa paragenerar código, gracias a la cantidad de información que se puede obtener de los modelosde Rhapsody.

Esta herramienta posibilita también la utilización de imágenes de los modelos deRhapsody a la hora de generar documentación.

Durante el proyecto la utilización de esta herramienta ha resultado bastante fácil, de-bido a que se había utilizado MDWorkbench anteriormente.

5.2.8. Comparativa y conclusiones

No es fácil realizar una comparativa de todas la herramientas presentadas. Aunquetodas están relacionadas con el MDD, al estar cada una centrada en una función y notener todas ellas las mismas funcionalidades, no es fácil decidir cuáles son los aspectos acomparar.

Algunas de las herramienas, como MetaEdit+ o Rhapsody pueden ser utilizadas inde-pendientemente, mientras que otras tienen que complementarse mutuamente. En la tabla5.1 se muestra una pequeña comparativa de las posibilidades que ofrece cada una de ellasa la hora de trabajar en el MDD.

Por comparar algunos aspectos generales, se puede mencionar la facilidad que ofreceMetaEdit+ para crear lenguajes específicos de modelado gráficos en comparación con

54


EMF. En cambio, a la hora de generar código es más fácil hacerlo con modelos creadoscon EMF, ya que existen varias herramientas diferentes para definir transformacionespara los mismos, y de las cuales algunas, como MDWorkbench, ofrecen gran facilidadde uso y gran variedad de opciones. Si se desea modelar utilizando UML tanto EMFcomo Rhapsody ofrecen esa posibilidad, pero en este caso Rhapsody ofrece una soluciónmás completa que, gracias además a RulesComposer, ofrece un abanico más amplio deposibilidades.

Aún así, hay que destacar que en el análisis de esas herramientas no se ha tenido encuenta el precio de las mismas, un aspecto que puede ser decisivo a la hora de decantarsepor una u otra. Por esta razón es muy importante tener claro para qué se va utilizar y elprovecho que se le va a sacar antes de decidirse por una.

5.3. Caso de estudio

5.3.1. Descripción

El sistema utilizado en este caso de estudio es el mismo sistema de control de inun-daciones llamado UK01 descrito en el Capítulo 4. La implementación de este sistema sehace utilizando el lenguaje C++, definiendo una clase para cada subsistema. Las entradasy salidas de cada subsistema son los atributos de la clase, y cada clase tiene tres operacio-nes, el constructor, el destructor y una operación exec donde se realizarán las accionesoportunas.

En este ejemplo se define una transformación de modelo a texto para generar el có-digo de implementación de los sistemas de control de inundaciones definidos en EMF.Para mostrar una transformación de modelo a modelo, también se define una transfor-mación con ATL que transforma nuestro modelo en un modelo UML. Para finalizar, seutiliza Rhapsody para generar tanto código como documentación desde el mismo sistemadefinido con UML.

5.3.2. Transformación de modelo a texto con MOFScript

La imagen 5.4 muestra la transformación definida con MOFScript para generar unfichero .cpp por cada subsistema. En la definición de la transformación se especifica enforma de parámetro a qué metamodelo conformará el modelo de entrada de la transfor-mación, que en este caso será el metamodelo definido en el anterior capítulo utilizandoEMF.

55


Figura 5.9: Fichero TenpKont.cpp generado con MOFScript

La transformación definida está compuesta por distintas reglas que generarán diferen-tes partes del fichero de salida. Se ha definido una regla para generar la cabecera, otrapara generar las variables locales, y finalmente se ha definido una regla para generar cadaoperación.

La transformación comienza por la regla main(), que se ejecutará para cada subsis-tema del modelo, ya que así lo indica su punto de entrada. En esa regla se especifica elnombre del fichero de salida con el comando file(), y posteriormente se invoca a lasdemás reglas para generar su contenido. Tal y como se puede apreciar en la Figura 5.4,dentro de las reglas es posible combinar texto predefinido con elementos del metamodelopara generar la salida deseada.

Una vez definida la transformación, a la hora de ejecutarla hay que elegir un modelode entrada; en este caso el modelo del sistema UK01 definido en el capítulo anterior. LaFigura 5.9 muestra parte de un fichero que se genera tras la ejecución de la transformación.

5.3.3. Transformación de modelo a modelo con ATL

Como ya se ha comentado, las transformaciones no se usan sólo para generar texto,también se pueden generar diferentes modelos de un mismo sistema. Una de las herra-mientas utilizadas durante el proyecto para esa tarea es ATL, con la cual hemos definido

56


Figura 5.10: Modelo UML generado con ATL

una transformación para transformar el modelo que habíamos definido con EMF en unmodelo de clases UML del mismo sistema.

La Figura 5.3 muestra parte de la transformación definida utilizando el lenguaje ATL.Como se aprecia en ella, al principio de la transformación se definen los parámetros deentrada y salida. El resto de la transformación se compone de reglas. Estas reglas utilizanun estilo declarativo, donde elementos del metamodelo de entrada son mapeados conelementos del metamodelo de salida. Las secciones from y to de cada regla indican quétipo de elemento de entrada y qué tipo de elemento de salida se mapearán. En nuestrocaso de estudio el elemento del tipo System se transforma en un Package de UML,que contendrá una clase por cada elemento del tipo Subsystem del modelo original. Loselementos de los tipos Input y Output son mapeados como atributos de las clases UMLdel modelo de salida. En la Figura 5.3 se pueden apreciar los mapeos realizados, dondese puede ver, por ejemplo en la regla subSys2class, que al nombre de la clase UML sele asigna el nombre del subsistema y se asignan como atributos de las clases las entradasy salidas del subsistema.

Tras la aplicación de esa transformación al modelo definido con EMF, se obtiene comoresultado el modelo UML de la Figura 5.10.

5.3.4. Ejemplo con Rhapsody y RulesComposer

Se ha utilizado Rhapsody para modelar el mismo sistema de control de inundacionesutilizando UML, para posteriormente generar tanto código como documentación.

La Figura 5.7 muestra cómo se ha definido cada subsistema utilizando una clase. Lasentradas y salidas han sido definidas como atributos y a cada clase se le ha definido una

57


Figura 5.11: Documentación generada con RulesComposer

operación exec() aparte del constructor y del destructor. Rhapsody permite completar losmodelos añadiendo todo tipo de información como estereotipos, descripciones, partes decódigo, etc. a los distintos elementos. En nuestro caso se les ha añadido una descripcióntanto a las clases como a los atributos, y se han definido los estereotipos input, outputy subsystem para indicar la función de cada elemento. Todo ello con los objetivos defacilitar la tarea al definir la transformación y hacer los modelos más expresivos.

A partir del modelo definido se ha generado tanto código C++ como documentos deMicrosoft Word utilizando el add-on RulesComposer. Al invocar la herramienta Rules-Composer desde Rhapsody podremos navegar por los elementos del modelo definido (verFigura 5.8). La Figura 5.5 muestra la transformación definida utilizando el lenguaje TGLpara generar un fichero .cpp. Esta transformación es una plantilla de texto donde se in-troducen los elementos obtenidos del modelo. En la figura mostrada también se puedeapreciar la utilización de funciones de Java. La ejecución de esta transformación generacódigo parecido a la transformación definida por MOFScript para el modelo de EMF (verFigura 5.9).

Utilizando la función que RulesComposer dispone para ello, también se ha generadoun documento Word a partir del modelo, donde se documentan los distintos subsistemascon sus atributos, operaciones y diagramas de estados, si es que tienen, que representansu comportamiento. La Figura 5.6 muestra la plantilla definida en Word. En esta plantilla

58


se puede acceder a los distintos elementos del metamodelo del mismo modo que en laplantilla definida con TGL, pero además es posible utilizar distintas utilidades de Wordcomo estilos, tablas, etc. para darle forma al texto. La Figura 5.11 muestra el resultadode la aplicación de esta transformación al modelo de entrada. Como se puede apreciar, esposible utilizar las imágenes de los modelos en la documentación.

Para poder ejecutar las dos transformaciones de una sola vez, se puede definir unruleset en Rhapsody desde el cual, mediante una regla, se pueden invocar ambas transfor-maciones.

5.3.5. Beneficios obtenidos

De la realización del caso de estudio es posible concluir cuáles son los beneficiosobtenidos de la utilización del paradigma de MDD.

Por una parte, se ha automatizado toda la generación del código a partir de los mode-los. Esto simplifica en gran medida la tarea de implementación. Se ha podido generar laimplementación de todas las clases definiendo una única plantilla (de otra manera habríaque escribir el código de cada clase a mano). Además de simplificar la tarea de imple-mentar el código, mediante el uso de las plantillas se evita la inserción de errores.

Por otra parte, la utilización de transformaciones permite centrar el desarrollo del soft-ware en el modelado. La transformación puede ser definida por una persona que conocemuy bien el lenguaje de implementación, pero un desarrollador trabaja a nivel de modela-do, donde la abstracción es mayor, y no tiene por qué saber todos los detalles del lenguajeen el que el software será implementado. Al trabajar con modelos se consigue una ma-yor expresividad y la generación automática de código permite disminuir el tiempo dedesarrollo.

Además de todo lo comentado, en el caso de estudio ha quedado demostrado la faci-lidad que ofrecen algunas herramientas para generar una documentación muy completa.Gracias a ello es posible obtener la implementación y la documentación de todo el sistemaal mismo tiempo.

En resumen, debido a sus ventajas en distintos aspectos, el MDD ayuda a incrementarla productividad a la hora de desarrollar software.

59


60

Capítulo 6

Variabilidad en el Desarrollo Dirigidopor Modelos

Durante el transcurso de este proyecto se ha dedicado una parte del tiempo a la inves-tigación. El MDD es un paradigma en auge, en el que se está avanzando cada vez más. Sucombinación con otros paradigmas de desarrollo de software hace posible el uso de losaspectos más positivos de cada uno de ellos durante el desarrollo del software.

La combinación de las Líneas de Producto Software (SPL) con el MDD, combina laabstracción que se puede obtener a través del modelado con la variabilidad que introducenlas familias de programas. En este sentido, se ha realizado bastante trabajo en lo que ala variabilidad de modelos se refiere, como la representación de familias de programasmediante modelos y la composición de los mismos (Apel et al., 2009; Trujillo et al.,2007). En cambio no se ha realizado tanto trabajo en lo que respecta en la variabilidadque pueden necesitar otros elementos que participan en el MDD, como metamodelos otransformaciones de modelos.

En este trabajo se ha analizado cómo puede afectar la variabilidad a todos los artefac-tos presentes en el MDD, y se presenta una solución para trabajar con esa variabilidad.Durante la realización del proyecto se han escrito varios artículos como resultado de lainvestigación. En uno de los artículos se menciona la necesidad de la variabilidad en losmetamodelos y en las transformaciones además de en los modelos (Trujillo et al., 2009a).En otro artículo se presenta una solución para aplicar la variabilidad mediante refina-mientos a las transformaciones de modelo a texto (Trujillo et al., 2009b). Finalmente, seestá trabajando en la aplicación de la variabilidad a los modelos, metamodelos y transfor-maciones al mismo tiempo, lo que nosotros hemos definido como Lock-Step Refinement

(Trujillo & Zubizarreta, 2009).

61

CAPÍTULO 6. VARIABILIDAD EN EL MDD

Figura 6.1: Modelo de control de temperatura

Este capítulo está basado en el segundo de los artículos, donde se presenta una solu-ción basada en refinamientos para introducir la variabilidad en las transformaciones demodelo a texto definidas con MOFScript, y que ha sido aceptado en las XIV Jornadas de

Ingeniería del Software y Bases de Datos (JISBD 2009).

6.1. Conceptos básicos

6.1.1. MDD

En el capítulo anterior se ha profundizado en el desarrollo dirigido por modelos. Re-sumiendo, el MDD es un paradigma en el que el objetivo es conseguir automatizar lageneración de código desde los modelos. Se han presentado los distintos elementos queparticipan en un escenario MDD, que eran los modelos, que conformaban a los metamo-delos, y las transformaciones, que definían mapeos entre diferentes metamodelos.

Para realizar esta parte del proyecto se ha utilizado un caso de estudio simplificado,pero basado en un sistema industrial. El comportamiento del sistema es representado porun modelo, del cual se obtiene código de implementación a través de una transformación.

Modelo: La Figura 6.1 muestra el modelo que se ha utilizado en nuestro caso de es-tudio. Este modelo es un diagrama de estados que representa el comportamiento de unsimple sensor de temperatura. El diagrama tiene los estados sClosed y sOpen, aparte delos estados inicial y final. El modelo también define las transiciones entre los estados ylas condiciones para que éstas se produzcan. Las acciones a ejecutar también pueden serdefinidas, aunque en este ejemplo han sido omitidas para simplificar.

62

6.1. CONCEPTOS BÁSICOS

1 t e x t t r a n s f o r m a t i o n b a s e T r a n s f ( i n sc : " h t t p : / / www. w3 . org / 2 0 0 5 / 0 7 / scxml " )2 {3 v a r o u t p u t F i l e : S t r i n g45 sc . ScxmlType : : main ( )6 {7 f i l e ( o u t p u t F i l e )8 w r i t e S w i t c h S t a r t ( )9 s e l f . s t a t e −>f o r E a c h ( s : s c . S t a t e T y p e )

10 {11 s . g e n e r a t e S w i t c h C a s e s ( )12 }13 w r i t e D e f a u l t ( )14 w r i t e S w i t c h E n d ( )15 }1617 module : : w r i t e S w i t c h S t a r t ( )18 {19 /∗ Empty r u l e : t o be r e f i n e d l a t e r on ∗ /20 }2122 /∗ C o n t e n t o m i t t e d ∗ /23 }

Figura 6.2: Definición de transformación con MOFScript

Metamodelo: El metamodelo utilizado para definir nuestro modelo será un metamode-lo que defina como se puede definir un diagrama de estados. Es decir, este metamodelodefinirá elementos tales como estados, transiciones, sus relaciones, etc. El modelo mos-trado en la Figura 6.1 deberá conformar a este metamodelo.

Transformación: Nuestro caso de estudio se centra en las transformaciones de mode-lo a texto definidas con el lenguaje MOFScript, que ha sido presentado en el capítuloanterior.

La definición de una transformación MOFScript está compuesta por reglas. La Figura6.2 muestra parte de la transformación utilizada en nuestro ejemplo. Esta transformaciónes la base de una transformación para generar una estructura switch que represente undiagrama de estados. En la Figura 6.2 se puede ver que la transformación tiene una reglallamada main(), en la que se define el fichero de salida, y en la que se llama a otras reglas1.

6.1.2. SPL

Una Línea de Producto Software puede ser definida como una colección de sistemasde software enmarcados en un dominio o segmento de mercado específico que compartenvarias características (Clements & Northrop, 2001; Pohl et al., 2006). Las SPL proponen

1En los ejemplos de los artículos se ha omitido parte del código. Los ejemplos completos se puedenencontrar en: http://www.ikerlan.es/softwareproductline/jisbd2009examples.zip

63


un sistema de producción basado en la reutilización de componentes en un determinadodominio.

Por ejemplo, en sistemas de software industriales, la presencia de diferentes tipos desubsistemas implica que cada una está controlada de una manera similar, pero diferente.Esto normalmente se soluciona definiendo diferentes componentes que no tienen por quéestar presentes en todos los sistemas posibles y se componen para producir el productofinal. Estos componentes diferencian los distintos sistemas de software o las variantes dela línea de producto software (Kang & et al., 1990).

Al combinarlos con el MDD, se ha pretendido elevar las SPL a nivel de modelado, enel llamado Model-Driven Product Lines.

6.2. Necesidad de la variabilidad

Tal y como se ha comentado, se ha realizado bastante trabajo en cuanto a la variabi-lidad en los modelos. A continuación analizamos la necesidad de la variabilidad en lastransformaciones de modelos.

6.2.1. Escenario

Se pueden dar diferentes escenarios en la combinación del MDD con las SPL. Consi-derar las diferencias, por ejemplo, en el lenguaje de modelado utilizado: no es lo mismoutilizar UML que un DSL.

En algunos escenarios la variabilidad de los modelos puede ser suficiente. Por ejemplosi el metamodelo es estándar y éste no está sujeto a variabilidad, como puede pasar cuandose usa UML. No tiene sentido hacer que el metamodelo de UML sea variable siendo ésteun metamodelo estandarizado. Puede producirse una situación similar en el caso de lastransformaciones, cuando éstas están predefinidas en una librería y son compartidas, comopor ejemplo la cantidad de transformaciones ATL que se pueden encontrar online2.

En cambio, existen escenarios donde la variabilidad de las transformaciones de mode-los puede ser necesaria. Por ejemplo, se puede dar el caso en el que las transformacionesde modelos deben ser personalizadas para diferentes plataformas (e.g. generar código endiferentes lenguajes desde el mismo modelo). Las transformaciones compartirán una par-te común, mientras se diferenciarán en algunas partes variables. Esta situación puede sermanejada introduciendo el concepto de SPL. Tendremos una familia de transformaciones,donde gran parte de código será compartido por todas las transformaciones, mientras cada

2http://www.eclipse.org/m2m/atl/atlTransformations/

64

6.3. REFINAMIENTO DE TRANSFORMACIONES

una tendrá sus propias particularidades dependiendo del lenguaje de destino. La aplica-ción de la variabilidad en este caso, nos permite manejar estas diferencias en una únicatransformación de modelo. A continuación se explica como se introduce la variabilidaden nuestro caso de estudio.

6.2.2. Caso de estudio

En una sección anterior se ha mostrado como se desarrollaba un sistema de control detemperatura siguiendo el MDD. Se ha enseñado un modelo definido con un diagrama deestados, del que se quería generar código de implementación mediante una transformacióndefinida con MOFScript.

En nuestro caso de estudio se pretende generar una estructura switch que está disponi-ble en la mayoría de lenguajes de programación actuales, para representar el diagrama deestados. En este caso concreto los lenguajes son Ada y Java. En realidad, Ada no ofrecela estructura switch, pero dispone de una estructura case que es equivalente al switch deotros lenguajes.

Se podría definir una transformación separada para cada lenguaje de salida, pero enese caso habría que reescribir toda la transformación cada vez que quisiésemos generarcódigo para algún lenguaje nuevo. Algo extremadamente laborioso en un sistema grande,o donde haya gran cantidad de lenguajes de destino.

La estructura switch es muy similar en la mayoría de los lenguajes de programación,radicando su diferencia normalmente en la sintaxis. Por lo tanto, sería posible definir unatransformación base común para todos los lenguajes y refinarlo con transformaciones par-ciales que incorporan características específicas del lenguaje de destino, permitiéndonosla reutilización de código. Eso es lo que en este trabajo de denomina como refinamientode transformaciones de modelo a texto.

6.3. Refinamiento de transformaciones de modelo a texto

Se ha introducido el refinamiento de transformaciones de modelo en nuestro caso deestudio con el objetivo de personalizar las transformaciones dependiendo de las diferentesnecesidades de variabilidad. Se ha incorporado la variabilidad a las transformaciones demodelo a texto para generar código en diferentes lenguajes, en este caso Java y Ada.

En nuestro ejemplo se ha definido una transformación base con los elementos comu-nes de una estructura switch que se pueden encontrar en todos los lenguajes. Después se

65


1 <MOFScriptModel : M O F S c r i p t S p e c i f i c a t i o n . . . xak : a r t i f a c t =" base . m2t . model . m o f s c r i p t " xak :f e a t u r e =" b a s e T r a n s ">

2 < t r a n s f o r m a t i o n l i n e ="6" name=" b a s e T r a n s f " xak : module =" t r a n s M o d u l e ">3 < v a r i a b l e s l i n e ="7" column ="2" name=" o u t p u t F i l e " t y p e =" S t r i n g " xak : module ="

oF i l eModu le " / >4 < p a r a m e t e r s l i n e ="6" column ="39" name=" sc " t y p e =" h t t p : / / www. w3 . org / 2 0 0 5 / 0 7 / scxml " / >5 <!−−C o n t e n t o m i t t e d−−>6 < t r a n s f o r m a t i o n r u l e s l i n e ="64" name=" w r i t e S w i t c h S t a r t " xak : module =" s w i t c h S t a r t M o d u l e

">7 < c o n t e x t l i n e ="64" name=" s e l f " t y p e =" module " / >8 </ t r a n s f o r m a t i o n r u l e s >9 <!−−C o n t e n t o m i t t e d−−>

10 </ t r a n s f o r m a t i o n >11 </ MOFScriptModel : M O F S c r i p t S p e c i f i c a t i o n >

Figura 6.3: Transformación base (representación XMI)

ha definido un refinamiento asociado a cada lenguaje de destino. Este refinamiento añadelos elementos específicos de cada lenguaje de destino a la transformación base.

6.3.1. Transformación base

Utilizando el lenguaje MOFScript se ha definido una transformación base (ver Figura6.2). Esta transformación recibe el modelo de un diagrama de estados como entrada ygenera una estructura switch como salida. Esta transformación sólo define los elementoscomunes en la estructura switch de todos los lenguajes, ya que hay elementos que difierensegún el lenguaje.

En este ejemplo, la transformación base define unas reglas comunes para generar unaestructura switch desde un diagrama de estados. Han sido definidas reglas para generartexto en el fichero de salida (e.g. writeCase), pero en la transformación base están vacíasdebido a que su contenido varía dependiendo de la sintaxis del lenguaje de destino. Tam-bién se define en la transformación una variable llamada outputFile, para especificar elnombre del fichero de salida, pero no se le asigna ningún valor, puesto que dependerá dellenguaje de destino. Esta asignación se realizará con un refinamiento.

MOFScript permite representar una definición de transformación como un modeloque conforma al metamodelo de MOFScript. La Figura 6.3 muestra esta representaciónutilizando XML Metadata Interchange (XMI). Esta representación es equivalente a la re-presentación textual presentada en la figura 6.2. La transformación está definida con el ele-mento <transformation>. Anidados a este elemento se encuentran los distintos elemen-tos de los que se compone una transformación, que son variables, parámetros y reglas, yque se definen con los elementos <variables>, <parameters> y <transformationrules>,respectivamente.

Esta transformación base no puede ser ejecutada, ya que no está completa. Necesita

66


1 <xak : r e f i n e s xak : a r t i f a c t =" base . m2t . model . m o f s c r i p t " xak : f e a t u r e =" a d a D e l t a " . . . >2 <xak : e x t e n d s xak : module =" oFi l eModule ">3 <xak : s u p e r xak : module =" oFi l eModule " / >4 < v a l u e x s i : t y p e =" MOFScriptModel : L i t e r a l " v a l u e =" example . adb " / >5 </ xak : e x t e n d s >6 <xak : e x t e n d s xak : module =" s w i t c h S t a r t M o d u l e ">7 <xak : s u p e r xak : module =" s w i t c h S t a r t M o d u l e " / >8 < s t a t e m e n t s x s i : t y p e =" MOFScriptModel : P r i n t S t a t e m e n t ">9 < p r i n t B o d y x s i : t y p e =" MOFScriptModel : L i t e r a l " v a l u e =" c a s e s t a t e i s
&# x9 ;&# x9

; " / >10 </ s t a t e m e n t s >11 < b l o c k s s t a t e m e n t s = " / / @ t r a n s f o r m a t i o n . 0 / @ t r a n s f o r m a t i o n r u l e s . 3 / @s ta t emen t s . 0 "

p r o t e c t e d =" t r u e " / >12 </ xak : e x t e n d s >13 <!−−C o n t e n t o m i t t e d−−>14 </ xak : r e f i n e s >

Figura 6.4: Refinamiento para Ada con XAK

ser refinada para cada lenguaje de salida.

6.3.2. Refinamiento

Un refinamiento puede considerarse como una función que toma un artefacto comoentrada, y devuelve otro artefacto similar que ha sido refinado para soportar una deter-minada característica (Batory et al., 2004). En nuestro caso de estudio se da soporte a lavariabilidad mediante la herramienta XAK.

XAK es un lenguaje para definir refinamientos en documentos XML que disponetambién de una herramienta para componer los refinamientos (Anfurrutia et al., 2007). Ennuestro caso de estudio XAK ha sido utilizado para representar y componer refinamientosde transformaciones basadas en MOFScript. Como ya se ha comentado, MOFScript ofre-ce la opción de representar una transformación como modelo, cuyo representación está enXMI. Al ser XMI un tipo de fichero XML, es posible utilizar XAK para el refinamientode transformaciones.

Con XAK se pueden definir un documento base y varios refinamientos, que serán com-puestos con el documento base, dando como resultado documentos refinados. Cualquierdocumento XML puede ser un documento base, pero es necesario añadir algunas anota-ciones adicionales (ver Figura 6.3). Se añaden los atributos xak:artifact y xak:feature

al elemento raíz del documento. El primero especifica el nombre del documento que serárefinado, mientras el segundo especifica el componente (“base” para el documento base).Se utiliza el atributo xak:module para especificar que elementos pueden ser refinados. Esdecir, los elementos etiquetados con este atributo, son considerados módulos, que pue-den ser refinados mediante un refinamiento. Normalmente cada módulo tiene un nombre

67


1 <MOFScriptModel . . . >2 < t r a n s f o r m a t i o n . . . >3 < v a r i a b l e s . . . >4 < v a l u e v a l u e =" example . adb " . . . / >5 </ v a r i a b l e s >6 <!−−C o n t e n t o m i t t e d−−>7 < t r a n s f o r m a t i o n r u l e s . . . >8 < c o n t e x t . . . / >9 < s t a t e m e n t s . . . >

10 < p r i n t B o d y v a l u e =" c a s e s t a t e i s
&# x9 ;&# x9 ; " . . . / >

11 </ s t a t e m e n t s >12 < b l o c k s . . . / >13 </ t r a n s f o r m a t i o n r u l e s >14 <!−−C o n t e n t o m i t t e d−−>15 </ t r a n s f o r m a t i o n >16 </ MOFScriptModel . . . >

(a)

1 /∗∗2 ∗ T r a n s f o r m a t i o n G e n e r a t e d by

MOFScript2Text t r a n s f o r m a t i o n3 ∗ /4 t e x t t r a n s f o r m a t i o n b a s e T r a n s f ( i n sc : "

h t t p : / / www. w3 . org / 2 0 0 5 / 0 7 / scxml " ) {5 v a r o u t p u t F i l e : S t r i n g = " example .

adb " ;67 /∗ C o n t e n t o m i t t e d ∗ /89 module : : w r i t e S w i t c h S t a r t ( ) {

10 " c a s e s t a t e i s \ n "11 }1213 /∗ C o n t e n t o m i t t e d ∗ /14 }

(b)

Figura 6.5: Composición de la transformación: (a) representación XMI; (b) representacionMOFScript

único.

Los documentos de refinamiento son los que refinan los documentos base, y estándefinidos bajo el elemento <xak:refines> (ver Figura 6.4). Su contenido describe losrefinamientos de los módulos (elementos anotados con xak:module) para extender el do-cumento base. El nodo xak:super indica dónde tiene que ser puesto el contenido originaldel módulo. En general un refinamiento XAK contiene varios refinamientos de módulos.

Los elementos de la transformación que tienen que ser refinados tienen que ser pri-mero definidos como módulos de refinamiento. En nuestro ejemplo estos elementos sonla transformación, las variables y las reglas. Es decir, podemos añadir nuevos elementoscomo variables o reglas a la transformación, podemos añadir valores a las variables yadefinidas, o podemos extender las reglas ya existentes. Para eso se ha añadido el atributoxak:module a los elementos definidos como <transformation>, <transformationrules>y <variables> (ver Figura 6.3).

La Figura 6.4 muestra un refinamiento para la transformación base. Este refinamientorefina la transformación base con el objetivo de extender éste con los elementos necesariospara generar código en el lenguaje Ada. Algunas reglas son refinadas para generar códigoespecífico para Ada, y se le asigna un valor a la variable outputFile. Es necesario unrefinamiento distinto para cada lenguaje de salida. Una vez definido el refinamiento, hayque componerlo con la transformación base.

68


1 case s t a t e i s2 when s C l o s e d =>3 i f isWarm then4 s t a t e := sOpened ;5 end i f ;6 when sOpened =>7 i f i s C o o l then8 s t a t e := s C l o s e d ;9 end i f ;

10 when o t h e r s =>11 end case ;

(a)

1 sw i t ch ( s t a t e ) {2 case s C l o s e d :3 i f ( isWarm ) {4 s t a t e = sOpened ;5 }6 break ;7 case sOpened :8 i f ( i s C o o l ) {9 s t a t e = s C l o s e d ;

10 }11 break ;12 d e f a u l t :13 }

(b)

Figura 6.6: Código generado: (a) Ada; (b) Java

6.3.3. Composición de la base y el refinamiento

La composición de la transformación base con el refinamiento se hace mediante laherramienta que XAK ofrece para ello. Se pueden componer los distintos artefactos conel siguiente comando:

>xak -xak2 -c baseTrans.mofscript adaDelta.xak -o composedAdaTrans.mofscript

El resultado de la composición es el modelo refinado de la transformación, que semuestra en la Figura 6.5a. Este modelo puede ser ejecutado directamente, o puede serconvertido en un fichero de MOFScript (ver Figura 6.5b). Obsérvese que algunas reglasque carecían de contenido en la transformación base, especifican ahora cómo será el có-digo Ada que generarán. La aplicación de esta transformación al modelo de control detemperatura presentado en la Figura 6.1 genera el fichero example.adb, cuyo contenidoes la representación en Ada de nuestro diagrama de estados y se muestra en la Figura 6.6a.

También se puede refinar la transformación base para que genere código Java. En estecaso las reglas tendrían que ser refinadas para generar texto de acuerdo con la sintaxis deJava. Además, al ser las sentencias break; necesarias en Java, habría que añadir una nuevaregla a la transformación que sería llamada desde la regla generateSwitchCases, que asu vez tendría que ser refinada para añadirle la nueva sentencia. La Figura 6.6b muestrael código generado al ejecutar la transformación refinada para Java.

El uso de refinamientos en el contexto de las transformaciones de modelo permite lareutilización y la personalización que las líneas de producto software promueven.

69


6.4. Trabajo relacionado

La combinación del MDD con las SPL no es algo nuevo, y existen varios ejemplosde ello (Czarnecki & Antkiewicz, 2005b,a; Deelstra et al., 2003; Gonzalez-Baixauli et al.,2005; Gray & et al., 2004; Schmidt et al., 2005; Webber & Gomaa, 2004). Existe una líneade trabajo en torno a la composición de modelos basado en features. MDD orientado afeatures es una propuesta que relaciona la composición de diferentes componentes con elMDD (Trujillo et al., 2007). El trabajo reciente de Apel propone la superimposición comotécnica de composición de modelos para dar soporte a la variabilidad en las líneas de pro-ducto (Apel et al., 2009). FeatureMapper es otra herramienta que combina la variabilidadcon el MDD (Heidenreich et al., 2008). Ninguno de los trabajos anteriores contempla lacomposición de transformaciones o metamodelos.

Sanchez-Cuadrado presenta una propuesta para la reutilización de las transformacio-nes definidas con RubyTL (Sanchez-Cuadrado & Molina, 2008). Aún así no incorpora elconcepto de familia de productos. ATL también ofrece la superimposición como técnicade reutilización de código, pero éste no tiene relación con las lineas de producto (Jouault& Kurtev, 2005). Oldevik propone una solución basada en aspectos extendiendo el len-guaje MOFScript, y que lo denomina como Higher Order Transformations (Oldevik &Haugen, 2007).

6.5. Conclusiones

En este capítulo se ha presentado una solución para introducir la variabilidad a lastransformaciones de modelo a texto definidas con MOFScript en un escenario de línea deproducto software. La contribución principal ha sido la de aplicar el denominado step-wise-refinement en el contexto de las transformaciones de modelo a texto.

Mediante este trabajo se defiende la necesidad de extender la variabilidad en el MDDmás allá de los modelos, analizando su impacto también en los metamodelos y en lastransformaciones de modelos. Así pues, el esfuerzo actual se dirige a analizar el impactode la variabilidad tanto en modelos, metamodelos o transformaciones, y la relación de lavariabilidad de unos con la de otros.

70

Capítulo 7

Gestión del proyecto

Al igual que pasa con muchos proyectos de todo tipo, la planificación final de esteproyecto se ha visto alterada respecto a su planificación inicial detallada en el Documentode Objetivos del Proyecto (ver Capítulo 2).

Desde el principio del proyecto se decidió que éste sería un proyecto abierto quepodría sufrir cambios de rumbo. La mayor alteración en la planificación del proyecto hasido causada por la decisión de dedicar parte del proyecto a la investigación. Una vezempezado el proyecto se llegó a la conclusión de que podría ser más interesante dedicarlos meses finales del proyecto a la investigación en vez de al desarrollo de un prototipodemostrador.

La investigación se ha dirigido a analizar cómo afecta la variabilidad en el MDD ypresentar soluciones para aplicar la variabilidad a los distintos elementos que participanen el MDD.

La decisión de cambiar los objetivos del proyecto se tomó por parte del alumno y eltutor de la empresa, y fue el interés del alumno de conocer el mundo de la investigaciónlo que empujó a ello. Tal y como se mostrará a continuación, este cambio de rumbo hagenerado alteraciones en la planificación del proyecto.

7.1. EDT inicial vs EDT final

Al cambiar uno de los objetivos del proyecto, también han tenido que ser modificadasalgunas de las tareas. En la Figura 7.1 se muestra el diagrama de la estructura de des-composición de trabajo final. Es posible apreciar algunos cambios respecto al diagramamostrado en el documento de objetivos del proyecto (Figura 2.1).

Por un lado, en el diagrama de la Figura 7.1 se han suprimido todas las tareas vin-

71

CAPÍTULO 7. GESTIÓN DEL PROYECTO

Figura 7.1: Diagrama EDT final

culadas al desarrollo de un prototipo demostrador. Este cambio ha sido causado por lamodificación de la lista de objetivos, del cual se ha suprimido el de desarrollar un proto-tipo demostrador a favor de dedicarle tiempo a la investigación.

Por otro lado, se han añadido la tarea relacionada a la investigación y sus subtareas enel diagrama EDT final. El proyecto ha tenido un nuevo objetivo, que es investigar cómopuede afectar la variabilidad a los distintos elementos relacionados al MDD y presentaralguna solución para introducir la variabilidad en los metamodelos y las transformacionesde modelos. Se ha definido una tarea general, con tres subtareas:

Análisis del estado del arte: análisis del trabajo realizado hasta el momento eneste tema.

Desarrollo de ideas: desarrollo de ideas para avanzar en el tema y definición deejemplos para mostrar soluciones

Redacción de artículos: redacción de artículos de investigación presentando lassoluciones ideadas.

7.2. Estimación de recursos inicial vs recursos invertidos

A continuación se realiza una comparación entre la planificación inicial del proyectoy la planificación real del mismo. El cambio de objetivos del proyecto ha causado altera-ciones tanto en el tiempo destinado a cada tarea como en el diagrama de Gantt.

72

7.2. ESTIMACIÓN DE RECURSOS INICIAL VS RECURSOS INVERTIDOS

Tabla 7.1: Tabla comparativa de horas planificadas frente a horas invertidas

7.2.1. Tabla de recursos

En la Tabla 7.1 se muestra una comparativa entre las horas planificadas para cada tareaal inicio del proyecto, y las horas reales dedicadas finalmente.

Es posible apreciar que el tiempo total del proyecto no ha sufrido grandes cambiosentre lo planificado y lo invertido. Ésto tiene su lógica, ya que al realizar el proyectoen una empresa, éste tiene un calendario ya establecido. En el caso de este proyecto laduración del mismo ya estaba establecida desde el principio y se ha ajustado su alcanceal tiempo disponible.

Aún así el tiempo dedicado a cada tarea sí ha sufrido bastantes cambios. El tiempodedicado a la gestión del proyecto y al cierre del mismo se han mantenido, pero en lasdemás tareas el tiempo real ha sido mayor de lo estimado. Esto no ha sido causado nece-sariamente por una mala estimación, sino por la disponibilidad de más tiempo, lo que haposibilitado profundizar más en esas tareas.

Lo que ha posibilitado dedicar más tiempo a algunas de las tareas ha sido el cambiode objetivos del proyecto. El tiempo dedicado a la investigación ha sido menor al tiempoestimado para el desarrollo del prototipo demostrador.

La Tabla 7.1 muestra detalladamente el tiempo dedicado a cada tarea y sus subtareas.

73

CAPÍTULO 7. GESTIÓN DEL PROYECTO

Figura 7.2: Diagrama de Gantt real

7.2.2. Diagrama de Gantt real

En el Capítulo 2 se mostraba la planificación inicial del proyecto mediante un diagra-ma de Gantt (ver Figura 2.2). En la Figura 7.2 se puede apreciar que esa planificacióninicial ha sufrido varios cambios.

En el diagrama de Gantt real están reflejadas las nuevas tareas introducidas. Ademásen este diagrama es posible apreciar que algunas de las tareas se han alargado en el tiempo,y otras han sido divididas en diferentes espacios de tiempo. Esto último se ha producidoporque no se han analizado todas las herramientas al mismo tiempo. Durante todo elproyecto se han ido introduciendo y probando nuevas herramientas y definiendo nuevosejemplos para analizar sus capacidades y limitaciones.

74

Capítulo 8

Conclusiones

En este capítulo se presentan las contribuciones realizadas en este proyecto. Se des-criben las conclusiones tanto generales como personales obtenidas durante la realizacióndel proyecto y se indica un posible rumbo a seguir en el futuro.

8.1. Contribución

En este trabajo se han realizado algunas contribuciones técnicas por una parte, y cien-tíficas por otra.

Entre las contribuciones técnicas está el análisis de diversas herramientas para trabajarcon lenguajes específicos de dominio en el ámbito del desarrollo dirigido por modelos.Se ha analizado una serie de herramientas con el fin de realizar una comparación de susposibilidades y limitaciones. Como resultado del análisis se han obtenido conclusionessobre qué herramienta ofrece una mejor solución en cada tarea, desde la definición demetamodelos hasta la generación de código, y se han definido unos aspectos a compararen la elección de una herramienta. También se ha analizado la utilidad de usar DSL frentea lenguajes de propósito general.

En cuanto a contribuciones científicas se refiere, durante el proyecto se ha analizadocómo aplicar la variabilidad a los distintos elementos que forman parte del MDD. Eneste sentido se ha definido una solución para aplicar la idea de las líneas de productosoftware al MDD aplicando la variabilidad más alla de los modelos. Como resultadode esta investigación se han escrito varios artículos donde se aplica la variabilidad a lastransformaciones y a los metamodelos aparte de los modelos:

Trujillo S., Zubizarreta A., De Sosa J. & Mendialdua X. (2009). Is Model VariabilityEnough? 1st International Workshop on Model-Driven Product Line Engineering

75

CAPÍTULO 8. CONCLUSIONES

(MDPLE 2009) Twente, The Netherlands.

Trujillo S., Zubizarreta A., De Sosa J. & Mendialdua X. (2009). On the Refine-ment of Model-to-Text Transformations. XIV Jornadas de Ingeniería del Software

y Bases de Datos (JISBD 2009) Donostia-San Sebastián

Trujillo S. & Zubizarreta A. (2009). Lock-Step Refinement of Models, Metamodelsand Model Transformations in Model-Driven Product-Lines. Borrador.

8.2. Conclusiones

8.2.1. Conclusiones generales

El desarrollo de software dirigido por modelos es una disciplina en auge en el ámbi-to del desarrollo de software. Aunque no sea una técnica ampliamente utilizada, ofrecemultitud de ventajas respecto al desarrollo tradicional.

Los modelos pasan de ser elementos de diseño o documentación, a ser la verdaderabase del desarrollo. Los modelos permiten trabajar a un mayor nivel de abstracción. Uti-lizar los modelos para la generación automática de código ahorra tareas tediosas comola de escribir el código, especialmente cuando se trata de código repetitivo y previene lainserción de errores. La generación de código a partir de modelos requiere escribir lastransformaciones de modelo a texto. Esta tarea puede entrañar cierta dificultad inicial, pe-ro una transformación bien definida permitirá reflejar automáticamente en el código finalcualquier cambio que realizado en el diseño del software. Si se introduce algún cambio enel modelo que implique cambiar el código en distintos puntos del software, se ahorra eltener que implementar los cambios de forma manual, que además de que pueda requerirmucho tiempo, el el código a mano puede inducir a cometer errores.

Aunque el concepto de los lenguajes específicos de dominio no sea nuevo, con el augedel MDD están cogiendo cada vez más importancia. La combinación del MDD con losDSL permite elevar aún más el nivel de abstracción a la hora de desarrollar software.Los DSL, tanto de modelado como de texto, permiten trabajar en términos del dominiodel problema, y aunque esto requiera un análisis exhaustivo del dominio al principio,facilita el aprendizaje por parte de las personas relacionadas con el dominio. Diseñar unlenguaje específico de dominio puede ser complicado, pero el ahorro de tiempo duranteel desarrollo puede ser considerable si el desarrollador trabaja en términos conocidospor él, modelando los programas usando conceptos de su dominio y generando códigoautomáticamente a partir de los modelos.

76

8.2. CONCLUSIONES

Añadir a todo lo anterior la idea de líneas de producto software, permite la reutili-zación de los modelos a la hora de trabajar con familias de programas. La composiciónde los modelos nos permite tener una parte del modelo común para todos los modelos,teniendo que modelar solo las partes específicas de cada producto en cada caso. Esta ideano es solo aplicable a los modelos, también podemos tener familias de transformacionesque podrán ser reutilizadas para la generación de los distintos productos. Por ejemplo a lahora de generar código en distintos lenguajes de programación desde un mismo modelo,se puede crear una transformación común para todos los lenguajes, y componerlo con suscaracterísticas específicas en cada caso.

Como conclusión general se puede decir que la tendencia es la de escribir cada vezmenos código a mano, y trabajar a mayores niveles de abstracción. El objetivo puedeser la generación automática de todo el código de implementación, limitando la escrituramanual de código a escribir las transformaciones, pero intentando que la escritura manualsea mínima, mediante técnicas de reutilización. En este proyecto se ha analizado cómohacerlo mediante la combinación de MDD, DSL y SPL, y los resultados sugieren que esun buen camino a seguir.

8.2.2. Conclusiones personales

En cuanto a conclusiones personales se refiere, se puede decir que este proyecto hacontribuido de distintas formas en la formación del alumno.

Por una parte, y en cuanto al contenido del proyecto se refiere, se ha trabajado en temasque pueden ser muy útiles en el futuro y que no han sido impartidos durante la carrera.Desde el principio del proyecto casi todo ha sido “nuevo” para el alumno, lo que hasuscitado un mayor interés en el tema. El aprendizaje de la gran variedad de herramientastambién puede servir de gran ayuda.

Por otra parte, el proyecto también ha tenido su parte de investigación. Gracias a estoel alumno ha podido conocer un poco ese mundo. El hecho de realizar trabajo de inves-tigación y escribir varios artículos para distintas conferencias ha sido muy gratificante,aunque en algunos momentos no haya rusultado una labor nada fácil.

Para finalizar, comentar que el entorno de trabajo también ha ayudado mucho. Eldesarrollar el proyecto en una empresa ha ayudado al alumno a ver cómo se trabaja enel entorno laboral, y haberlo hecho en un centro de investigación ha resultado aún másinteresante. El ambiente de trabajo ha sido muy bueno, la relación con los compañerosde trabajo excelente, y ni qué decir de la ayuda recibida por el tutor. La dinámica detrabajo ha sido muy buena, y la implicación del tutor en el proyecto muy grande, lo que

77

CAPÍTULO 8. CONCLUSIONES

ha influido muy positivamente en su realización.La sensación final es la de haber aprendido mucho, por lo que se puede decir que el

proyecto ha cumplido con su objetivo en ese sentido.

8.3. Trabajo futuro

Aunque el MDD se vaya implantando poco a poco, todavía queda mucho caminopor recorrer. Existen ejemplos exitosos de grandes proyectos llevados a cabo siguiendoese paradigma, pero su implantación masiva no parece que se vaya a dar a corto plazo.En este sentido, para que estas técnicas se implanten, es muy importante disponer deherramientas que den soporte al MDD. Existen herramientas que dan buen soporte parala creación de DSL, pero no para la generación de código. También las hay las que dangran soporte a la generación de código, pero en cambio no permiten trabajar con DSL. Ytambién las hay que ofrecen un poco de cada uno. El trabajo futuro debe estar centradoen crear herramientas que den un buen soporte al MDD.

Una herramienta que ofrezca un buen soporte para la creación de DSL gráficos, quepermitan “dibujar” el software en términos del dominio, y que permita una fácil transfor-mación de los modelos en texto, tanto código de implementación como documentaciónpuede ser el primer objetivo a conseguir.

Lo siguiente sería dar soporte a la variabilidad. Esto ya se ha hecho en este proyecto,pero para la implantación masiva de esta técnica, sería necesario que esto fuera más fácilpara el usuario.

En este trabajo, donde se ha trabajado con la variabilidad se ha combinado el MDDcon el Feature Oriented Programming (FOP). También existen trabajos donde se com-binan el MDD y el Aspect Oriented Programming (AOP). Podría ser interesante, en unfuturo, trabajar en la combinación de los tres paradigmas, MDD con FOP y AOP, sacandoprovecho de lo mejor de cada uno.

Otro aspecto que se podría trabajar es la generación automática de las propias trans-formaciones. Es decir, diseñar las transformaciones modelándolas y generar su códigoautomáticamente a partir de los modelos.

Como se puede ver, éste es un tema donde todavía queda mucho por hacer, pero queestá cogiendo fuerza, y donde seguramente se podrán ver muchos avances a corto plazo.

78

Bibliografía

Anfurrutia, F. I., Díaz, O., & Trujillo, S. (2007). On Refining XML Artifacts. In ICWE

(pp. 473–478).

Apel, S., Janda, F., Trujillo, S., & Kaestner, C. (2009). Model Superimposition in Softwa-re Product Lines. In 2nd International Conference on Model Transformations (ICMT

2009), Zurich, Switzerland, June.

Apel, S., Kästner, C., Kuhlemann, M., & Leich, T. (2007). Pointcuts, advice, refinements,and collaborations: similarities, differences, and synergies. Innovations in Systems and

Software Engineering, 3(4), 281–289.

Azanza, M., Batory, D., Diaz, O., & Trujillo, S. (2009). Metamodel-guided Compositionin Model Driven Product Lines. In Draft under Review.

Batory, D., Sarvela, J., & Rauschmayer, A. (2004). Scaling Step-Wise Refinement. IEEE

Transactions on Software Engineering (TSE), 30(6), 355–371.

Beuche, D. (2003). Composition and Construction of Embedded Software Families. PhDthesis, School of Computer Sciences, University of Magdeburg, Magdeburg, Germany.http://www-ivs.cs.uni-magdeburg.de/ danilo.

Bézivin, J. (2005). On the Unification Power of Models. Software and Systems Modeling,4(2), 171–188.

Bézivin, J., Dupe, G., Jouault, F., Pitette, G., & Rougui, J. E. (2003). First Experimentswith the ATL Model Transformation Language: Transforming XSLT into XQuery. In2nd OOPSLA Workshop on Generative Techniques in the context of MDA, Anaheim,

California, USA, Oct 27.

BigLever (2008). BigLever Software Gears. http://www.biglever.com/solution/solution.html.

79

BIBLIOGRAFÍA

Budinsky, F., Steinberg, D., Ellersick, R., Grose, T. J., & Merks, E. (2003). Eclipse Mo-

deling Framework: a Developer’s Guide. Addison-Wesley.

Clements, P. & Northrop, L. (2001). Software Product Lines - Practices and Patterns.Addison-Wesley.

Cook, W. R., Delaware, B., Finsterbusch, T., Ibrahim, A., & Wiedermann, B. (2009).Strategic programming by model interpretation and partial evaluation. (submitted forpublication to icse.

Cuadrado, J. S. & Molina, J. G. (2007). Building Domain-Specific Languages for Model-Driven Development. IEEE Software, 24(5), 48–55.

Cuadrado, J. S., Molina, J. G., & Tortosa, M. M. (2006). RubyTL: A Practical, ExtensibleTransformation Language. In 2nd European Conference on Model Driven Architecture

- Foundations and Applications (ECMDA-FA 2006), Bilbao, Spain, Jul 10-13 (pp. 158–172).

Czarnecki, K. & Antkiewicz, M. (2005a). Mapping Features to Models: A TemplateApproach Based on Superimposed Variants. In 4th International Conference on Gene-

rative Programming and Component Engineering (GPCE 2005), Tallinn, Estonia, Sep

29 - Oct 1.

Czarnecki, K. & Antkiewicz, M. (2005b). Model-Driven Software Product-Lines. In20th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems,

Languages, and Applications (OOPSLA 2005), San Diego, CA, USA, Oct 16-20.

Deelstra, S., Sinnema, M., van Gurp, J., & Bosch, J. (2003). Model Driven Architectureas Approach to Manage Variability in Software Product Families. In Workshop on

Model Driven Architecture: Foundations and Applications (MDAFA), Enschede, The

Netherlands, June 26-27.

DSM-Forum (2008). DSM Case Studies and Examples.http://www.dsmforum.org/cases.html.

Eclipse (2009). Eclipse Modeling Framework (EMF). http://www.eclipse.org/emf/.

Ehrig, H., Ehrig, K., de Lara, J., Taentzer, G., Varró, D., & Varró-Gyapay, S. (2005).Fundamental Approaches to Software Engineering, chapter Termination Criteria forModel Transformation, (pp. 49–63).

80

BIBLIOGRAFÍA

Friedenthal, S., Moore, A., & Steiner, R. (2008). OMG Systems Modeling Language(OMG SysML) Tutorial. INCOSE 2008.

Gonzalez-Baixauli, B., Laguna, M., & Crespo, Y. (2005). Product Lines, Features, andMDD. In 1st Europeean Workshop on Model Transformation (SPLC-EWMT’05), Ren-

nes, France, Sep 25.

Gray, J. & et al. (2004). Model Driven Program Transformation of a Large Avionics Fra-mework. In 3th International Conference on Generative Programming and Component

Engineering (GPCE 2004), Vancouver, Canada, Oct 24-28.

Greenfield, J., Short, K., Cook, S., & Kent, S. (2004). Software Factories: Assembling

Applications with Patterns, Models, Frameworks, and Tools. Wiley.

Heidenreich, F., Kopcsek, J., & Wende, C. (2008). FeatureMapper: Mapping Featuresto Models. In 30th International Conference on Software Engineering (ICSE 2008),

Companion (pp. 943–944). New York, NY, USA: ACM.

Herst, D. & Roman, E. (2003). Model Driven Development for J2EE Utilizing a Model

Driven Architecture (MDA) - Approach: A Productivity Analysis. Technical report,TMC Research Report.

Hudak, P. (1996). Building Domain-Specific Embedded Languages. ACM Computing

Surveys, 28, 196.

Jouault, F. & Kurtev, I. (2005). Transforming Models with the ATL. In International

Conference on Model Driven Engineering Languages and Systems (MODELS 2005).

Kang, K. C. & et al. (1990). Feature Oriented Domain Analysis Feasability Study. Tech-nical Report CMU/SEI-90-TR-21, Software Engineering Institute.

Kelly, S. & Tolvanen, J. (2008). Domain-specific modeling: enabling full code generation.Wiley-IEEE Computer Society Pr.

Kern, H. (2008). The Interchange of (Meta)Models between MetaEdit+ and Eclipse EMFUsing M3-Level-Based Bridges.

Kontio, M. (2005). Architectural Manifesto: The MDA Adoption Manual. http://www-128.ibm.com/developerworks/wireless/library/wi-arch17.html.

Krueger, C. W. (2008). Software Product Lines. http://www.softwareproductlines.com/.

81

BIBLIOGRAFÍA

Kurtev, I. (2005). Adaptability of Model Transformations. PhD thesis, University ofTwente.

Kurtev, I., Bézivin, J., Jouault, F., & Valduriez, P. (2006). Model-based DSL Frame-works. In OOPSLA ’06: Companion to the 21st ACM SIGPLAN symposium on Object-

oriented programming systems, languages, and applications (pp. 602–616). New York,NY, USA: ACM.

Marwedel, P. (2006). Embedded System Design. Birkhäuser, 2 edition.

Mernik, M., Heering, J., & Sloane, A. M. (2005). When and How to Develop Domain-Specific Languages. ACM Comput. Surv., 37(4), 316–344.

MetaCase (2007). Nokia Case Study: MetaEdit+ revolutionized the way Nokia developsmobile phone software. http://www.metacase.com/papers/MetaEdit_in_Nokia.pdf.

MetaCase (2009). MetaEdit+ Domain-Specific Modeling (DSM) environment.http://www.metacase.com/products.html.

Oldevik, J. & Haugen, O. (2007). Higher-Order Transformations for Product Lines. Soft-

ware Product Line Conference, International, 0, 243–254.

OMG (2003). MDA Guide version 1.0.1. OMG document 2003-06-01.

OMG (2005). Unified Modeling Language (UML), version 2.0.http://www.uml.org/#UML2.0.

OMG (2006). MetaObject Facility (MOF) Core Specification version 2.0. OMG docu-ment 2006-01-01.

OMG (2007). OMG. XML Metadata Interchange (XMI) Mapping Specification, version2.1. http://www.omg.org/technology/documents/formal/xmi.htm.

OMG (2008a). OMG Systems Modeling Language. http://www.omgsysml.org/.

OMG (2008b). Software Process Engineering Meta-Model, Version 2.0.http://www.omg.org/technology/documents/formal/spem.htm.

OMG (2009). MDA Success Stories. http://www.omg.org/mda/products_success.htm.

Pohl, K., Bockle, G., & van der Linden, F. (2006). Software Product Line Engineering -

Foundations, Principles and Techniques. Springer.

82

BIBLIOGRAFÍA

Sanchez-Cuadrado, J. & Molina, J. G. (2008). Approaches for Model TransformationReuse: Factorization and Composition. In International Conference of Model Trans-

formations (ICMT).

Schmidt, D., Nechypurenko, A., & Wuchner, E. (2005). MDD for Software Product-Lines: Fact or Fiction. In Workshop at 8th International Conference on Model Driven

Engineering Languages and Systems (MoDELS 2005), Montego Bay, Jamaica, Oct 2-7,

2005.

Sendall, S. & Kozaczynski, W. (2003). Model Transformation: The Heart and Soul ofModel-Driven Software Development. IEEE Software, 20(5), 42–45.

Simon, D. E. (1999). An Embedded Software Primer. Addison-Wesley, 12 edition.

SINTEF (2009). MOFScript. http://www.eclipse.org/gmt/mofscript/about.php.

Sánchez, P., Loughran, N., Fuentes, L., & Garcia, A. (2009). Engineering Languages forSpecifying Product-Derivation Processes in Software Product Lines. (pp. 188–207).

Sánchez-Barbudo, A., Sánchez, E. V., Roldán, V., Estévez, A., & Roda, J. (2008). Pro-viding an Open Virtual-Machine-based QVT Implementation. In Proceedings of the V

Workshop on Model-Driven Software Development. MDA and Applications (DSDM’08

- XIII JISBD).

Sodius (2009a). MDWorkbench 3.0. http://www.mdworkbench.com/index.php.

Sodius (2009b). Rhapsody add-on for RulesComposer.http://addons.rulescomposer.com/.

Sommerville, I. (2007). Software Engineering. Pearson Education.

Trask, B. & Roman, A. (2008). Leveraging Model Driven Engineering in Software Pro-duct Line Architectures. In SPLC ’08: Proceedings of the 2008 12th International

Software Product Line Conference (pp. 373). Washington, DC, USA: IEEE ComputerSociety.

Trujillo, S. (2007). Feature Oriented Model Driven Product Lines. PhD thesis, School ofComputer Sciences, University of the Basque Country. http://www.struji.com.

Trujillo, S., Batory, D., & Díaz, O. (2007). Feature Oriented Model Driven Development:A Case Study for Portlets. In 29th International Conference on Software Engineering

(ICSE 2007), Minneapolis, MN, USA, May.

83

Trujillo, S. & Zubizarreta, A. (2009). Lock-Step Refinement of Models, Metamodels andModel Transformations in Model-Driven Product-Lines. Draft.

Trujillo, S., Zubizarreta, A., de Sosa, J., & Mendialdua, X. (2009a). Is Model VariabilityEnough? In 1st International Workshop on Model-Driven Product Line Engineering

(MDPLE 2009) Twente, The Netherlands.

Trujillo, S., Zubizarreta, A., de Sosa, J., & Mendialdua, X. (2009b). On the Refinement ofModel-to-Text Transformations. In XIV Jornadas de Ingeniería del Software y Bases

de Datos (JISBD 2009) Donostia-San Sebastian.

Vallecillo, A. (2008). A Journey through the Secret Life of Models. In Perspectives

Workshop: Model Engineering of Complex Systems (MECS) Dagstuhl, Germany.

Völter, M. (2008). MD* Best Practices.

Völter, M. & Groher, I. (2007). Handling Variability in Model Transformations and Ge-nerators. In Proc of the DSM Workshop at OOPLSA.

W3C (1999). HTML 4.01 Specification. http://www.w3.org/TR/html401/.

Webber, D. & Gomaa, H. (2004). Modeling Variability in Software Product Lines withthe Variation Point Model. Science of Computer Programming, 53.

Williams, J., Colomb, G., & of Chicago, U. (1990). Style: Toward clarity and grace.University of Chicago Press.

Esker onak

Bizitzako etapa honen azken puntura helduta, nire eskerrik beroenak eman nahi dizkietOscar Diazi eta Salvador Trujillori, proiektu honen garapenean gidatzeagatik eta eman-dako aholku guztiengatik. Eskerrak batez ere Salvari proiektu honetan erakutsitako in-plikazioagatik, eskainitako denbora guztiarengatik, eta ikerketa munduan lehen pausoakematen lagundu izanagatik.

Eskerrak ere Josune de Sosa eta Xabier Mendialduari proiektuan zehar eskainitakolaguntzagatik eta nirekin galdutako denboragatik.

Ikerlaneko nire egonaldia esperientzia oso positibo eta aberasgarria izatea ahalbidetuduten gainerako lankideei ere mila esker.

Eskerrak etapa honetan bidelagun izan ditudan ikaskideei eta hainbat alditan bideazabaltzen laguntzeko prest azaldu direnei.

Eta bukatzeko, nola ez, ezin aipatu gabe utzi familia. Eskerrak eman nahi dizkiet bideluze honetan erakutsitako laguntza eta pazientziagatik, beraiek izan baitira, seguraski,nire momentu txarrrak, haserreak etab. gehien sufritu behar izan dituztenak eta gehienlagundu didatenak.

Eskerrik asko guztioi.

Technology

PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos