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 KODEA
CURSO CÓDIGO

IKASLEA N.A.N.
ALUMNO/A D.N.I.

Reunido el tribunal examinador en el día de la fecha, Egunean bildurik ondorengo partaideek osatutako
constituido por: 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, Horrela ager dadin, eta dagozkion ondorioak sor ditzan,
firmada por todos los comparecientes del tribunal, la bertaraturiko batzordekideek sinatutako ebaluazio-akta
presente acta 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

________________________________ ________________________________ ________________________________

Resumen
Un lenguaje específico de dominio (DSL) es un lenguaje creado para dar solución a
un 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 menos
completos, pero más expresivos, permitiendo un mayor nivel de abstracción.
El desarrollo dirigido por modelos (MDD) es un paradigma para la automatización de
la 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 ser
transformados 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 herramientas
disponibles para trabajar con ellos, mediante casos de estudio. También se muestra cómo
puede 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 xede
orokorreko lengoaiek baino modu argiagoan irudikatzea ahalbidetzen dute. Normalean
sinpleagoak 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 batez
zehaztutako modelo bidez irudikatzen da. Transformazioen erabilerarekin modelo bat
sistema beraren beste modelo batean eraldatu daiteke, sistemaren beste irudikapen bat
izateko, edo inplementazio kodea sor daiteke.
Modelo bidezko software garapenaren eta software produktu lerroen (SPL) arteko
konbinaketarekin 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 MDDaren
arloan 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 other
general purpose languages. They are usually more expressive, allowing a higher level of
abstraction.
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 implementation
code.
The use combination of MDD with software product lines (SPL) introduces variability
to the MDD.
This project analyzes the state of the art of these paradigms and the tools available to
work with them, through case studies. It also shows how the variability can be introduced
to the MDD.

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

Índice general

Índice general I

Índice de ﬁguras V

Índice de tablas VII

1. Introducción 1
1.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 7
2.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 13
3.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 21
4.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 37
5.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 61
6.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 71
7.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 75
8.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) . . . . . . . . . . . . . . . . 66
6.4. Reﬁnamiento para Ada con XAK . . . . . . . . . . . . . . . . . . . . . . 67
6.5. Composición de la transformación . . . . . . . . . . . . . . . . . . . . . 68
6.6. Código generado: (a) Ada; (b) Java . . . . . . . . . . . . . . . . . . . . . 69

7.1. Diagrama EDT ﬁnal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.2. Diagrama de Gantt real . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

VI

Índice de tablas

2.1. Asignación de recursos en la planiﬁcació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 planiﬁcadas 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 y
la metodología utilizada para cumplirlos.

1.1. Contexto
El desarrollo de software ha ido evolucionando, introduciendo nuevos lenguajes y
paradigmas que ofrecen mejoras al desarrollo. Simultáneamente también los lenguajes y
las herramientas de modelado han ido adquiriendo cada vez más importancia. No obstante
estos últimos son muchas veces utilizados como herramientas de documentación y no
como herramientas de diseño de software.
La mayoría de los lenguajes utilizados actualmente en el desarrollo de software, tanto
lenguajes 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 ser
más o menos apropiada en una situación determinada, todos los lenguajes de este tipo
permiten, en general, dar solución a cualquier problema, sin que importe el dominio en el
que se sitúa el mismo.
Aunque los lenguajes hayan ido evolucionando, la forma de desarrollar el software no
ha sufrido grandes cambios. Con la introducción de los lenguajes específicos de dominio
o DSL (Domain Specific Languages) y el desarrollo dirigido por modelos o MDD (Model
Driven Development), se pretende dar un salto cualitativo en la evolución del desarrollo
de 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 de
personas 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 para
diseñ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 ser
representados 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 la
representació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 este
contexto se sitúan las Líneas de Producto Software o SPL (Software Product Lines). Las
SPL permiten la reutilización de código, mediante la definición de distintos componentes
que 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 productos
finales 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ática
el código para una familia de programas para sistemas embebidos a partir de modelos, en
un dominio específico. La utilización del MDD es esencial en el modelado del software
para la posterior generación automática de código, y su combinación con los DSL y la
variabilidad puede ofrecer una solución interesante al problema. Es precisamente esa la
cuestión que se aborda en este trabajo.

1.2. Objetivos

El objetivo principal que persigue el proyecto es analizar los lenguajes específicos de
dominio. 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 sistemas
embebidos. 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 de
software no está muy extendida todavía. Aún así, son conceptos que van adquiriendo
cada vez más importancia, y es por ello por lo que es conveniente conocer qué se ha
hecho y cómo se han utilizado hasta ahora, así como analizar qué herramientas existen en
el mercado para trabajar con ellos. El objetivo es estudiar qué ventajas nos pueden ofrecer
tanto 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ón
automá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 de
modelado diseñados por uno mismo. También existen herramientas que ofrecen ambas
posibilidades.
En este proyecto se plantea analizar una serie de herramientas, tanto comerciales como
de licencia libre, con el objetivo de conocer las capacidades que ofrecen, y comparar las
ventajas y desventajas de cada una de ellas.
También se analiza cómo se puede introducir la variabilidad en el MDD utilizando
alguna 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 que
se persigue en este proyecto es analizar cómo se puede introducir la variabilidad en otros
elementos 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 este
proyecto.
El proyecto empezó a finales de octubre de 2008. En una primera reunión entre el
alumno 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, para
analizar el trabajo realizado y los compromisos a adquirir para la siguiente semana. Tras
cada reunión se redactaba su correspondiente acta.
El primer trabajo tras iniciar el proyecto fue el de documentación. Dada la novedad de
los 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 durante
todo el proyecto.
La lectura acaparó gran parte del tiempo durante el inicio del proyecto (aunque no
haya sido poco el tiempo que se le ha dedicado posteriormente), con el fin de, por una
parte 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 del
arte.
A continuación se procedió a la instalación de diversas herramientas y a aprender a
utilizarlas realizando pequeños ejemplos con ellas. Las primeras herramientas utilizadas
fueron MetaEdit+ y Eclipse Modeling Framework (EMF) para diseñar DSL de modelado.
Posteriormente se utilizaron MDWorkbench, ATL y MOFScript, todas ellas herramientas
para definir transformaciones de modelos. Por último, se ha utilizado la herramienta de
modelado IBM Telelogic Rhapsody, la cual ofrece un potente entorno para el modelado
de 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 modelos
definidos. 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 las
posibilidades que ofrece cada herramienta y hacer un análisis más detallado de cada una
de 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ón
ha sido la introducción de la variabilidad en el MDD. Se ha analizado cómo puede afectar
la 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án
en 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 algunos
conceptos 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 han
analizado y cómo se trabaja con ellas. Seguidamente, se hace una comparativa de los
distintos aspectos de las herramientas y para finalizar se muestra un caso de estudio con
un ejemplo.
En el siguiente capítulo se hace una introducción al MDD. Este cuarto capítulo sigue
la 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ículos
escritos como resultado de la investigación y en él se presenta una solución para aplicar
la variabilidad a las transformaciones de modelo a texto.
En el capítulo 7 se ofrecen detalles sobre la gestión del proyecto, donde se comparan
las alteraciones sufridas en la planificación respecto al plan inicial detallado en el capítulo
2.
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 de
trabajo 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 los
lenguajes específicos de dominio (DSL) y el desarrollo dirigido por modelos (MDD) en
el 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 este
proyecto se analizará cuál es el estado de arte, cómo se han utilizado, los beneficios que
aportan, y sus limitaciones. También se utilizarán varias herramientas para trabajar con
DSL con el objetivo de analizar sus capacidades y limitaciones.
Para analizar la viabilidad de la utilización de DSL en el contexto del proyecto, se
implementará 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ódigo
de 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 ha
realizado en estos áreas y cómo se han utilizado para desarrollar software. Estudiar
sus 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án
desarrollando durante la realización del proyecto:

Entregable: planiﬁcació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 planiﬁcació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 aprender
a utilizar las herramientas.

Definir ejemplos nuevos: definición de un ejemplo para analizar las capacidades y
limitaciones 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 del
proyecto.

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 la
realizació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 del
prototipo demostrador.
Probabilidad: baja
Acciones a llevar a cabo: analizar la posibilidad de usar otra herramienta para
hacer 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 lograr
unos 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 y
alumno. El contacto entre el alumno y el tutor de la empresa sera directo o por correo
electró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 (oscar.diaz@ehu.es)

Tutor en la empresa: Salvador Trujillo (strujillo@ikerlan.es)

Alumno: Ander Zubizarreta (ander.zubizarreta@ikerlan.es)

2.9.2. Reuniones
Cada miércoles se realizará una reunión entre el tutor de la empresa y el alumno con el
objetivo 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, ésta
podrá ser cambiada a otra fecha cercana. Después de cada reunión el alumno redactará su
respectivo acta.

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

12

Capítulo 3

Conceptos básicos

En este capítulo se introducen algunos conceptos básicos que ayudarán a situarnos en
el proyecto. En la primera sección se hace una introducción a los sistemas embebidos. En
la segunda se introduce brevemente la ingeniería de software, describiendo dentro de su
contexto 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” en
una 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 microprocesadores
y su software. Se suele llamar sistema embebido a cualquier sistema de computación que
esté “escondido” dentro de otro producto, es decir, que sea una parte integral del sistema
entero.

3.1.1. Características de los sistemas embebidos
A diferencia de los ordenadores personales, que pueden usarse para una gran variedad
de tareas dependiendo de su programación, los sistemas embebidos suelen ser normal-
mente sistemas creados para un propósito especíﬁco, 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 y
complejos que pueden estar compuestos de varias unidades de procesamiento, periféricos
y 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 o
servidores. Estas son algunas de sus principales características:

Los sistemas embebidos se construyen para un propósito específico, por lo que
normalmente ofrecen un mayor rendimiento en las tareas para las que han sido
diseñ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 por
cuestiones de seguridad o de usabilidad.

Los recursos de hardware son normalmente limitados para reducir costes. Se busca
el 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 (sin
ratón, monitor, teclado...) o muy limitada (LEDs, displays digitales...) en sistemas
simples 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 ellos
mediante una interfaz web a través de una conexión de red (e.g. configuración de
routers).

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 los
siguientes 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 dar
al sistema. Por ejemplo en el sistema de control de una central nuclear lo más importante
puede 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 ser
má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 no
embebidos, y cuáles son los requisitos a seguir a la hora de desarrollar software para
sistemas 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 un
sistema para el control de un aerogenerador, es decir, un sistema embebido en un molino
de 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 molino
y 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 distintos
puntos 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 embebido
en el aerogenerador están el de que tiene que ser un sistema en tiempo real y que tiene
que 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 que
los controle. Grandes infraestructuras, sistema financiero y procesos industriales están
computerizados en su mayor parte. Por eso, la producción y el mantenimiento de software
de calidad a un coste reducido adquiere gran importancia.
La ingeniería de software es la disciplina que trata todos los aspectos relacionados
con 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 mejorar
la productividad durante el desarrollo y la calidad del software, desde hace tiempo se ha
intentado encontrar metodologías que sean sistemáticas, predecibles y repetibles para la
producció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 haya
requisitos incompletos, ambiguos o contradictorios se obtiene como resultado la
Especificación de los Requisitos del Sistema.

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

Diseño y arquitectura: En esta etapa se determina cómo funcionará el sistema de
forma 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 tareas
indicadas 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 cumplir
nuevos requisitos.
Dependiendo del paradigma que se siga, estas fases pueden seguir una orden secuencial o
no. Por ejemplo el desarrollo en cascada define el orden estrictamente secuencial, donde
una 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 medida
de lo posible la producción de software. Con este objetivo se han utilizado diferentes
mé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 del
sistema, como en la fase de documentación, prueba y mantenimiento con herramientas
de 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 de
implementació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 se
centra 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 este
paradigma, a continuación se hace una breve exposición de los elementos que participan
en él.

Modelos: Los modelos son utilizados para representar un sistema. Se utilizan para
ello lenguajes de modelado que normalmente son gráficos, y que pueden ser tanto de
propósito general como específicos de dominio. Los elementos que pueden ser definidos
en 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, un
metamodelo 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 de
la salida de la transformación éstas pueden ser transformaciones de modelo a modelo, o
de modelo a texto. Con una transformación de modelo a modelo se obtiene un modelo
distinto del mismo sistema. Con una transformación de modelo a texto, en cambio, la
salida 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 elementos
definidos 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 de
software. 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 los
más utilizados, sobre todo cuando se trabaja en programación orientada a objetos. Por otra
parte 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, de
estados y de secuencia.

SPL

SPL es el acrónimo de Software Product Lines o Líneas de Producto Software. Las
SPL proponen un sistema de producción basado en la reutilización de componentes en
un 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 y
por otro las distintas variantes. Los distintos productos finales se consiguen mediante la
composición de diferentes componentes.
Una Linea de Producto Software puede ser definido como una colección de sistemas
de software enmarcados en un dominio o segmento de mercado específico que comparten
varias 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 varios
componentes que se componen dependiendo de las decisiones de producto, dando como
resultado diferentes productos finales (Krueger, 2008).
Las SPL introducen la variabilidad en el desarrollo del software. Se profundiza sobre
este 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 desarrollo
y 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 del
hardware y la puesta en marcha de todo el sistema. El trabajo de un ingeniero de sistemas
consiste en especificar el sistema, definir su arquitectura general e integrar las distintas
partes del sistema, sin participar en las partes específicas del sistema como pueden ser el
hardware 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 usan
técnicas parecidas para ambas disciplinas. Ejemplo de ello es SysML (OMG, 2008a), un
lenguaje de modelado de sistemas, creado como perfil de UML que se usa para modelar
software.

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 de
modelado, por ejemplo Java y UML. La frontera entre estas dos categorías es cada vez
más borrosa debido a que muchas veces los programas son tratados como modelos, o los
modelos 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 se
centrará este capítulo. Tanto UML como Java pueden ser algunos ejemplos de la primera
categoría, mientras que SQL o HTML pueden ser ejemplos de DSL. Aún así, al igual que
en la anterior clasificación, en este caso la frontera tampoco es tan clara ya que existen
lenguajes específicos de dominio que han evolucionado hasta convertirse en lenguajes de
propó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 o
textuales, 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 cuando
ha aumentado el interés por ellos, gracias sobre todo al surgimiento del paradigma de
desarrollo dirigido por modelos, donde se trabaja muchas veces con modelos específicos
de 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 H e a d i n g < / 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 menos
completos, pero más expresivos en su dominio. Al usar el lenguaje términos propios del
dominio 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 de
propó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ífico
de 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. No
obstante, 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álisis
muy profundo del dominio, al que hay que sumarle el coste de diseño, implementación y
mantenimiento.

DSL gráficos vs DSL textuales

Como ya se ha comentado, los lenguajes específicos de dominio pueden ser tanto
gráficos como textuales. Ejemplos de DSL textuales pueden ser SQL para la interacción
con bases de datos, o HTML para visualización de páginas web, mostrado en la Figura
4.1a. En este ejemplo se puede ver como se define la visualización de un título o de un
pá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 por
modelos. Normalmente los DSL gráficos suelen ser lenguajes de modelado, desde los que
se puede generar código de implementación o documentación, y que se analizará más a
fondo en el siguiente capítulo. La utilización de lenguajes de modelado específicos de
dominio permite elevar aún más el nivel de abstracción. Como ejemplo de DSL gráficos
se puede comentar por ejemplo SPEM (Software Process Engineering Meta-Model), que
es un lenguaje para la definición de procesos de ingeniería de software (OMG, 2008b). En
la 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 el
que se va a diseñar el lenguaje. Esto supone un gran esfuerzo, por lo que es importante
saber 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 algunas
propuestas 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 tiene
porque 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 depender
de 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 uso
no está siempre justificado, ya que el coste de la creación del DSL puede ser mayor
que 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 alternativas
antes 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 el
conocimiento necesario desde diversas fuentes, como pueden ser documentos téc-
nicos, conocimiento de los expertos del dominio, código ya existente en lenguajes
de propósito general, etc. Como resultado del análisis se obtiene una terminología
especí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 puede
resultar una tarea extremadamente difícil. Una opción más fácil es la de partir de un
lenguaje ya existente, ya sea utilizando parte de sus características, restringiéndolo
para 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 embebidos
en 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 se
ha realizado mediante técnicas de metamodelado, es decir, creando modelos del
lenguaje.

Puesta en marcha: Para la puesta en marcha de un DSL después de realizar los
pasos previos es muy importante facilitar al usuario la implantación del DSL en su
entorno 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 al
desarrollo 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 elementos
que 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 definidos
anteriormente en el meta-metamodelo. Los elementos comentados se representan en un
diagrama de tres niveles, tal y como muestra la Figura 4.2 (Kurtev et al., 2006). Al diseñar
un DSL se trabaja en el nivel M2, es decir, hay que crear el metamodelo. El usuario final
del 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 ejemplos
exitosos de su utilización (DSM-Forum, 2008). Un ejemplo de uso de DSL en empresas
es 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 continuamente
incluyen nuevas características, y el software que lleva el aparato se ha convertido en un
aspecto 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 que
el competidor se puede traducir en grandes cantidades de ingresos. En este sentido, la
productividad en el proceso de desarrollo es vital.
Con el objetivo de incrementar su competitividad, Nokia buscaba un método para
mejorar la productividad aplicando las siguientes estrategias:

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

25


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

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 modelado
y 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 en
la 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 que
relacionar cada concepto del dominio con un elemento del lenguaje de modelado como
ocurrirí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 entre
los 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 la
implementació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 analizado
dos de ellos, que permiten la creación de lenguajes específicos de modelado mediante
el 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 EMF
M3 GOPPRR Ecore
M2 DSL definido con GOPPR DSL definido con Ecore
M1 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 para
trabajar con modelos. Ambas herramientas permiten definir los metamodelos utilizando
un lenguaje de metamodelado o meta-metamodelo.

En este capítulo solo se analiza parte de las herramientas, ya que éstas ofrecen más
fuciones aparte del diseño de DSL. Se hace una breve descripción de las herramientas y se
muestran sus características más importantes relacionadas con el diseño de lenguajes de
modelado. 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 finalizar
esta 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 los
cuales 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 los
objetos, para especificar la forma que tendrán las relaciones, como por ejemplo de qué
parte de un objeto podrá salir una relación.
1 http://www.metacase.com/

28

4.2. HERRAMIENTAS

Aparte de la herramienta gráfica para definir metamodelos, MetaEdit+ también ofrece
una 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 de
diseñ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 de
objetos

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

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

Otra utilidad de la que dispone esta herramienta es la de diseñar figuras propias para
utilizarlas en los modelos, pudiéndose crear de esta manera elementos con apariencia
relacionada con lo que representan dentro del dominio, haciendo que el lenguaje diseñado
sea 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 metamodelo
otra vez a MetaEdit+ podremos utilizar el lenguaje diseñado para crear nuestros modelos
específicos de dominio.
Los formatos utilizados por MetaEdit+ para exportar metamodelos y modelos son
propios, por lo que no son compatibles con otras herramientas. Aún así, esta herramienta
ofrece 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ás
profundamente 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. La
definició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 en
la Figura 4.2.

4.2.2. EMF
Descripción

Eclipse Modeling Framework (EMF) es también una herramienta que permite definir
DSL de modelado gráficamente. Esta herramienta es el framework que ofrece Eclipse
para el MDD (Eclipse, 2009) y es software libre. Es una herramienta extensible mediante
plugins, que ofrece también herramientas para transformaciones de modelos y generación
de código. En este capítulo nos centramos en la utilidad de esta herramienta para crear
DSL 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 mediante
el lenguaje de metamodelado Ecore. La herramienta dispone para ello de un editor de
diagramas 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 elementos
que se podrán incluir en un modelo con el lenguaje creado. También se definen en el
diagrama los atributos que tendrán los distintos elementos, y cómo estarán relacionados
entre 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 describe
má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 clases
de UML, el lenguaje de metamodelado KM3 o XML Schema, e importarlo a EMF, el cual
generará automáticamente un modelo Ecore desde el fichero importado.
Una vez definido el metamodelo, EMF ofrece la opción de generar un plugin para
poder utilizar el editor de modelos para definir modelos específicos de dominio. La Figura
4.7 muestra el editor de modelos para crear modelos en el lenguaje definido en la Figura
4.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 ello
de la herramienta Graphical Modeling Framework (GMF). Esta herramienta permite crear
un editor de diagramas para el lenguaje de modelado definido con Ecore, especificando
para ello cuáles serán los elementos y relaciones que podrán aparecer en un diagrama del
modelo y cómo.
El formato utilizado para exportar e importar metamodelos y modelos por EMF es
XML Metadata Interchange (XMI). XMI (OMG, 2007) es una especificación definida
por 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, el
proceso 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 se
podrán utilizar en un modelo. Se puede decir, en este aspecto, que la facilidad de uso de
ambas herramientas es más o menos la misma.
Donde existe más diferencia entre las dos herramientas analizadas, es a la hora de
utilizar el DSL de modelado diseñado. Mientras MetaEdit+ ofrece automáticamente un
editor gráfico de diagramas para dibujar modelos con el lenguaje diseñado, el editor de
modelos ofrecido por EMF no es tan expresivo, ya que en éste el modelo se define en
forma de árbol, y no con un diagrama. Como se ha comentado, EMF ofrece la posibilidad
de crear un editor de diagramas con GMF para nuestro lenguaje de modelado, pero esta
tarea puede resultar bastante difícil. Se puede decir que en este aspecto la herramienta
MetaEdit+ es más completa y está bastante más lograda. Durante el proyecto hacer un
ejemplo con MetaEdit+ ha requerido menos tiempo que hacer el mismo ejemplo con
EMF.
Una baza a favor de EMF es su extensibilidad, ya que mediante el uso de plugins
se puede obtener una herramienta muy completa con una gran variedad de utilidades.
Además dispone de una gran comunidad de desarrolladores y usuarios que mantienen
muy 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 herramientas
tanto 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 este
proyecto es la posibilidad de crear DSL desde XML Schema, pudiendo tratar ficheros
XML 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 modelos
entre ambas herramientas.
Como conclusión se puede decir que aunque EMF sea una herramienta más completa
y versátil, la facilidad ofrecida por MetaEdit+ para la definición y utilización de DSL de
modelado es superior a la ofrecida por EMF. Es importante analizar para qué se va a usar
la herramienta y qué se quiere obtener de ella antes de decidirse por una u otra. Además
al 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 define
un DSL de modelado para diseñar un sistema de control de inundaciones. Primero se
describe el caso de estudio y se presenta cuál es el sistema a definir. A continuación se
muestra cómo hemos definido un lenguaje de modelado con MetaEdit+ y otro con EMF
para 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 de
un sistema embebido compuesto por varios subsistemas que controlan diferentes partes
del sistema. Este sistema de control de inundaciones recoge información del ambiente, y
basándose en los datos recopilados fija unos niveles de alerta y ejecuta unas determinadas
acciones. 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 de
entrada 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 las
salidas, 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 lenguaje
GOPPRR. En este metamodelo se han definido los elementos principales que puede tener
un 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ón
se ha definido a su vez el rol que juega cada objeto que participa en él, y donde se indica la
cardinalidad. Como se puede ver, un subsistema estará compuesto de varios subsistemas
que tendrán al mismo tiempo varias entradas y salidas.
Para poder utilizar el lenguaje definido primero hay que importarlo a MetaEdit+. Esto
se puede hacer con el botón Build (ver Figura 4.4), el cual exporta el metamodelo en un
fichero 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 apariencia
que 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 cada
tipo 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 un
nombre y una descripción. Tal y como se ve en la Figura 4.6, el sistema puede tener varios
subsistemas y siempre tendrá al menos uno. Igualmente, un subsistema también tiene un
nombre y una descripción, y se compone de varias entradas y salidas, que se definen con
las clases Input y Output respectivamente. A cada una de estas clases se le han definido
tres 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 editor
de modelos que se utilizará para diseñar nuestro tipo de sistemas. Utilizando este editor
podemos 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 definir
modelos que conformen al metamodelo. En la Figura 4.5 se muestra el modelo de un
sistema de control de inundaciones llamado UK01. Este modelo contiene los elementos
definidos en el metamodelo, y como se puede apreciar, cada tipo de elemento tiene una
apariencia diferente que hemos definido utilizando el Object Tool.
En el modelo se puede ver que el sistema UK01 está compuesto por tres subsistemas
que sirven para controlar la temperatura, las precipitaciones, y el nivel de la presa. El
primero recibe como entrada los valores de temperatura medidas en tres puntos diferentes
y devuelve como salida un nivel de alarma. El segundo hace lo propio, pero en este caso
recibe como entrada datos de precipitaciones. El tercero controla la compuerta de la presa
basá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éndole
más entradas o salidas a los subsistemas existentes.

34

4.3. CASO DE ESTUDIO

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 modelo
contiene 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 y
salidas.
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 y
salidas correspondientes. También se puede completar el modelo definido añadiéndole
más subsistemas que controlen otros componentes.

4.3.4. Beneficios obtenidos
Con el estudio de este caso se pueden observar algunos de los beneficios obtenidos
por la utilización de un DSL.
Aunque la definición de un DSL requiera esfuerzo y tiempo, se ha conseguido definir
un 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 la
expresividad 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 coste
de desarrollo, que se traduce en un incremento de la productividad. Si añadimos a todo lo
anterior la generación automática de código, los beneficios pueden ser aún mayores, tal y
como se verá en el siguiente capítulo.

35


36

Capítulo 5

Desarrollo de Software Dirigido por
Modelos

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 este
capítulo se presentan los principales elementos que participan en el MDD. Seguidamente
se analiza una serie de herramientas para la deﬁnición de modelos y generación de código,
y ﬁnalmente 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 modelos
y transformaciones de modelos. Los programas son representados mediante modelos que
pueden 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ón
automá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ás
de 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 a
nivel 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ía
de la calidad. Generalmente la razón más importante para utilizar el MDD es el aumento
de 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, por
lo que el MDD va muy unido a los DSL. La utilización de modelos durante el diseño del
software ha ido creciendo, sobre todo gracias a UML, y los intentos de generar código
automáticamente desde los modelos UML también han sido muchos. Pero al ser UML un
lenguaje de modelado de propósito general no es fácil definir una transformación general
que 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 las
clases, pero no todo el programa. Al definir los programas utilizando modelos específicos
del 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 por
metamodelos.
La Figura 5.1 muestra los principales elementos que participan en el MDD, que son
los modelos, metamodelos y transformaciones de modelos.

5.1.2. Modelo

Un modelo es una representación de la realidad mediante abstracciones. Un modelo
muestra 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 de
modelado, 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 (Figura
4.2). Un metamodelo es el modelo de un lenguaje de modelado en el que el lenguaje
es especificado (Kurtev, 2005). En otras palabras, el metamodelo describe los elementos
del dominio, sus relaciones y algunas restricciones básicas. En el Capítulo 4 se mostraba
cómo se definía un metamodelo para crear un lenguaje de modelado (ver Figuras 4.4 y
4.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 genera
un modelo de salida a partir de un modelo de entrada. El modelo de salida puede ser
una representación distinta del mismo sistema, o bien la implementación del mismo. Las
transformaciones 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 texto
de salida (Kurtev, 2005; Sendall & Kozaczynski, 2003).
Dependiendo de la salida, una transformación de modelos se puede clasificar como
transformación de modelo a modelo, o transformacion de modelo a texto. El primero toma
como entrada uno o varios modelos que conforman a un metamodelo, y devuelve como
salida uno o varios modelos que conforman al mismo u otro metamodelo. El segundo
produce texto como salida, que puede ser código de implementación, documentación o
cualquier otro tipo de texto.

Transformación de modelo a modelo

Las transformaciones de modelo a modelo normalmente definen mapeos entre los
metamodelos de entrada y salida. Los metamodelos de entrada y salida pueden ser los
mismos o diferentes, y aplicando la transformación al modelo de entrada se consigue
como salida otra representación del sistema. Las transformaciones se definen utilizando
lenguajes de transformación. Algunos lenguajes son declarativos y permiten mapear ele-
mentos del metamodelo de entrada con el de salida. Otros son imperativos y permiten
generar 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 una
gran variedad de lenguajes, tanto libres como comerciales, para definir transformaciones

39


entre modelos. Algunos ejemplos son ATL (Bézivin et al., 2003), RubyTL (Cuadrado
et al., 2006), y ATC (Sánchez-Barbudo et al., 2008). En este trabajo se han utilizado ATL
y 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ón
de 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én
pueden ser utilizados para generar documentación a base de la información que ofrece
el modelo, o para generar cualquier otro tipo de texto. Los lenguajes de transformación
de 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 las
herramientas 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. En
este capítulo se analizarán las herramientas desde el punto de vista del MDD. También
se analizan otras herramientas; algunas de ellas incorporan el entorno completo para el
desarrollo dirigido por modelos; otras son plugins o add-ons que trabajan conjuntamente
con 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ña
comparativa.

5.2.1. MetaEdit+
Descripción

En el capítulo anterior se mostraba cómo utilizar esta herramienta para crear DSL
gráficos que podían ser utilizados para definir modelos de un sistema. MetaEdit+ ofrece
tambié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 los
elementos 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 de
modelo 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 elementos
e introduciéndolos en una plantilla de texto. El lenguaje MERL ofrece varios comandos
para acceder a los distintos elementos de un modelo. Una transformación comienza con
la definición de la transformación y del fichero de salida. Normalmente toda la definición
de la transformación va dentro de una sentencia foreach() donde se itera en un tipo de
elementos definidos en el modelo. Por ejemplo, en la Figura 5.2 se itera en los objetos
del tipo Controllable que se encuentran en el modelo. A partir de ahí se navega sobre
todo el modelo obteniendo la información de los diferentes elementos. El lenguaje MERL
ofrece 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 la
informació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+ ya
sea código, documentación o cualquier otro fichero textual, pero en cambio no ofrece la
posibilidad de definir transformaciones entre modelos.
En Kelly & Tolvanen (2008) se pueden encontrar varios ejemplos realizados con esta
herramienta.

Ventajas y limitaciones

Entre los aspectos positivos de esta herramienta cabe destacar la facilidad de uso al
definir lenguajes específicos de modelado con GOPPRR. La definición de modelos con
el DSL creado es también muy fácil. La herramienta permite realizar todas las tareas
gráficamente de forma muy sencilla, además de facilitar la creación de iconos propios para
utilizar en los modelos, haciendo que éstos sean identificados fácilmente como elementos
del dominio. La expresividad conseguida a la hora de modelar con esta herramienta es
muy alta.
Otro aspecto positivo a comentar es que la herramienta está muy bien documentada
con 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 esta
herramienta, 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 utilizan
otros lenguajes de transformación que ofrecen más posiblidades a la hora de navegar entre
los elementos de los modelos. La sintaxis tampoco es tan clara como en otros lenguajes, y
el estilo de programación difiere bastante, al definir toda la transformación dentro de una
iteración donde la navegación entre los elementos del modelo puede resultar complicado
en muchos casos.
Otro aspecto negativo de la herramienta es el uso de formatos propios para exportar
modelos y metamodelos, haciendo incompatible su uso en otras herramientas, a no ser
que estos permitan la importación de modelos de MetaEdit+. La interoperabilidad con
otras herramientas sería más fácil si se utilizara el formato XMI. De este modo sería
posible importar modelos de MetaEdit+ en otras herramientas y utilizar otros lenguajes
para definir las transformaciones.
Finalmente, como ya se ha comentado, con está herramienta se puede transformar de
modelo 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 que
ofrece EMF para definir lenguajes de modelado específicos de dominio. Eclipse es un
entorno 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 software
libre.

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 pueden
utilizar en distintas transformaciones. Aunque EMF trae algunas herramientas para definir
las 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. Esas
herramientas serán analizadas posteriormente de forma individual.

Ventajas y limitaciones

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 la
definició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 de
cada plugin, ya que estos tienen documentación propia. Además la ayuda ofrecida por la
comunidad resulta muy útil. Durante el transcurso del proyecto se han utilizado los grupos
1 http://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ón
de ayuda casi instantáneamente.
El uso de XMI como representación textual de los modelos y metamodelos también es
un aspecto positivo a comentar, ya que facilita la interoperabilidad con otras herramientas
de modelado o generadores de código.
En EMF, al igual que en MetaEdit+ la creación de un lenguaje de modelado mediante
el metamodelado es muy fácil e intuitivo. En cambio, con EMF no es tan fácil la definición
de un editor gráfico para modelos. Mientras ésto era automático en MetaEdit+, en EMF
hay 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 una
herramienta 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 transformaciones
utilizando el lenguaje de su mismo nombre, ATL (ATLAS Trasnformation Language). Es
una herramienta integrada como plugin dentro de EMF que permite definir transforma-
ciones entre metamodelos definidos con éste.
2 http://www.eclipse.org/newsportal/
3 http://www.sciences.univ-nantes.fr/lina/ATLAS/

44

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

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (16)

En vedette

En vedette (6)

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

Similaire à PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos (20)

Dernier

Dernier (20)

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