UMGenesis PDF

Universidad de Mendoza
UMGnesis
Generador de Aplicaciones basado en MDE

Carrera
Ingeniera en Informtica

Autor
Juan Pablo Marzetti

Tutor
Ing. Alberto Cortz.

2010

Agradecimientos
Ante todo quiero agradecer a Dios por el regalo de la vida y de esta vocacin a la que me
descubro llamado. Un enorme agradecimiento por descubrir en mi vida mucho ms que
diez talentos y una plegaria confiada en que el sacrificio de estos aos haya sido y siga
siendo para hacerlos fructificar en beneficio del hombre.
A mis padres, Mnica y Armando que han sido, desde que tengo memoria, el primer y ms
grande signo del Amor de Dios y que, con su ejemplo, han hecho de m el hombre que soy.
Les estoy infinitamente agradecido por regalarme su amor, su apoyo incondicional, sus
valores y por mostrarme con su testimonio que el sacrificio tiene valor: nos hace salir de
nosotros para mirar ms all de nuestra existencia.
A mis hermanas, Florencia, Marita y Agostina que han hecho junto con mis padres una
verdadera familia llena de calor de hogar.
A mis amigos por estar siempre, por saber que con ellos siempre soy el que soy, por ser
quienes junto a mi familia han estado presentes en los momentos ms importantes de mi
vida y han hecho de mi historia personal lo que es.
A Alberto, mi tutor por confiar en m, por sus valiosos aportes a este trabajo y,
principalmente, por sus consejos, su acompaamiento y su trato como si fuera un hijo
suyo.
A todas las personas que me han acompaado y han estado, simplemente GRACIAS.

Juan Pablo Marzetti
UMGnesis: Generador de Aplicaciones basado en MDE
v

n
d
i
c
e

ndice
ndice __________________________________________________________________ 5
ndice de Figuras ________________________________________________________ 13
1. Introduccin __________________________________________________________ 15
1.1. Propsito del Documento ___________________________________________________ 15
1.2. Contexto del Proyecto ______________________________________________________ 15
1.3. Motivacin _______________________________________________________________ 16
1.4. Definiciones_______________________________________________________________ 17
1.4.1. Framework __________________________________________________________________ 17
1.4.2. Modelo _____________________________________________________________________ 18
1.4.3. Metamodelo _________________________________________________________________ 18
1.4.4. MOF (Meta Object Facility) ______________________________________________________ 18
1.4.5. Transformacin de modelos _____________________________________________________ 18
1.4.6. QVT (Query/View/Transformation) _______________________________________________ 19
1.4.7. Generacin de Cdigo __________________________________________________________ 19
1.4.8. Interpretacin de Modelos ______________________________________________________ 19
1.4.9. Lenguaje de modelado _________________________________________________________ 20
1.4.10. Validacin de modelos ________________________________________________________ 20
1.4.11. Verificacin de Modelos _______________________________________________________ 20
1.4.12. Pruebas basadas en modelos ___________________________________________________ 20
1.4.13. Modelo especfico de Dominio __________________________________________________ 20
1.4.14. Modelado mltiple ___________________________________________________________ 21
1.4.15. Espacio de modelado _________________________________________________________ 21
1.4.16. Lenguaje de Propsito General __________________________________________________ 21
1.4.17. Ontologa ___________________________________________________________________ 22
1.4.18. Hibernate ___________________________________________________________________ 22
1.4.19. RichFaces ___________________________________________________________________ 23
1.4.20. Java Persistence API (JPA) _____________________________________________________ 23
1.4.21. Java Server Faces (JSF) ________________________________________________________ 23
1.4.22. CORBA _____________________________________________________________________ 23
vi Universidad de Mendoza

n
d
i
c
e

2. Objetivos ____________________________________________________________ 25
3. Ingeniera dirigida por modelos __________________________________________ 27
3.1. Introduccin ______________________________________________________________ 27
3.2. Objetivos de MDE __________________________________________________________ 28
3.3. Especificacin de modelos ___________________________________________________ 30
3.3.1. Roles de un Modelo____________________________________________________________ 30
3.3.2. Uso de modelos _______________________________________________________________ 31
3.3.4. Metamodelos ________________________________________________________________ 32
4. Arquitectura dirigida por Modelos ________________________________________ 35
4.1. Conceptos ________________________________________________________________ 36
4.1.1. Sistema _____________________________________________________________________ 36
4.1.2. Modelo _____________________________________________________________________ 37
4.1.3. Punto de Vista ________________________________________________________________ 37
4.1.4. Arquitectura _________________________________________________________________ 37
4.1.5. Plataforma ___________________________________________________________________ 37
4.1.6. Independencia de la plataforma __________________________________________________ 38
4.1.7. Servicios Dominantes __________________________________________________________ 38
4.1.8. Aplicacin ___________________________________________________________________ 38
4.1.9. Implementacin ______________________________________________________________ 38
4.1.10. Transformacin de modelos ____________________________________________________ 38
4.2. Puntos de vista de MDA _____________________________________________________ 38
4.2.1. Punto de Vista independiente de la Computacin ____________________________________ 38
4.2.2. Punto de Vista independiente de la Plataforma ______________________________________ 39
4.2.3. Punto de Vista especfico para la Plataforma ________________________________________ 39
4.3. Modelos MDA _____________________________________________________________ 39
4.3.1. Modelo Independiente de la Computacin (CIM) ____________________________________ 39
4.3.2. Modelo Independiente de la Plataforma (PIM) ______________________________________ 40
4.3.3. Modelo Especfico para la Plataforma (PSM) ________________________________________ 40
4.3.4. Modelo de la Plataforma ________________________________________________________ 41
4.3.5. Transformacin de un Modelo ___________________________________________________ 41
4.4. Tecnologas que conforman MDA _____________________________________________ 41
Juan Pablo Marzetti
vii

n
d
i
c
e

4.4.1. Lenguaje Unificado de Modelado (UML) ___________________________________________ 42
4.4.2. Meta Object Facility (MOF) ______________________________________________________ 42
4.4.3. Intercambio de Metadatos con XML (XMI) __________________________________________ 43
4.5. Uso de MDA ______________________________________________________________ 43
4.5.1. Proceso MDA para sistemas complejos ____________________________________________ 44
4.6. Relacin entre MDA y MDE __________________________________________________ 45
5. Modelado y Metamodelos ______________________________________________ 47
5.1. Dimensiones de Modelado __________________________________________________ 47
5.2. Tipos de Metamodelado ____________________________________________________ 48
5.2.1. Metamodelado Lingstico ______________________________________________________ 48
5.2.2. Metamodelado Ontolgico ______________________________________________________ 49
5.3. Jerarquas de Metamodelos _________________________________________________ 49
5.3.1. Jerarquas de Metamodelos Ontolgicos ___________________________________________ 49
5.3.2. Combinacin de jerarquas de metamodelado lingstico y ontolgico ___________________ 50
5.3.3. Jerarquas Lineales y No lineales __________________________________________________ 51
5.3.4. Elementos de lenguaje versus elementos de biblioteca ________________________________ 52
6. Lenguajes Especficos de Dominio _________________________________________ 55
6.1. Introduccin ______________________________________________________________ 55
6.2. Definicin ________________________________________________________________ 55
6.3. Elementos utilizados en la definicin de un lenguaje _____________________________ 57
6.3.1. Gramticas libres de contexto ___________________________________________________ 57
6.3.2. Gramtica de atributos _________________________________________________________ 58
6.4. Definicin de un lenguaje especfico de dominio ________________________________ 59
6.4.1. Sintaxis abstracta______________________________________________________________ 59
9.4.2. Sintaxis concreta ______________________________________________________________ 59
6.4.3. Semntica ___________________________________________________________________ 60
6.4.4. Relaciones ___________________________________________________________________ 61
6.4.5. Beneficios al definir un DSL. _____________________________________________________ 61
6.5. Sintaxis abstracta __________________________________________________________ 62
6.5.1. Modelado de la sintaxis abstracta ________________________________________________ 62
viii Universidad de Mendoza

n
d
i
c
e

6.5.2. Proceso _____________________________________________________________________ 63
6.5.2.1. Identificacin de los conceptos _______________________________________________ 63
6.5.2.2. Modelado de los conceptos _________________________________________________ 66
6.5.2.3. Validacin y Verificacin ____________________________________________________ 70
6.6. Sintaxis Concreta __________________________________________________________ 70
6.6.1. Modelado de la sintaxis concreta _________________________________________________ 71
6.6.2. Fases en el proceso de reconocimiento ____________________________________________ 72
6.6.2.1. Anlisis lxico y sintctico ___________________________________________________ 72
6.6.2.2. Anlisis semntico - Abstraccin ______________________________________________ 73
6.6.2.3. Anlisis semntico - Enlace __________________________________________________ 73
9.6.2.4. Anlisis semntico - Verificacin esttica _______________________________________ 73
6.7. Semntica ________________________________________________________________ 73
6.7.1. Definicin ___________________________________________________________________ 74
6.7.2. Objetivo _____________________________________________________________________ 74
6.7.3. Semntica y metamodelos ______________________________________________________ 75
6.7.4. Propuestas para la definicin de gramticas ________________________________________ 76
6.7.4.1. Semntica definida por traduccin ____________________________________________ 76
6.7.4.2. Semntica operacional _____________________________________________________ 77
6.7.4.3. Semntica extensional ______________________________________________________ 77
6.7.4.4. Semntica denotacional ____________________________________________________ 78
7. Entorno de desarrollo Eclipse ____________________________________________ 79
7.1. Arquitectura ______________________________________________________________ 79
7.1.1. Arquitectura del ncleo y Plug-ins ________________________________________________ 81
7.2. Eclipse Modeling Framework (EMF) ___________________________________________ 82
7.2.1. Ncleo EMF __________________________________________________________________ 82
7.2.1.1. Metamodelo Ecore ________________________________________________________ 83
7.2.2. Framework EMF.Edit ___________________________________________________________ 84
7.2.3. Generacin de Cdigo EMF-Codegen ______________________________________________ 84
7.3. Xtext ____________________________________________________________________ 84
7.3.1. Uso de Xtext _________________________________________________________________ 85
7.3.2. Estructura del proyecto _________________________________________________________ 86
7.3.3. Gramtica ___________________________________________________________________ 87
7.3.3.1. Declaracin del Lenguaje____________________________________________________ 88
Juan Pablo Marzetti
ix

n
d
i
c
e

7.3.3.2. Definicin de EPackage _____________________________________________________ 88
7.3.3.3. Reglas Terminales _________________________________________________________ 88
7.3.3.4. Reglas de Produccin ______________________________________________________ 89
7.3.3.5. Reglas de Tipo de Datos ____________________________________________________ 93
7.4. Framework para generar cdigo ______________________________________________ 93
7.4.1. Sistema de Tipos ______________________________________________________________ 94
7.4.1.1. Tipos ___________________________________________________________________ 94
7.4.1.2. Implementaciones de Metamodelos __________________________________________ 95
7.4.2. Lenguaje de Expresiones ________________________________________________________ 96
7.4.3. Xpand _______________________________________________________________________ 96
7.4.3.1. Estructura general de un archivo de plantillas ___________________________________ 97
7.4.3.2. Sentencia IMPORT _________________________________________________________ 97
7.4.3.3. Sentencia EXTENSION ______________________________________________________ 97
7.4.3.4. Sentencia DEFINE__________________________________________________________ 98
7.4.3.5. Sentencia FILE ____________________________________________________________ 99
7.4.3.6. Sentencia EXPAND _________________________________________________________ 99
7.4.3.7. Sentencia FOREACH _______________________________________________________ 100
7.4.3.8. Sentencia IF _____________________________________________________________ 100
7.4.3.9. Sentencia PROTECT _______________________________________________________ 100
7.4.3.10. Sentencia LET ___________________________________________________________ 101
7.5. Xtend _______________________________________________________________________ 101
7.5.1 Archivos de Xtend __________________________________________________________ 101
7.5.2 Sentencias Import __________________________________________________________ 102
7.5.3 Extensiones _______________________________________________________________ 102
7.5.3 Extensiones JAVA ___________________________________________________________ 102
8. Caso de Estudio ______________________________________________________ 103
8.1. Introduccin al lenguaje UMGnesis _________________________________________ 103
8.1.1. Vista esttica del Modelo ______________________________________________________ 103
8.1.2. Vista dinmica del Modelo _____________________________________________________ 104
8.1.3. Servicios ____________________________________________________________________ 105
8.2. Sintaxis Concreta _________________________________________________________ 106
8.2.1. Definicin de la Gramtica de Xtext ______________________________________________ 106
8.2.2. Elementos de la sintaxis de UMGnesis ___________________________________________ 112
x Universidad de Mendoza

n
d
i
c
e

8.2.2.1. Entidad _________________________________________________________________ 112
8.2.2.2. Uso ____________________________________________________________________ 115
8.2.2.3. Servicio ________________________________________________________________ 118
8.2.2.4. Expresiones _____________________________________________________________ 119
8.3. Sintaxis Abstracta _________________________________________________________ 123
8.3.1. Metamodelo de la Sintaxis abstracta _____________________________________________ 123
8.3.1.1 Sistema _________________________________________________________________ 124
8.3.1.2 Entidad _________________________________________________________________ 125
8.3.1.3 Propiedad _______________________________________________________________ 125
8.3.1.4 Atributo ________________________________________________________________ 126
8.3.1.5 Uso ____________________________________________________________________ 128
8.3.1.6 UsoTipo _________________________________________________________________ 128
8.4. Implementacin del analizador con Xtext _____________________________________ 130
8.4.1. Creacin del proyecto _________________________________________________________ 130
8.4.2. Especificacin de la gramtica y generacin de los artefactos __________________________ 131
8.4.3. Personalizacin del analizador __________________________________________________ 133
8.4.3.1. Conversin ______________________________________________________________ 134
8.4.3.2. Formateado de Cdigo ____________________________________________________ 134
8.4.3.3. mbitos ________________________________________________________________ 135
8.4.3.4. Validaciones al modelo ____________________________________________________ 136
8.4.4. Personalizacin del editor y del entorno del IDE ____________________________________ 137
8.4.4.1. Proposicin de cdigo _____________________________________________________ 137
8.4.4.2. Etiquetado ______________________________________________________________ 138
8.4.4.3. Vista Outline ____________________________________________________________ 139
8.4.4.4. Asistente para crear nuevos modelos _________________________________________ 140
8.5. Implementacin del Generador con Xpand ____________________________________ 141
8.5.1. Estructura de un Generador ____________________________________________________ 141
8.5.1.1. Tipos de Generadores _____________________________________________________ 141
8.5.1.2. Requerimientos __________________________________________________________ 142
8.5.1.3. Parmetros _____________________________________________________________ 143
8.5.1.4. Interfaz de acceso ________________________________________________________ 143
8.5.1.5. Descriptor del generador __________________________________________________ 145
8.5.2. Proceso de Generacin de Cdigo _______________________________________________ 146
8.5.3. Implementacin del Generador de Aplicaciones Java Server Faces ______________________ 149
Juan Pablo Marzetti
xi

n
d
i
c
e

8.5.3.1. Generador del Motor de Base de Datos MySQL _________________________________ 149
8.5.3.2. Generador de la Capa de Persistencia JPA _____________________________________ 151
8.5.3.3. Generador para el framework Java Server Faces ________________________________ 155
8.6. Ayuda de UMGnesis ______________________________________________________ 158
8.7. Datos Generales del Proyecto _______________________________________________ 159
9. Conclusiones _________________________________________________________ 161
9.1. Ingeniera dirigida por Modelos _____________________________________________ 162
9.2. Desarrollo de UMGnesis __________________________________________________ 163
9.3. Lneas futuras de investigacin y aplicacin ____________________________________ 164
10. Bibliografa _________________________________________________________ 167
Juan Pablo Marzetti
xiii

n
d
i
c
e

d
e

F
i
g
u
r
a
s

ndice de Figuras
Figura 1. Relacin entre Modelos de Tipo, Modelos de Muestra y los objetos reales __ 31
Figura 2. Proceso simplificado de Ingeniera de Software ________________________ 32
Figura 3. Jerarqua de cuatro capas de Metamodelos de UML ____________________ 33
Figura 4. Transformacin de un modelo ______________________________________ 41
Figura 5. Transformaciones entre los distintos modelos _________________________ 44
Figura 7. Relacin entre MDA y MDE ________________________________________ 45
Figura 6. Transformaciones para sistemas complejos ___________________________ 45
Figura 8. Ejemplo de Jerarqua de Metamodelos Ontolgicos ____________________ 50
Figura 9. Lenguajes Especficos de Dominio conocidos __________________________ 56
Figura 10. Arquitectura de la plataforma Eclipse _______________________________ 80
Figura 11. Modelo completo de Ecore. _______________________________________ 83
Figura 12. Creacin de un nuevo proyecto Xtext. _______________________________ 86
Figura 13. Metamodelo de Ejemplo _________________________________________ 98
Figura 14. Precedencia de Operadores en UMGnesis __________________________ 120
Figura 15. Sintaxis abstracta de UMGnesis Vista Esttica ____________________ 124
Figura 16. Sintaxis abstracta de UMGnesis Tipos de Datos Escalares ___________ 126
Figura 17. Sintaxis abstracta de UMGnesis Vista Dinmica - Usos ______________ 128
Figura 18. Sintaxis abstracta de UMGnesis Vista Dinmica Servicios __________ 129
Figura 19. Proyectos de UMGnesis ________________________________________ 131
Figura 20. Estructura del proyecto luego de la generacin de los artefactos. _______ 132
Figura 21. Primera ejecucin del analizador generado _________________________ 133
xiv Universidad de Mendoza

n
d
i
c
e

d
e

F
i
g
u
r
a
s

Figura 22. Sugerencias de cdigo de UMGnesis ______________________________ 138
Figura 23. Comparacin de Vistas Outline por defecto y personalizada ____________ 139
Figura 24. Asistente para crear modelos UMGnesis ___________________________ 140
Figura 25. Dilogo de Generacin de Cdigo _________________________________ 147
Figura 26. Progreso del proceso de generacin de cdigo. ______________________ 147
Figura 27. Diagrama de Clases de las entidades generadas _____________________ 153
Figura 28. Diagrama de Clases de los Controladores de Acceso a Datos 1 __________ 154
Figura 29. Diagrama de Clases de los Controladores de Acceso a Datos 1 __________ 155
Figura 30. Diagrama de Clases de un controlador (bean) para un uso ____________ 157
Figura 31. Diagrama de Clases de un servicio generado.________________________ 158
Figura 32. Documentacin para Eclipse de UMGnesis _________________________ 159
Juan Pablo Marzetti
15

I
n
t
r
o
d
u
c
c
i
n

1. Introduccin
1.1. Propsito del Documento
El propsito de este documento es ser una referencia inicial sobre los temas que
involucran el desarrollo y la ingeniera dirigida por modelos para introducirse en sta
creciente rea de la Ingeniera del Software.
Es el resultado de una investigacin, estudio y prctica realizados como trabajo final para
la carrera de Ingeniera en Informtica de la Universidad de Mendoza. Espero
sinceramente que quien lea este documento lo encuentre til para interiorizarse en sta
rea del conocimiento y, sobre todo, lo motive y aliente a seguir obteniendo conocimiento
de manera de poder sacarle provecho.
1.2. Contexto del Proyecto
La creciente complejidad de los sistemas informticos representa un reto importante para
los ingenieros y arquitectos del software. El desafo consiste en desarrollar productos con
niveles de calidad y productividad adecuados en un contexto de negocio altamente
complejo y dinmico y con acelerados cambios tecnolgicos.
Existe una imperiosa necesidad de mejorar el desempeo para maximizar las ganancias. El
Human Performance Center agrupa las tendencias que sigue la comunidad informtica
para lograr tal propsito, en tres enfoques bsicos (HPC, 2002):
Trabajar ms rpidamente: mejorando las herramientas que apoyan el desarrollo
de software (IDE, compiladores, generadores de cdigo, etc.).
Trabajar ms gilmente: analizando, evaluando y mejorando la forma de trabajar.
Trabajar menos: cambiando la forma de trabajar, maximizando el reso, no
desgastndose en diseo, codificacin y pruebas exhaustivas, realizando
programacin en el nivel de ingeniera de modelos y requisitos.
El planteamiento anterior evidencia la importancia de proponer metodologas de trabajo y
las herramientas que ayuden a materializarlas, que potencien la reutilizacin a un alto
16 Universidad de Mendoza

I
n
t
r
o
d
u
c
c
i
n

nivel de abstraccin. De la preocupacin inicial sobre la definicin de la estructura y
calidad del cdigo final, se ha pasado a dedicar cada vez ms tiempo, atencin y esfuerzo
al diseo y modelado del sistema.
De esta manera, al hacer hincapi en los modelos, que proporcionan un mayor nivel de
abstraccin, es posible trabajar con sistemas mayores y ms complejos facilitando el
proceso de codificacin e implementacin del sistema de forma distribuida y en distintas
plataformas. A partir de este desafa surge la idea de proponer esquemas de desarrollo en
los cuales los modelos, antes que el cdigo, son los actores centrales del proceso de
desarrollo y donde se proveen mecanismos y herramientas de trabajo integradas que
asisten al desarrollador en la construccin y transformacin progresivas de modelos hasta
llegar a la solucin final.
1.3. Motivacin
La metodologa MDE es una filosofa de trabajo que puede aplicarse al desarrollo del
software de manera manual, sin utilizar herramientas. Sin embargo, como se indic
anteriormente el mayor reto de la industria del software es construirlo con rapidez,
calidad y versatilidad a los cambios en los requerimientos, plataformas y arquitecturas.
Esto evidencia una imperiosa necesidad de herramientas CASE que automaticen al
mximo posible las tareas que los desarrolladores realizan permitindoles a los mismos
centrar su atencin en disear software lo ms ajustado a las necesidades del cliente.
Desde el punto de vista personal, surge la idea de generar una herramienta de cdigo libre
que permita acelerar el proceso de desarrollo y a la vez permitir adaptarse rpidamente a
los cambios en los requerimientos.
Mi experiencia laboral en el rea de desarrollo de sistemas de la Direccin General de
Escuelas del Gobierno de Mendoza aporta mucho a la motivacin de investigar sobre este
tema. Los requerimientos para los sistemas de la DGE son altamente dinmicos y el
recambio de personal en el desarrollo tambin. Actualmente se trabaja con una
Juan Pablo Marzetti
17

I
n
t
r
o
d
u
c
c
i
n

herramienta comercial (GeneXus) que implementa ciertos aspectos de la filosofa MDE
pero tiene ciertas desventajas:
Tiene un alto costo de licenciamiento
La metodologa de trabajo no respeta ningn estndar y el lenguaje de
programacin es un lenguaje de programacin de propsito general propio, por lo
que los desarrolladores deben capacitarse especficamente para la herramienta.
Eso tiene como puntos negativos una curva de aprendizaje muy lenta y un costo de
capacitacin elevado.
El cdigo generado tampoco respeta estndares y es altamente ininteligible por lo que
hacer cambios muy especficos que no puedan ingresarse desde el modelo es muy difcil y
costoso por el tiempo que lleva interpretarlo.
1.4. Definiciones
1.4.1. Framework
La palabra inglesa framework define, en trminos generales, un conjunto estandarizado
de conceptos, prcticas y criterios para enfocar un tipo de problemtica particular, que
sirve como referencia para enfrentar y resolver nuevos problemas de ndole similar.
En el desarrollo de software, un framework es una estructura conceptual y tecnolgica de
soporte definida, normalmente con artefactos o mdulos de software concretos, en base
a la cual otro proyecto de software puede ser organizado y desarrollado. Tpicamente,
puede incluir soporte de programas, bibliotecas y un lenguaje interpretado entre otros
para ayudar a desarrollar y unir los diferentes componentes de un proyecto.
Representa una arquitectura de software que modela las relaciones generales de las
entidades del dominio. Provee una estructura y una metodologa de trabajo la cual
extiende o utiliza las aplicaciones del dominio.

I
n
t
r
o
d
u
c
c
i
n

1.4.2. Modelo
El trmino modelo proviene del latn modulus que significa medida, regla, patrn, ejemplo a
ser seguido. Una definicin ms formal de modelo es Esquema terico, generalmente en
forma matemtica, de un sistema o de una realidad compleja que se elabora para facilitar
su comprensin y el estudio de su comportamiento. (RAE 2001)
Un modelo necesita verificar tres propiedades para ser considerado tal:
Trazabilidad: un modelo est basado en un elemento original que puede ser
construido o permanecer imaginario.
Reduccin: no todas las propiedades del sujeto real son trazadas en el modelo,
aunque ste debe poder describir al sujeto de manera ms o menos completa.
Usabilidad: un modelo debe poder ser utilizado en lugar del sujeto para algn
propsito.
1.4.3. Metamodelo
Se define generalmente como el modelo de un modelo. Este concepto se usa como un
medio para definir lenguajes. Los metamodelos son definidos a travs de lenguajes como
MOF (Meta Object Facility).
1.4.4. MOF (Meta Object Facility)
MOF es un estndar propuesto por OMG (Object Management Group) y puede ser visto
como un DSL (Domain Specific Language, Lenguaje Especfico de Dominio) para definir
metamodelos. Es una especificacin para definir metamodelos. MOF puede ser expresado
como un modelo en su misma notacin (esto significa que es auto-definible)
1.4.5. Transformacin de modelos
Consiste en convertir un modelo origen en uno destino mediante el uso de ciertas reglas
de transformacin. Existen diversos mtodos para llevar a cabo esta tarea. En 2007 OMG
lanz el estndar QVT (Query View Transformation) que es la especificacin de un
lenguaje de transformacin de modelos.
Juan Pablo Marzetti
19

I
n
t
r
o
d
u
c
c
i
n

Se puede distinguir entre transformaciones (refinamientos) que agregan informacin
computacional y transformaciones que agregan informacin tecnolgica o de la
plataforma. En el primer caso es necesaria la intervencin humana mientras que en el
segundo la tarea puede ser automatizada.
Otro tipo de transformacin es la que propaga cambios. Este tipo de transformaciones son
no destructivas y consisten en tomar el cambio de origen y propagarlo entre las distintas
capas de abstraccin. Un ejemplo de este caso son las modificaciones que pueden hacerse
a la estructura de una base de datos sin perder los datos almacenados en la misma. Cabe
destacar que este tipo de transformacin no siempre es posible.
1.4.6. QVT (Query/View/Transformation)
La transformacin de modelos es un elemento crtico de MDA por lo que se ha trabajado
mucho en un estndar para la transformacin de modelos. En 2007 la especificacin final
de MOF QVT 2.0 fue lanzada. Dicha especificacin mejor conocida como QVT define
metamodelos para definir lenguajes de transformacin de modelos. Los lenguajes
resultantes pueden transformar modelos fuente en modelos destino donde ambos son
compatibles con un metamodelo MOF arbitrario. El lenguaje de transformacin en s
mismo constituye un modelo y es compatible con un metamodelo MOF.
1.4.7. Generacin de Cdigo
Es la tcnica de generar cdigo fuente (en un lenguaje de programacin como Java o C#)
desde un modelo. Puede realizarse de varias maneras: utilizando plantillas y reglas de
reescritura o construyendo un metamodelo del lenguaje de programacin y definiendo las
transformaciones formales necesarias.
1.4.8. Interpretacin de Modelos
La interpretacin de modelos o ejecucin de modelos implica ejecutar directamente un
modelo en un motor de ejecucin (como una mquina virtual). De esta manera no se
genera cdigo fuente ni se definen transformaciones. Simplemente se coloca un modelo

I
n
t
r
o
d
u
c
c
i
n

en un entorno de ejecucin y este se encarga de ejecutarlo de acuerdo a la semntica del
modelo.
1.4.9. Lenguaje de modelado
Un modelo es especificado en alguna notacin de modelado. Dicha notacin puede ser
indicada como lenguaje de modelado. Al ser los lenguajes de modelado orientados a
ciertos dominios, puede hablarse de ellos como lenguajes especficos de dominio (DSL).
1.4.10. Validacin de modelos
Tcnica utilizada para evaluar modelos con respecto un criterio semntico y sintctico.
Implica una verificacin de consistencia, es decir: evaluar el modelo contra su
metamodelo. Adems de los metamodelos, pueden utilizarse restricciones para validar el
modelo. El lenguaje ms utilizado para este propsito es un estndar de OMG llamado
OCL (Object Constraint Language) que consiste en un lenguaje formal para describir
expresiones sobre los modelos.
1.4.11. Verificacin de Modelos
Tcnica de comprobacin formal basada en la exploracin de estados. Dado un estado en
un sistema, una propiedad y una transicin de estado, los algoritmos de verificacin
exploran exhaustivamente el espacio de estado para determinar si el sistema satisface la
propiedad dada.
1.4.12. Pruebas basadas en modelos
Adems de probar, validar y verificar modelos tambin es necesario comprobar el
artefacto de software resultante. El uso de casos de prueba generados automticamente a
partir de los modelos para chequear el comportamiento de un sistema se llama Pruebas
basadas en modelos.
1.4.13. Modelo especfico de Dominio
Es el resultado de especificar un modelo en un lenguaje especfico de dominio. Esta
tcnica eleva el nivel de abstraccin ms all de la programacin especificando la solucin
Juan Pablo Marzetti
21

I
n
t
r
o
d
u
c
c
i
n

directamente con los conceptos del dominio. Los productos finales son generados desde e
las especificaciones a este nivel de abstraccin.
1.4.14. Modelado mltiple
Es el acto de combinar diversos modelos, lo cual puede realizarse de dos maneras:
Jerrquico: Se combinan composiciones jerrquicas de distintos estilos de modelo
aprovechando la expresividad de los mismos.
Vista mltiple: Se construyen modelos distintos y separados del sistema con el
objeto de denotar distintos aspectos del mismo.
En este informe se habla de modelado mltiple en sentido de vistas mltiples. Mientras
que en el desarrollo de un sistema ste se describe utilizando mltiples modelos
especficos de dominio, la integracin de los mismos es necesaria para sintetizar el
sistema descrito.
1.4.15. Espacio de modelado
Un sistema complejo se describe con muchos modelos cada cual describe diferentes
partes del sistema. Todos estos modelos en su conjunto conforman el espacio de
modelado. Es importante estructurar este espacio categorizando las perspectivas que
cada modelo ofrece. Un ejemplo de dicha categorizacin sera:
Los aspectos del sistema que describen: datos, presentacin, seguridad, reglas de
negocio, flujos de trabajo, etc.
Las reas de inters que describen: ventas, clientes, administracin, etc.
El nivel de abstraccin en que estn definidos: CIM, PIM, PSM, etc.
1.4.16. Lenguaje de Propsito General
Los lenguajes de propsito general, son lenguajes que pueden ser usados para varios
propsitos como acceso a bases de datos, comunicacin entre computadoras,
comunicacin entre dispositivos, captura de datos, clculos matemticos, diseo de

I
n
t
r
o
d
u
c
c
i
n

imgenes o pginas, crear sistemas operativos, manejadores de bases de datos,
compiladores, entre muchas otras cosas.
En general, puede ser usado para cualquier desarrollo y se denominan de propsito
general en oposicin a los lenguajes especficos de dominio que sirven para describir
programas o situaciones con validez dentro del dominio al que se circunscriben.
1.4.17. Ontologa
Se refiere al estudio de las clases de cosas que existen. Suele afirmarse que las ontologas
desmenuzan el mundo desde sus articulaciones. Los anlisis ontolgicos ayudan a
clarificar la estructura del conocimiento. Dado un dominio determinado, su ontologa
conforma el corazn de cualquier sistema de representacin de conocimiento acerca del
mismo. Sin ontologas, o las conceptualizaciones que sustentan el conocimiento, no podra
existir un vocabulario para representar el conocimiento.
Incluso en los procesos de ingeniera de software, las ontologas son importantes.
Cualquier programa de software necesita un modelo del mundo real para hacer algo til y,
por ende, necesita una ontologa. Una ontologa es un sistema de conceptos y sus
relaciones en el cual todos los conceptos son definidos e interpretados en una manera
declarativa. El sistema define el vocabulario del dominio de un problema y un conjunto de
restricciones que constrien la forma en que los trminos pueden combinarse con el
modelo del dominio. Un sinnimo para ontologa podra ser modelo del dominio.
1.4.18. Hibernate
Hibernate es un servicio de persistencia y consulta objeto/relacional de alto rendimiento.
Permite desarrollar clases persistentes siguiendo los lineamientos del paradigma de
orientacin a objetos incluyendo: asociaciones, herencia, polimorfismo, composicin y
colecciones. Hibernate permite expresar consultas en su extensin propia de SQL (llamada
HQL), en SQL nativo o con una API orientada a objetos.
Hibernate es un proyecto de cdigo abierto perteneciente a la suite de productos JBoss
Enterprise Middleware System desarrollados por Red Hat.
Juan Pablo Marzetti
23

I
n
t
r
o
d
u
c
c
i
n

1.4.19. RichFaces
RichFaces es un framework de cdigo abierto que agrega funcionalidades Ajax a
aplicaciones desarrolladas en Java Server Faces (JSF) sin la necesidad de escribir cdigo en
JavaScript.
RichFaces toma ventaja de las funcionalidades de JSF incluyendo el ciclo de vida,
validacin, conversin, y administracin de recursos dinmicos y estticos. Los
componentes de RichFaces tienen soporte incorporado para Ajax y un sistema altamente
configurable de skins para adaptarlos al diseo de la aplicacin web.
1.4.20. Java Persistence API (JPA)
Es la API de persistencia desarrollada para la plataforma Java EE e incluida en el estndar
EJB3. Esta API busca unificar la manera en que funcionan las utilidades que proveen un
mapeo objeto-relacional. El objetivo que persigue el diseo de esta API es no perder las
ventajas de la orientacin a objetos al interactuar con una base de datos, como s pasaba
con EJB2, y permitir usar objetos regulares (conocidos como POJOs).
1.4.21. Java Server Faces (JSF)
La tecnologa Java Server Faces est desarrollada mediante el Java Community Process.
Establece un estndar para construir interfaces de usuario del lado del servidor. Su
objetivo es facilitar el desarrollo de aplicaciones web en Java, permitiendo desarrollar
aplicaciones con soporte para varios idiomas y accesibilidad.
La tecnologa JSF incluye un conjunto de APIs para representar componentes visuales y
administrar su estado, manejar eventos y validacin de datos de entrada. Este ltimo
aspecto se realiza definiendo el mapa de navegacin de las pginas.
1.4.22. CORBA
CORBA (Common Object Request Broker Architecture arquitectura comn de
intermediarios en peticiones a objetos), es un estndar que establece una plataforma de
desarrollo de sistemas distribuidos facilitando la invocacin de mtodos remotos bajo un
paradigma orientado a objetos.

I
n
t
r
o
d
u
c
c
i
n

CORBA fue definido y est controlado por el Object Management Group (OMG) que define
las APIs, el protocolo de comunicaciones y los mecanismos necesarios para permitir la
interoperabilidad entre diferentes aplicaciones escritas en diferentes lenguajes y
ejecutadas en diferentes plataformas, lo que es fundamental en computacin distribuida.
En un sentido general, CORBA "envuelve" el cdigo escrito en otro lenguaje, en un
paquete que contiene informacin adicional sobre las capacidades del cdigo que
contiene y sobre cmo llamar a sus mtodos. Los objetos que resultan, pueden entonces
ser invocados desde otro programa (u objeto CORBA) desde la red. En este sentido CORBA
se puede considerar como un formato de documentacin legible por la mquina, similar a
un archivo de cabeceras, pero con ms informacin.
CORBA utiliza un lenguaje de definicin de interfaces (IDL) para especificar las interfaces
con los servicios que los objetos ofrecern. CORBA puede especificar a partir de este IDL,
la interfaz a un lenguaje determinado, describiendo cmo los tipos de dato CORBA deben
ser utilizados en las implementaciones del cliente y del servidor. Implementaciones
estndar existen para Ada, C, C++, Smalltalk, Java, Python, Perl y Tcl.

Juan Pablo Marzetti
25

O
b
j
e
t
i
v
o
s

2. Objetivos
Los objetivos planteados en el siguiente trabajo son los siguientes:
Conocer las metodologas de desarrollo de software basadas en modelos:
o Adquirir habilidades para el diseo de modelos que respondan a los
requerimientos de los clientes.
o Determinar la viabilidad y versatilidad de dichas metodologas.
Conocer los detalles de la especificacin de Ingeniera Dirigida por el Modelo
(MDE)
o Adquirir habilidades para el desarrollo de modelos que luego puedan ser
utilizados en el diseo de una arquitectura de software y finalmente el
software propiamente dicho.
o Investigar la visin del Object Management Group (OMG) de MDE llamada
Arquitectura dirigida por el Modelo (MDA) y todas las tecnologas y
herramientas que propone para su desarrollo e implementacin (UML, OCL,
MOF, etc.) y su relacin con MDE.
o Determinar las ventajas que ofrece dicha metodologa en cuanto a
productividad y calidad del software desarrollado.
Proponer como mtodo de trabajo el diseo y desarrollo de software a travs de la
metodologa MDE estudiando el uso de lenguajes especficos de dominio.
Desarrollar un lenguaje especfico de dominio y una herramienta que permita
automatizar el proceso de validacin del modelo y generacin de cdigo para
plataformas y arquitecturas diversas.
Estudiar las herramientas existentes que permitan aportar al desarrollo propio.
Desarrollar la herramienta bajo la premisa de automatizar lo ms posible las
etapas de desarrollo planteadas por MDE.

Juan Pablo Marzetti
27

I
n
g
e
n
i
e
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

3. Ingeniera dirigida por modelos
3.1. Introduccin
La Ingeniera dirigida por Modelos (MDE, Model Driven Engineering, por sus siglas en
ingls) es una metodologa de desarrollo de software orientada a crear modelos o
abstracciones que sean ms cercanas a los conceptos de un dominio en particular, que a
un concepto computacional o algortmico.
El principio bsico de MDE es todo es un modelo as como el principio bsico para la
programacin orientada a objetos es todo es un objeto. En este mbito los modelos
juegan un papel preponderante ya que no slo son simples elementos de documentacin
del software que se disea sino que son los verdaderos directores de todo el proceso de
desarrollo del software. Los modelos se utilizan para definir la implementacin,
transformaciones, aspectos de los artefactos de software, puntos de vista del sistema, y
mucho ms.
Se considera efectivo a un paradigma de modelado para MDE si sus modelos tienen
sentido desde el punto de vista del usuario y pueden servir de base para la
implementacin de los sistemas. Los modelos son diseados a partir de una fuerte
comunicacin entre los gerentes de producto, diseadores y miembros del equipo de
desarrollo. A medida que los modelos se van completando, se habilita el proceso de
desarrollo del sistema.
Esta metodologa, que pertenece al rea del desarrollo de software, no es una receta
cerrada de cmo deben hacerse las cosas. Involucra una amplia gama de variantes que
utilizan el modelado de software como forma principal de expresin. En algunos casos los
modelos son construidos a un cierto nivel de detalle y luego el cdigo es escrito a mano en
una etapa separada. En otros, se genera cdigo a partir de los modelos diseados: puede
generarse esqueletos de cdigo o productos enteros listos para ser distribuidos.

I
n
g
e
n
i
e
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

El uso de UML junto con el mayor nmero de gente trabajando con esta metodologa de
desarrollo ha permitido que MDE se expanda incluyendo estndares de la industria del
software y una potente focalizacin de la metodologa en la arquitectura del software y la
automatizacin del proceso de desarrollo. Esta focalizacin genera niveles de abstraccin
ms altos, lo que permite modelos ms simples con un gran hincapi en los detalles del
problema en cuestin, antes que las plataformas, lenguajes, frameworks y dems
herramientas utilizadas para resolverlo.
El incremento de la automatizacin en el desarrollo se logra utilizando transformaciones
en los modelos: los modelos de mayor nivel de abstraccin son transformados a modelos
de niveles menores hasta que estos ltimos puedan ser ejecutables. Para la ltima etapa
se generar cdigo a partir de los modelos de bajo nivel o se interpretar a los mismos.
3.2. Objetivos de MDE
MDE busca mejorar la productividad. En los actuales contextos empresariales, cuya
complejidad es elevada y en los cuales se verifica una creciente diversidad de sistemas y
plataformas, no puede pretenderse que las aplicaciones nuevas sean compatibles con
todo lo existente y los sistemas futuros. MDE busca aumentar el retorno que una
compaa obtiene de sus esfuerzos en el desarrollo de software a travs de dos maneras:
1. Mejora de la productividad a corto plazo de los desarrolladores: Se incrementa el
valor de los artefactos de software primarios en trminos de cunta funcionalidad
ofrecen.
2. Mejora de la productividad a largo plazo de los desarrolladores: Se incrementa el
tiempo en el cual dichos artefactos se vuelven obsoletos.
El enfoque principal de la mayora de los vendedores de herramientas est orientado al
primer punto de los mencionados precedentemente. La mayora de los artefactos de
software pueden ser generados a partir de modelos ayudando de esa a manera a mejorar
la productividad de los desarrolladores. Sin embargo, luego del proceso de construccin
inicial prcticamente no existe soporte para administrar el ciclo de vida del artefacto de
Juan Pablo Marzetti
29

I
n
g
e
n
i
e
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

software. Los cambios deben ser incorporados en el cdigo fuente generado o en partes
del modelo lo que puede desembocar en problemas cclicos.
En el contexto actual de cambio, conseguir que aumente el tiempo de vida til de los
artefactos de software aporta mayores beneficios y es la prioridad que ms debe tenerse
en cuenta. MDE busca reducir la sensibilidad de los artefactos al cambio y para ello debe
estudiarse las cuatro formas fundamentales de cambio que se pueden observar:
1. Cambio de Personal: Los conocimientos vitales de desarrollo no deberan slo
almacenarse en las mentes de los desarrolladores ya que pueden perderse
fcilmente con los cambios de personal. Dicha informacin debera ser accesible a
otras personas adems de los creadores del artefacto de software. En lo posible
dicha informacin debera estar detallada de tal manera que todos los interesados
puedan entenderla, incluso los clientes.
2. Requerimientos: Los constantes cambios en los requerimientos es un conocido
problema en la ingeniera del software. En las actuales condiciones de cambio de
los negocios se debe desarrollar nuevas funcionalidades ms rpido que nunca,
mientras que los cambios deben tener el menor impacto posible en los sistemas
existentes en trminos de mantenimiento y bajas de servicio. Lo ideal sera que los
cambios se realicen mientras los sistemas siguen funcionando.
3. Plataformas de Desarrollo: Las plataformas son un elemento de constante
evolucin. Para desacoplar el tiempo de vida de un artefacto de software de la
herramienta de desarrollo utilizada para su creacin inicial, es necesario
desacoplar el artefacto o el modelo que lo representa de la herramienta de
desarrollo.
4. Plataformas de Despliegue: Las nuevas plataformas que surgen, las soluciones
middleware, los servidores de aplicacin y dems elementos son lanzados cada vez
ms rpidamente. Para incrementar el tiempo de vida de un artefacto de software
es necesario protegerse contra los cambios en dicha plataforma. El enfoque de
MDA (Arquitectura dirigida por el Modelo) pone especial nfasis en este punto.

I
n
g
e
n
i
e
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

En la mayora de los casos, cuando se habla de MDE, se tiende a asociar la reduccin de la
sensibilidad de los artefactos de software al cambio, con el cambio en las plataformas de
despliegue y se olvida las tres formas anteriores. Sin embargo, las cuatro formas de
cambio son igualmente importantes y se debe crecer en una metodologa que aporte
soluciones en las cuatro direcciones.
Como en cada enfoque de ingeniera del software, la calidad es un aspecto importante en
todo el proceso. Desde el punto de vista de MDE, la calidad del software puede ser
comprobada y asegurada con tres tcnicas diferentes: validacin de modelos,
comprobacin de modelos y pruebas basadas en el modelo.
3.3. Especificacin de modelos
Un modelo puede especificarse en alguna notacin de modelado o un lenguaje de
modelado. Usualmente dichos lenguajes estn orientados a un determinado dominio por
lo que se los llama Lenguaje Especfico de Dominio (DSL por sus siglas en ingls). Los DSL
pueden ser tanto visuales (utilizando formas geomtricas y conexiones) como textuales.
Un modelo especificado con un DSL se llama Modelo Especfico de Dominio por lo que a la
hora de disear un sistema, el mismo ser descrito a partir de varios modelos especficos
de dominio. Y probablemente dichos modelos estarn expresados utilizando diferentes
DSL.
3.3.1. Roles de un Modelo
Segn Khne (Khne 2006) un modelo puede tener los siguientes roles:
Modelo de Muestra: son los que generalmente las personas tienen en mente a la
hora de hablar de modelos en general. Consisten en una representacin 1 a 1 de
partes (o el todo) de los elementos del sujeto real. En este caso no se aplica
ninguna abstraccin. Pueden ser llamados modelos de representacin, modelos de
instancia, modelos singulares o individuales, o modelos por extensin. Un ejemplo
de este rol lo constituyen los planos que utilizan los albailes para construir una
casa.
Juan Pablo Marzetti
31

I
n
g
e
n
i
e
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

Modelo de Tipo: En forma opuesta a los modelos de muestra, esta clase de
modelo captura los aspectos universales de los elementos del sujeto,
clasificndolos segn cierto criterio. Las propiedades del objeto (cuatro patas, dos
ojos, peludo, dientes afilados) son utilizadas para clasificar objetos (por ejemplo:
predador). A este tipo de modelos se los suele llamar tambin modelo de
esquema, modelo de clasificacin o modelo universal. Como los modelos de tipo
son creados a partir de clasificaciones, puede afirmarse que un modelo de muestra
es una instancia de un modelo de tipo de un sistema.

3.3.2. Uso de modelos
Los modelos pueden clasificarse a su vez por la forma en que se utilizan. Un modelo puede
reflejar un original real (como una fotografa) o se puede utilizar como la especificacin de
algo que ser creado (como un plano de construccin). En el primer caso se trata de un
modelo descriptivo mientras que en el ltimo hablamos de un modelo prescriptivo.
Cuando se parte de un modelo descriptivo y luego se llega a uno prescriptivo se le llama
transitivo. Este es el caso en que un original necesita ser modificado (por ejemplo cuando
se va a refaccionar una casa).
Mendoza
San Rafael
San Luis
143
7
Instancia de
modelo de
tipo
Ciudad Ruta
2 1..*
modelo de
muestra
Figura 1. Relacin entre Modelos de Tipo, Modelos de Muestra y los objetos reales

I
n
g
e
n
i
e
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

En la Ingeniera del Software se utilizan muchos modelos en su mayora prescriptivos. Slo
la especificacin de requerimientos es a la vez prescriptiva y descriptiva ya que describe
las necesidades del usuario y prescribe el producto que ser desarrollado. Este rol doble
hace que la especificacin sea el modelo de software ms importante y donde debe
ponerse la mayor atencin.
El problema radica en que la construccin de un modelo descriptivo es muy difcil. Implica
conocer muy bien el original que se describe. En la mayora de los casos el mundo real
de los proyectos de ingeniera de software es un desorden, con requerimientos que nunca
estn completos o precisos. Otro problema es que los modelos descriptivos slo cubren
una pequea parte del universo ya que buscan ser solucin de compromiso entre
simplicidad y realismo. Los modelos prescriptivos por otro lado son fciles de construir
pero tienen el problema de que pueden indicar cualquier cosa que su autor decida. A
continuacin podemos observar en la figura un proceso simplificado de ingeniera de
software donde se definen modelos para las distintas etapas y aspectos:

3.3.4. Metamodelos
Cmo se pueden definir los lenguajes utilizados en los modelos? La respuesta es: a travs
de metamodelos. Un metamodelo, que es frecuentemente denominado como el modelo
de un modelo, constituye un concepto importante para la definicin de modelos. Los
Especificacin de
Requerimientos
Arquitectura
Diseo
Implementacin
Requerimientos
del Usuario
Figura 2. Proceso simplificado de Ingeniera de Software
Juan Pablo Marzetti
33

I
n
g
e
n
i
e
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

metamodelos son siempre modelos de tipo ya que clasifican los elementos de sus
modelos sujeto.
En la siguiente figura podemos observar la jerarqua de cuatro capas de metamodelos de
UML planteada por el OMG. Esta infraestructura consiste en una jerarqua de niveles de
modelo cada uno, con excepcin del primero, caracterizado como una instancia del nivel
superior. El nivel M0 contiene los datos del usuario; el nivel M1 es un modelo de los datos
del nivel M0; el nivel M2 es un modelo del modelo del nivel M1 (tambin referido como
metamodelo). Finalmente el nivel M3 contiene un modelo de la informacin del nivel M2
y se lo denomina meta-metamodelo.

Clase
M3 (MOF)
Atributo Instancia Clase
M2 (UML)
instancia de instancia de instancia de
clasificador
M1 (Modelo Usuario)
Video

+titulo: String
Video1: Video

titulo = Avatar
instancia de instancia de instancia de
trailer
M0 (Instancia de Ejecucin)
unVideo
instancia de
Figura 3. Jerarqua de cuatro capas de Metamodelos de UML
Juan Pablo Marzetti
35

A
r
q
u
i
t
e
c
t
u
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

4. Arquitectura dirigida por Modelos
Los conceptos de Ingeniera dirigida por Modelos son confundidos frecuentemente con
Arquitectura dirigida por Modelos (MDA). Esta ltima metodologa puede ser vista como
la visin propia que tiene el OMG de MDE. El foco de MDA es en la variabilidad tcnica del
software de manera que su especificacin no dependa de una plataforma especfica.
La arquitectura dirigida por modelos es una especificacin detallada por el OMG que
integra diferentes especificaciones y estndares definidos por la misma organizacin.
Estos estndares buscan ofrecer una solucin a los problemas relacionados con los
cambios en los modelos de negocio, la tecnologa y la adaptacin de los sistemas de
informacin a los mismos.
MDA permite el despliegue de aplicaciones empresariales, diseadas de manera agnstica
de la plataforma donde sern desplegadas y con un diseo expresado mediante el uso de
UML y otros estndares. Potencialmente puede realizarse en cualquier plataforma
existente, abierta o propietaria, como servicios web, .Net, Corba, J2EE, u otras.
Su enfoque se orienta al uso de modelos en el desarrollo de software. Prescribe qu clase
de modelos utilizar, cmo esos modelos deben ser diseados y las relaciones entre los
diferentes tipos de modelo. El concepto bsico de MDA es la separacin de la operacin
del sistema, de los detalles en la forma en que el sistema utiliza las capacidades y
funcionalidades de la plataforma.
La metodologa se basa en la idea establecida y acordada de separar la especificacin de
operacin de un sistema de los detalles de implementacin del mismo. Proporciona un
enfoque que implica y requiere herramientas para:
Especificar un sistema independientemente de la plataforma que lo soporte
Especificar plataformas
Elegir plataformas especficas para un sistema y

A
r
q
u
i
t
e
c
t
u
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

Transformar la especificacin del sistema en un detalle especfico para la
plataforma seleccionada.
Los tres principales objetivos de MDA son: portabilidad, interoperabilidad y reutilizacin a
travs de la separacin arquitectnica de los distintos aspectos de un sistema.
MDA se apoya sobre los siguientes estndares para llevar a cabo su funcin:
UML: empleado para la definicin de los modelos independientes de la plataforma
y los modelos especficos de las plataformas de destino. Es un estndar para el
modelado introducido por el OMG.
MOF: establece un marco comn de trabajo para las especificaciones del OMG, a la
vez que provee de un repositorio de modelos y metamodelos.
XMI (XML Metadata Interchange): define una traza que permite transformar
modelos UML en XML para poder ser tratados automticamente por otras
aplicaciones.
CWM (Common Warehouse Metamodel): define la transformacin de los modelos
de datos en el modelo de negocio a los esquemas de base de datos.
4.1. Conceptos
Para poder comprender en profundidad MDA, sus caractersticas, funcionamiento y
aplicacin al proceso de desarrollo a continuacin se exponen los conceptos bsicos que la
metodologa define en su especificacin.
4.1.1. Sistema
Existen dos nociones diferentes de sistema: la nocin teleolgica y la ontolgica. La
primera nocin hace referencia a la funcionalidad y al comportamiento externo del
sistema. El sistema es visualizado como una caja negra, siendo esta visin adecuada para
utilizar o controlar un sistema. La nocin ontolgica puede ser utilizada para construir o
modificar un sistema. Tiene que ver con la construccin y funcionamiento interno del
sistema en una vista de caja blanca.
Juan Pablo Marzetti
37

A
r
q
u
i
t
e
c
t
u
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

Ambas nociones son relevantes a la hora de disear un sistema y MDA tiene en cuenta
estas nociones.
4.1.2. Modelo
El modelo de un sistema es una descripcin o especificacin del mismo y de su entorno
para un cierto propsito. Un modelo es presentado a menudo como una combinacin de
figuras y texto que puede ser escrito en lenguaje de modelado o lenguaje natural.
4.1.3. Punto de Vista
Un punto de vista del sistema es una tcnica de abstraccin que utiliza un conjunto
reducido de conceptos arquitectnicos y reglas para focalizarse en aspectos particulares
del sistema. Aqu abstraccin se utiliza en el sentido de eliminar detalles en orden a
obtener un modelo simplificado.
MDA determina tres puntos de vista: un punto de vista independiente de la computacin,
uno independiente de la plataforma y un punto de vista especfico para la plataforma.
4.1.4. Arquitectura
La arquitectura de un sistema es la especificacin de las partes del mismo, las conexiones
entre ellas, y las normas de interaccin entre las partes del sistema haciendo uso de las
conexiones especificadas.
MDA determina los tipos de modelos que deben ser usados, cmo preparar dichos
modelos y las relaciones que existen entre los mismos.
4.1.5. Plataforma
Es un conjunto de subsistemas y tecnologas que proveen una variedad de funcionalidades
a travs de interfaces y platillas de uso que cualquier aplicacin puede utilizar sin conocer
los detalles de implementacin. En principio una plataforma es una base sobre la que se
construye y ejecuta software. Ejemplos de ellas son: un sistema operativo, las bibliotecas
de ejecucin de un lenguaje de programacin como .NET Framework, la mquina virtual
de Java, etc.

A
r
q
u
i
t
e
c
t
u
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

4.1.6. Independencia de la plataforma
Se trata de una cualidad que un modelo puede exhibir. Implica que el modelo es
independiente de las funcionalidades y caractersticas que ofrece una plataforma. Como
cualquier cualidad, la independencia de la plataforma puede ser susceptible de grados.
Esto significa que un modelo puede asumir la disponibilidad de un cierto grupo de
caractersticas de un tipo muy general de plataforma mientras otro lo hara sobre ciertas
caractersticas de la plataforma CORBA.
4.1.7. Servicios Dominantes
Son servicios disponibles en un amplio rango de plataformas. En MDA dichos servicios se
modelan como independientes de la plataforma. Ejemplo de ellos son: Servicio de
Directorio, Manejo de Eventos, Persistencia, Transacciones, Seguridad, etc.
4.1.8. Aplicacin
Se utiliza este trmino para referirse a un software que ofrece cierta funcionalidad.
4.1.9. Implementacin
Es una especificacin que provee toda la informacin necesaria para construir un sistema
y ponerlo en operacin.
4.1.10. Transformacin de modelos
Es el proceso de convertir un modelo en otro modelo referido al mismo sistema.
4.2. Puntos de vista de MDA
MDA especifica tres puntos de vista en un sistema:
4.2.1. Punto de Vista independiente de la Computacin
Se enfoca en el entorno del sistema y de los requerimientos del sistema. Los detalles de la
estructura y de procesamiento del sistema estn escondidos o an indeterminados. Este
punto de vista puede relacionarse con la vista teleolgica del sistema.
Juan Pablo Marzetti
39

A
r
q
u
i
t
e
c
t
u
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

4.2.2. Punto de Vista independiente de la Plataforma
Se enfoca en la operacin de un sistema mientras esconde los detalles necesarios para
una plataforma particular. Esta vista muestra que parte de la especificacin completa del
sistema no cambia de una plataforma a la otra. Puede utilizarse un lenguaje de modelado
de propsito general o un lenguaje especfico al rea en la cual el sistema ser utilizado.
Esta vista puede compararse con la vista ontolgica del sistema.
4.2.3. Punto de Vista especfico para la Plataforma
Combina el punto de vista independiente de la plataforma junto con los detalles de uso de
una plataforma especfica por un sistema.
4.3. Modelos MDA
MDA especifica tres modelos por defecto de un sistema correspondientes a los tres
puntos de vista de MDA. Adems de estos modelos, tambin se indica un Modelo de la
Plataforma.
4.3.1. Modelo Independiente de la Computacin (CIM)
Se trata de una vista del sistema desde un punto de vista independiente de la
computacin. Este tipo de modelo no muestra detalles de la estructura de los sistemas.
Frecuentemente se lo denomina modelo de dominio y se utiliza para describirlo, un
vocabulario familiar para las personas involucradas en el uso del sistema. Este modelo
muestra al sistema dentro del entorno en el cual ste operar. Esto facilita la presentacin
y compresin de qu es lo que se espera que el sistema haga.
Se asume que el usuario principal del CIM es quien utiliza el sistema o un consultor de
negocios. Este usuario no est obligado a tener conocimientos acerca de los artefactos de
modelado que se ajusten a los requerimientos definidos en el CIM y que se utilicen para
construir la aplicacin.
El modelo independiente de la computacin acta como puente para rellenar el espacio
entre quienes son expertos en el dominio del sistema y sus requerimientos por un lado, y
aquellos que poseen el conocimiento para disearlo y construirlo. Es til para entender el

A
r
q
u
i
t
e
c
t
u
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

problema y tambin como una fuente compartida de vocabulario para su uso en otros
modelos. En una especificacin de un sistema realizada con este enfoque los
requerimientos del CIM deberan ser trazables hasta el PIM y el PSM y viceversa.
4.3.2. Modelo Independiente de la Plataforma (PIM)
Constituye una vista del sistema sin tener en cuenta la plataforma que se utilizar para
construirlo. Exhibe un determinando grado de independencia de la plataforma (no puede
hablarse en trminos absolutos de independencia o dependencia) de tal manera que sea
apropiado para su uso con una variedad de plataformas de tipo similar.
El PIM describe la construccin de un sistema en un nivel ontolgico, es decir, la
construccin del sistema es especificada sin los detalles de implementacin. Un modelo
ontolgico de un sistema se define de la siguiente manera:
Algo es un sistema si, y slo si verifican las siguientes propiedades:
Composicin: un conjunto de elementos de cierta categora (fsica, biolgica,
social, qumica, etc.)
Entorno: conjunto de elementos de la misma categora que la composicin. Estos
dos conjuntos son disjuntos.
Produccin: los elementos de la composicin producen cosas (productos o
servicios) que son entregados al entorno.
Estructura: conjunto de relaciones entre los elementos de la composicin y entre
estos elementos y los del entorno.
Una caracterstica importante es la categora a la cual pertenecen los elementos del
sistema. En el caso de MDA se inicia con un modelo de un negocio o actividad y se finaliza
con un modelo de un sistema de software.
4.3.3. Modelo Especfico para la Plataforma (PSM)
Es una vista del sistema que combina las especificaciones del PIM con los detalles que
especifican cmo un sistema utiliza un tipo particular de plataforma. El modelo especfico
Juan Pablo Marzetti
41

A
r
q
u
i
t
e
c
t
u
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

para la plataforma es una versin detallada del PIM. A la hora de definir un PSM se debe
contar con un modelo de la plataforma particular a la cual se transformar el PIM.
4.3.4. Modelo de la Plataforma
Provee un conjunto de conceptos tcnicos que representan los distintos tipos de
elementos que constituyen la plataforma y los servicios que sta ofrece. Adems indica los
conceptos que representan cmo se utilizar la plataforma por parte de la aplicacin.
4.3.5. Transformacin de un Modelo
Es el proceso de convertir un modelo en otro modelo del mismo sistema.

Figura 4. Transformacin de un modelo

En la figura superior se observa que el modelo independiente de la plataforma y otra
informacin son combinados por la transformacin en orden a obtener el modelo
especfico para la plataforma.
4.4. Tecnologas que conforman MDA
La familia de estndares de OMG para el modelado de software est compuesta de las
siguientes tecnologas:

A
r
q
u
i
t
e
c
t
u
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

La especificacin del Lenguaje Unificado de Modelado (UML)
La especificacin de Meta Object Facility (MOF)
La especificacin de Intercambio de Metadatos con XML (XMI)
A continuacin estudiaremos brevemente cada una de ellas.
4.4.1. Lenguaje Unificado de Modelado (UML)
La especificacin de UML define un lenguaje grfico para visualizar, especificar, construir y
documentar artefactos de sistemas de objetos distribuidos. Provee la fundacin para
especificar y compartir modelos de objetos distribuidos basados de CORBA. La
especificacin incluye los siguientes aspectos:
Una definicin formal del metamodelo UML, el lenguaje abstracto para especificar
modelos UML.
Una notacin grfica concreta para expresar modelos UML.
Un conjunto de interfaces CORBA para representar y administrar modelos UML
Un formato XMI para intercambiar modelos UML.
4.4.2. Meta Object Facility (MOF)
La especificacin MOF define un lenguaje abstracto y un framework para especificar,
construir y administrar metamodelos de una manera independiente y neutral de la
tecnologa. Adicionalmente MOF define un framework para implementar repositorios que
alberguen metadatos (modelos por ejemplo) descritos por los metamodelos denominado
CWM (Common Warehouse Model). Utiliza mapeos tecnolgicos estndar para
transformar metamodelos MOF en APIs de metadatos. Esto aporta APIs de repositorios de
metadatos consistentes e interoperables con productos de diferentes fabricantes y
diferentes tecnologas de implementacin.
La especificacin MOF incluye los siguientes aspectos:
Una definicin formal de el meta-metamodelo MOF
Un mapeo para relacionar metamodelos MOF arbitrarios con CORBA IDL.
Juan Pablo Marzetti
43

A
r
q
u
i
t
e
c
t
u
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

Un conjunto de interfaces reflectivas CORBA IDL para administrar metadatos
independientes de los metamodelos.
Un conjunto de interfaces CORBA IDL para representar y administrar metamodelos
MOF.
Un formato XMI para intercambiar metamodelos MOF.
UML y MOF son vistos normalmente en el contexto de una arquitectura conceptual de
metadatos en capas que fue descrita en la seccin 3.3.4. Metamodelos. Los metamodelos
de UML y MOF han sido diseados para estar alineados arquitectnicamente ya que
comparten un subconjunto comn de las construcciones bsicas.
4.4.3. Intercambio de Metadatos con XML (XMI)
La especificacin XMI es un estndar de OMG para el intercambio de informacin
metadatos a travs del lenguaje XML. Puede utilizarse para intercambiar cualquier tipo de
metadatos cuyo modelo pueda ser expresado en MOF. El uso ms comn de XMI es el de
un formato de intercambio para modelos UML aunque puede utilizarse para serializar
modelos descritos en otros lenguajes.
Uno de los objetivos de XMI es permitir un intercambio fcil de metadatos entre
herramientas de modelado basadas en UML y repositorios de metadatos basados en MOF
en entornos heterogneos y distribuidos. XMI tambin es utilizado frecuentemente como
el medio por el cual los modelos son pasados desde las herramientas de modelado a las
herramientas de generacin de cdigo como parte del proceso de ingeniera dirigida por
modelos.
4.5. Uso de MDA
El proceso de construccin del sistema comienza con la definicin del CIM o modelo de
dominio. Este modelo ser definido por un analista de negocios en cooperacin con el
usuario del negocio. El CIM ser transformado por un Arquitecto de Negocios en el PIM.
Incorporar sus conocimientos arquitectnicos al CIM sin mostrar los detalles de la
plataforma utilizada. Finalmente, el PIM ser especializado teniendo en cuenta una

A
r
q
u
i
t
e
c
t
u
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

plataforma determinada para obtener el PSM. En este punto se hace evidente que es
necesario un modelo detallado de la plataforma para completar este proceso. La ltima
transformacin ser realizada por un especialista en la plataforma seleccionada. El PSM
resultante puede ser una implementacin en la medida en que provea toda la informacin
necesaria para construir el sistema y ponerlo en funcionamiento.

En este proceso se agrega conocimiento en cada etapa por parte de diferentes
profesionales. El desafo principal es la transformacin entre los diferentes modelos. En
los enfoques tradicionales estas transformaciones son mayormente ineficientes debido a
que no se utilizan modelos formales. Sin el uso de dichos modelos es imposible definir
transformaciones formales que puedan ser automatizadas completa o parcialmente.
4.5.1. Proceso MDA para sistemas complejos
En la prctica el proceso de transformacin entre los CIM a los PSM podra ser mucho ms
complejo que el graficado en la Figura 5. Ente los distintos tipos de modelo pueden
generarse huecos que no sea posible rellenar con una transformacin directa. En dichos
casos podra tenerse varios modelos de cada tipo que estn interrelacionados y distintos
niveles de abstraccin. Dentro de este conjunto global de modelos podran realizarse
transformaciones en una misma capa de abstraccin. Por ejemplo, un PIM puede
transformarse en otro PIM ms detallado varias veces. Este tipo de transformacin
horizontal se agrega a las transformaciones verticales entre los distintos tipos de modelos.

CIM PIM PSM
Figura 5. Transformaciones entre los distintos modelos
Juan Pablo Marzetti
45

A
r
q
u
i
t
e
c
t
u
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

Como puede verse en la Figura 6, ya no hay una separacin en el paso de un tipo de
modelo a otro sino que se van dando sucesivas transformaciones que enriquecen los
modelos hasta que es posible dar el salto a la siguiente etapa.
4.6. Relacin entre MDA y MDE
La metodologa de trabajo MDA pone su foco en la arquitectura, los artefactos y los
modelos. Su objetivo principal es la variabilidad tcnica determinando una diferencia
entre los modelos independiente y dependiente de la plataforma y definiendo las
transformaciones necesarias para pasar de uno a otro. Las dimensiones con las que
trabaja son: abstracta (que se corresponde con el PIM) y concreta (se corresponde con el
PSM).

Figura 7. Relacin entre MDA y MDE
CIM CIM CIM
PIM PIM PSM
PSM PSM
Figura 6. Transformaciones para sistemas complejos

A
r
q
u
i
t
e
c
t
u
r
a

d
i
r
i
g
i
d
a

p
o
r

m
o
d
e
l
o
s

MDE, por otro lado, es un concepto ms amplio que MDA. Agrega mltiples dimensiones
de modelado y, lo que es ms importante, la nocin de un proceso de ingeniera de
software. El foco de MDE se ubica adems en la variabilidad de dominios de aplicacin
permitiendo la coexistencia de dimensiones de modelado para una variedad de reas de
aplicacin y aspectos arquitectnicos.
Juan Pablo Marzetti
47

M
o
d
e
l
a
d
o

y

M
e
t
a
m
o
d
e
l
o
s

5. Modelado y Metamodelos
5.1. Dimensiones de Modelado
Un enfoque que busque cumplir con los objetivos de MDE debe tener ms que la
dimensin abstracta y concreta que presenta MDA. En esta dimensin podemos hablar
solo de si un modelo es abstracto (independiente de la plataforma) con respecto a otro
modelo o no. Kent (Kent, 2002) define dos categoras adicionales de dimensiones que son
necesarias para trabajar con MDE. La primera categora contiene varias dimensiones a
considerar:
La distincin de modelos sobre la base del rea a la que pertenecen: diferentes
usuarios pueden tener distintos puntos de vista del sistema focalizados en un
subconjunto de las funcionalidades del mismo. Por ejemplo: el mdulo de ventas,
el de stock, el de clientes.
La enumeracin de aspectos del sistema: ejemplos de esta dimensin podran ser
informacin/datos, presentacin, control de concurrencia, seguridad, distribucin
y manejo de errores.
En la segunda categora podemos encontrar dimensiones que estn menos relacionadas
con los aspectos tcnicos del sistema pero corresponden a asuntos organizacionales. Las
dimensiones en esta categora incluyen: autora, control de versiones y de configuracin,
ubicacin (en el caso que el sistema sea desarrollado de manera distribuida) e interesados
(expertos de negocio o desarrolladores).
En los proyectos de desarrollo de software es necesario determinar las dimensiones
importantes para cada caso particular. En la mayora ser importante autora y control de
versiones, pero otras dimensiones necesitan que se identifiquen puntos de inters como
saber qu reas de inters juegan un rol en el sistema y qu aspectos del sistema son
importantes. Otra decisin importante es el nivel de abstraccin necesario para ser
utilizado en el proceso y qu interesados estarn involucrados en el mismo. Esto permite

M
o
d
e
l
a
d
o

y

M
e
t
a
m
o
d
e
l
o
s

definir cmo sern los modelos para que todo el mundo pueda entenderlos. A la hora de
disear los modelos en el proceso de desarrollo del software, cada modelo ser ubicado
en la interseccin de las dimensiones mencionadas. La variedad de dimensiones en una
interseccin ser de especial importancia a la hora de elegir un lenguaje de modelado
para ese modelo en particular.
5.2. Tipos de Metamodelado
5.2.1. Metamodelado Lingstico
Un metamodelo lingstico de A para el modelo B puede ser visto como un modelo del
lenguaje de modelado en que B esta expresado. En otras palabras, un metamodelo A
define el lenguaje de un modelo B. En este caso, los elementos del modelo B son
instancias lingsticas de de los elementos del metamodelo A. La instanciacin lingstica
entre un elemento y un tipo lingstico se basa en la asuncin de que el tipo representa
(un fragmento de) un lenguaje definiendo qu expresiones son sentencias vlidas para el
mismo. De esta manera un elemento e es una instancia lingstica del tipo T si esta existe
en la extensin de significados de T. La instanciacin lingstica se ocupa de la forma de
los elementos en el sentido que define los aspectos sintcticos y estructurales del modelo:
su sintaxis abstracta. Adems se define parte de la semntica del modelo como son los
tipos semnticos, los elementos semnticos estticos y los dinmicos:
Tipo semntico: El tipo semntico de un objeto se define a travs del proceso de
metamodelado y permite razonamientos tales como: Estudiante deriva de la
construccin del metamodelo Entidad y por ello es una clase de objeto del mundo
real y no una relacin.
Semntica Esttica: Son las condiciones bien formadas entre los elementos
sintcticos. Por ejemplo: ausencia de herencias circulares. Se las conoce como
Restricciones.
Semntica Dinmica: Son los comportamientos de las entidades pertenecientes a
la especificacin del metamodelo como E/S, reaccin a estmulos, efectos de
ejecutar una operacin, etc.
Juan Pablo Marzetti
49

M
o
d
e
l
a
d
o

y

M
e
t
a
m
o
d
e
l
o
s

Ejemplos de metamodelado lingstico son:
Business Process Modeling Notation (BPMN): es una notacin grfica
estandarizada que permite el modelado de procesos de negocio en un formato de
flujo de trabajo (workflow) propuesta por OMG.
Modelo Entidad Relacin: es una herramienta para el modelado de datos de
un sistema de informacin. Estos modelos expresan entidades relevantes para un
sistema de informacin as como sus interrelaciones y propiedades.
UML
5.2.2. Metamodelado Ontolgico
Adems del metamodelado lingstico existe la dimensin ontolgica que resulta
igualmente importante. Mientras que los metamodelos lingsticos definen el lenguaje de
un modelo (incluyendo su sintaxis abstracta, sus tipos semnticos, elementos semnticos
estticos y dinmicos), los metamodelos ontolgicos definen las semnticas inherentes
del modelo. stas describen los significados internos de los recursos modelados y proveen
las bases para razonar acerca de los conceptos estudiados. Por ejemplo: un estudiante es
una persona humana que puede ser varn o mujer y est asistiendo a una institucin
educativa. Las ontologas son esenciales en la definicin de lenguajes declarativos: estos
lenguajes definen el qu y no el cmo.
5.3. Jerarquas de Metamodelos
En la Figura 3 observamos la jerarqua de metamodelos de UML. Con lo expuesto
anteriormente se concluye que esta jerarqua es una jerarqua de metamodelado
lingstico. Ms an, la mayora de las jerarquas de metamodelado existentes pertenecen
a esta categora.
5.3.1. Jerarquas de Metamodelos Ontolgicos
Un ejemplo de dicha jerarqua puede verse en la Figura 8 donde la capa superior describe
conceptos tecnolgicos de manera abstracta. No estn sujetos a plataformas especficas y
son similares a los conceptos de los modelos independientes de la plataforma de MDA. Se

M
o
d
e
l
a
d
o

y

M
e
t
a
m
o
d
e
l
o
s

muestra un Dataset que describe una porcin de datos persistentes. Los elementos en
esta capa actan de metaclases para conceptos especficos de dominio. Una posible
instancia, segn la figura, sera Artculo. Esta capa intermedia se utiliza como un lenguaje
de modelado especfico para el dominio. En el ejemplo, el administrador de contenidos
modelado es un libro de recetas de cocina online que almacena artculos llamados
recetas. Un diario online podra tener artculos llamados Publicidad, Noticia, Editorial.

5.3.2. Combinacin de jerarquas de metamodelado lingstico y ontolgico
Se ha visto un ejemplo de ambas jerarquas de metamodelado para comprender y argir
que ambas son importantes a la hora de trabajar con un enfoque MDE que se basa en el
modelado.
De lo sealado anteriormente surge la necesidad de una infraestructura que soporte
ambos tipos de modelo de una manera accesible y personalizable y que sea
dinmicamente extensible. Estos requerimientos surgen de las metas que se propone
MDE consistentes en hacer que los artefactos de software puedan sobrevivir a los cambios
en el personal y de los requerimientos del negocio. La extensibilidad dinmica requiere la
capacidad de extender el conjunto de tipos de dominio disponibles para modelar de
Jerarqua de
Metamodelos
Elementos de
Ejemplo
Capa
Tecnolgica
Capa del
Dominio del
Negocio
Capa de
Modelo
DataSet
Articulo
Receta
Figura 8. Ejemplo de Jerarqua de Metamodelos Ontolgicos
Juan Pablo Marzetti
51

M
o
d
e
l
a
d
o

y

M
e
t
a
m
o
d
e
l
o
s

manera dinmica. Esto, a su vez, requiere la capacidad de definir metatipos de dominio
(para el modelado ontolgico).
El resto de metas que plantea MDE precisan adems modelos intercambiables, concisos y
que permitan ser relacionados por el usuario de manera que identifique en ellos los
elementos del dominio del problema que ste conoce. Con lo expuesto hasta ahora se
deduce que cualquier tcnica de MDE necesita de ambos tipos de metamodelado cuya
combinacin permite nuevos beneficios para el diseo. Se podra utilizar jerarquas
lineales y no lineales, la definicin de elementos como elementos del lenguaje o
elementos de bibliotecas, y la definicin de controles estrictos en las jerarquas de
metamodelado.
5.3.3. Jerarquas Lineales y No lineales
El concepto de estereotipo de UML puede ser considerado como la solucin para
combinar metamodelados lingsticos y ontolgicos. Consiste en un mecanismo liviano
para extender el metamodelo. En lugar de introducir capas nuevas al metamodelo, las
existentes son extendidas a travs de etiquetas en los elementos. El uso de los
estereotipos presenta dos ventajas:
1. Son fciles de utilizar ya que los usuarios no tienen que conocer otra jerarqua de
metamodelado.
2. Este concepto es fcil de implementar en las herramientas CASE ya que el
metamodelo no sufre modificaciones en su estructura y puede incluso codificarse
previamente (y estticamente) en la herramienta.
Estas ventajas tienen su lado negativo ya que los estereotipos introducen un
mecanismo de clasificacin adicional que se conjuga con la, ya existente, imprecisin
de la instanciacin semntica de UML. Muchos de los perfiles UML existentes como
EAI (Enterprise Application Integration: integracin de aplicaciones de negocio, OMG
2004) usan su propio metamodelo junto con el de UML. De esto se concluye que el uso
de estereotipos no es suficiente para crear un lenguaje propio. Una jerarqua de

M
o
d
e
l
a
d
o

y

M
e
t
a
m
o
d
e
l
o
s

metamodelos debera soportar la extensin de manera que se puedan definir nuevas
familias de lenguajes especficos.
El modelo de una meta-capa con estereotipos casi no provee estructura y no es
suficiente para definir nuevos modelos. El uso de jerarquas de metamodelos con
mltiples capas ofrece a quien utiliza una herramienta de MDE la flexibilidad adicional
de extensiones ya que puede utilizar metamodelos personalizados para modelar su
aplicacin con los beneficios que un DSL puede ofrecer. Pueden disponerse mltiples
metamodelos en diferentes jerarquas.
5.3.4. Elementos de lenguaje versus elementos de biblioteca
A la hora de definir un lenguaje para un desarrollo basado en MDE que tenga en cuenta
los conceptos mencionados precedentemente es necesario definir si los elementos
particulares sern definidos sobre el modelo ontolgico o sobre el lingstico. Si
observamos un lenguaje de programacin orientado a objetos podemos observar que se
distingue entre los elementos y conceptos que pertenecen al ncleo del lenguaje y
aquellos que son clases pertenecientes a bibliotecas.
La estrategia adoptada por la mayora es una definicin lo ms pequea posible dentro del
ncleo del lenguaje y el resto de conceptos ubicarlos en las bibliotecas de clase. Esto
ayuda a:
Mantener la definicin del lenguaje lo ms simple posible
Mantener la estabilidad de las mquinas virtuales que soportan los lenguajes
incluso si se reestructuran profundamente los conceptos pertenecientes al mundo
del lenguaje, ya que la mayor parte de estos se define en las bibliotecas de clase.
Permitir al usuario una mayor flexibilidad sobre el lenguaje: este puede elegir
utilizar otras bibliotecas pero no modificar el ncleo del lenguaje.
Se puede afirmar que de la experiencia con los lenguajes orientados a objetos, la
instanciacin lingstica debe mantenerse lo ms pequea posible y definir la mayor
cantidad posible de elementes dentro de la jerarqua de clasificacin ontolgica. Incluso
Juan Pablo Marzetti
53

M
o
d
e
l
a
d
o

y

M
e
t
a
m
o
d
e
l
o
s

puede aprenderse de esta experiencia qu conceptos deberan ser tomados como bsicos
para ser incluidos dentro del ncleo de un lenguaje. Atkinson and Khne indican que los
nicos conceptos o mecanismos que la definicin de un lenguaje dirigido por modelos son
aquellos relacionados con:
Instanciacin de tipos/instancias
Especializacin
Modelos basados en grafos
Presentacin (sintaxis concreta)
Reflexin
Juan Pablo Marzetti
55

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

6. Lenguajes Especficos de Dominio
6.1. Introduccin
Al hablar de MDE y Metamodelado hemos dicho que estos conceptos extienden MDA ms
all de la dimensin concreto/abstracto definiendo en cierta manera un marco de trabajo
de mltiples dimensiones e intersecciones y con ello la posibilidad de expresin a travs
de diferentes modelos.
Anteriormente se ha indicado que las dimensiones que se pueden encontrar en una
interseccin juegan un papel importante en la eleccin de un lenguaje de modelado para
un modelo particular. Por ejemplo: un lenguaje de modelado puede estar influenciado por
las reas de inters, los interesados, y el nivel de abstraccin. En dicho caso podemos
hablar del mencionado lenguaje como un Lenguaje Especfico de Dominio (DSL).
6.2. Definicin
Un DSL puede ser definido como un lenguaje de programacin o la especificacin de un
lenguaje ejecutable que ofrece a travs de notaciones apropiadas y abstracciones un
poder de expresin focalizado y usualmente restringido a un cierto dominio de problemas.
La especificidad de dominio de un lenguaje no es una medida absoluta. Cualquier lenguaje
tiene un cierto mbito de aplicacin aunque algunos pueden ser ms restringidos que
otros. Puede distinguirse dos tipos de dominios a los que puede orientarse un DSL:
Dominios de conocimiento: rea del conocimiento o actividad caracterizada por
un conjunto de conceptos y terminologas que entienden y utilizan los expertos en
la dicha rea o actividad.
Familias de Sistemas: Conjunto de sistemas de software que exhiben
funcionalidades similares. Este dominio es una clase especializada del anterior.


L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

Los lenguajes pueden ser comparados basados en el nmero de instrucciones de cdigo
necesarias para implementar una funcin especfica. De esta manera los lenguajes que
tienen un nmero menor de instrucciones son ms especficos que los de mayor cantidad.
Algunos ejemplos de lenguajes especficos de dominio son los siguientes:
Lenguaje Descripcin
HTML Lenguaje para el marcado de pginas web e
hipertexto.
LATEX Lenguaje para generar documentos.
Make Lenguaje para automatizar el proceso de
construccin de software.
SQL Lenguaje para realizar consultas y
administracin de base de datos.
Figura 9. Lenguajes Especficos de Dominio conocidos

A lo largo de esta dcada se ha revitalizado el inters por los lenguajes especficos de
dominio con el surgimiento del paradigma del desarrollo dirigido por modelos. Debemos
tener en cuenta que este concepto no es algo nuevo, ya en los aos 50 se idearon DSL
para programar aplicaciones en maquinas controladas numricamente. A modo de
ejemplo se puede mencionar BNF para especificar gramticas, que fue desarrollado
durante 1959. Los llamados lenguajes de cuarta generacin (4GLs) son usualmente DSLs
para aplicaciones con fuerte uso de bases de datos. Se puede encontrar tambin a los DSL
bajo otros nombres.
Es preciso destacar que un DSL que se utilice como lenguaje de modelado no
necesariamente debe ser visual y grfico. Un modelo es una representacin abstracta de
la realidad y puede ser expresado utilizando un DSL textual. A partir de este momento al
hablar de lenguajes especficos de dominio haremos foco en los que son textuales. No
obstante eso, los conceptos presentados en este captulo son mayormente aplicables al
estudio y definicin de DSLs tanto grficos como textuales.
Juan Pablo Marzetti
57

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

6.3. Elementos utilizados en la definicin de un lenguaje
6.3.1. Gramticas libres de contexto
Las gramticas libres de contexto permiten especificar la mayora de los lenguajes de
programacin, de hecho, la sintaxis de la mayora de ellos est definida mediante este tipo
de gramticas. Cuando se las crea, se construye una especificacin de una sintaxis
concreta. La gramtica entonces debe establecer todas las palabras clave y otros smbolos
que luego estarn presentes en un programa del nuevo lenguaje.
Una gramtica libre de contexto se puede definir mediante una 4-tupla:
G = <V,,S,P>
V es el conjunto finito de caracteres no terminales o variables.
es un conjunto finito de smbolos terminales, disjunto a V.
S es la variable inicial, la cual es usada para representar la sentencia completa. Debe ser
un elemento de V.
P es un conjunto finito de producciones. Se define como una relacin desde V a (V U )+.
A modo de ejemplo se puede mostrar la gramtica libre de contexto de un lenguaje que
consiste en todas las cadenas que se pueden formar con las letras a y b, de manera tal que
la cantidad de a sea distinta al total de b.
G = < {S, U, V, T}, {a,b}, S, P >
Donde las relaciones de P serian las siguientes:
S U | V
U TaU | TaT
V TbV | TbT
T aTbT | bTaT |

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

Siendo S el smbolo inicial, T genera todas las cadenas con la misma cantidad de letras a
que b, U genera todas las cadenas con mas letras a, y V todas las cadenas con mas letras b.
La estructura subyacente de una gramtica libre de contexto es un rbol de derivacin,
donde cada nodo representa:
la aplicacin de una regla de produccin durante el reconocimiento de un
elemento.
un smbolo bsico, es decir, un smbolo terminal.
Las distintas alternativas al obtener la expresin a partir del smbolo inicial pueden
generar en algunos casos arboles de derivacin distintos. En estos casos, decimos que la
gramtica es ambigua. Este tipo de gramtica es ms difcil de procesar, ya que el
analizador no puede conocer siempre qu regla aplicar.
Las gramticas libre de contexto solamente permiten especificar lenguajes textuales. No
se puede crear un lenguaje grafico usando nicamente una gramtica libre de contexto. Si
quisiramos hacerlo necesitaramos una extensin de estas gramticas llamada gramtica
de atributos.
6.3.2. Gramtica de atributos
Las gramticas de atributos son una extensin de las gramticas libre de contexto a las
cuales se les asocian atributos a sus smbolos no terminales. Estos atributos pueden ser de
cualquier tipo, por lo que en muchos casos poseen una estructura compleja. A su vez, se
utilizan para esconder informacin del elemento que representan. La forma abstracta
completa de un elemento se puede crear como un atributo de un elemento concreto,
como es una palabra clave.
Estos atributos tienen que ser consistentes, tanto en lo que significan como en el nmero
de los mismos asociado a cada terminal. Sus valores se calculan mediante acciones, reglas
o funciones semnticas asociadas a cada produccin. Por lo que, en general, las funciones
semnticas toman como argumentos cero o ms atributos de los smbolos que forman
Juan Pablo Marzetti
59

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

parte de la produccin, y solo pueden tomar como argumento los atributos de los
smbolos a los que estn asociados en la produccin.
Los atributos se dividen en dos grupos: sintetizados y heredados. Los atributos
sintetizados salen de la evaluacin de las reglas y pueden usar valores de atributos
heredados. Los atributos heredados son pasados desde los nodos superiores del rbol de
evaluacin.
6.4. Definicin de un lenguaje especfico de dominio
Para definir un nuevo lenguaje es necesario definir su sintaxis abstracta, su sintaxis
concreta y su semntica.
6.4.1. Sintaxis abstracta
La sintaxis abstracta de un lenguaje describe su vocabulario, es decir, los conceptos
provistos por el lenguaje y como estos conceptos se pueden combinar para crear
modelos. Una sintaxis abstracta consiste entonces de una definicin de los conceptos, de
las relaciones que existen entre estos conceptos y las reglas de buena formacin que
determinan cmo dichos conceptos pueden ser combinados de una manera correcta.
Es importante enfatizar en este punto que la sintaxis abstracta del lenguaje es
independiente de su sintaxis concreta y de la semntica asociada. La sintaxis abstracta
define la forma y la estructura de los conceptos del lenguaje, sin considerar su
presentacin o su significado.
9.4.2. Sintaxis concreta
Todos los lenguajes proveen una notacin que facilita la representacin y la construccin
de modelos o programas escritos en dicho lenguaje. Esta notacin tambin se la conoce
como sintaxis concreta. Las clases de sintaxis concretas se pueden dividir en dos tipos
principales: sintaxis textual y sintaxis visual.
Una sintaxis textual permite escribir modelos o programas de manera textual. Puede
tener varias formas, pero tpicamente consiste de una seccin de declaraciones, donde se

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

declaran los objetos y variables que van a estar disponibles dentro del programa y de un
conjunto de sentencias asociadas.
La ventaja de las sintaxis textuales es la posibilidad de modelar o escribir expresiones
complejas. Sin embargo, ms all de cierta cantidad de lneas se vuelve muy difcil de
comprender y manejar.
Una sintaxis visual presenta un modelo o programa en forma de diagramas. Una sintaxis
visual consiste de un nmero de iconos grficos que representan vistas de un modelo
subyacente. Un ejemplo muy conocido de sintaxis visual es un diagrama de clases, el cual
provee una buena forma representar una vista de las relaciones y conceptos de un
modelo.
El principal beneficio de una sintaxis visual es la habilidad de expresar mucha informacin
de una manera intuitiva y entendible. La desventaja es: solamente ciertos detalles pueden
ser expresados en un grafico ya que si se quisiera expresar todo el mismo se volvera
demasiado complejo e incomprensible.
En la prctica se utiliza una mezcla de ambas para aprovechar los beneficios aportados por
cada una. As, los lenguajes frecuentemente usan las notaciones visuales para representar
las vistas de alto nivel de un modelo, mientras que las sintaxis textuales se usan para
capturar los detalles.
6.4.3. Semntica
La sintaxis abstracta no define que significan los conceptos dentro de un lenguaje. Por lo
tanto se precisa informacin adicional para capturar la semntica de dicho lenguaje. Es
importante definir la semntica de un lenguaje ya que se establece qu representa y qu
significan las construcciones en dicho lenguaje. De otra forma se podra malinterpretar.
Por ejemplo, aunque se tiene una idea intuitiva de qu se quiere representar con una
mquina de estados, es probable que la semntica detallada de un lenguaje est abierta a
la mala interpretacin si no es definida de manera precisa. Qu es exactamente un
estado? Qu significa que ocurra una transicin? Qu pasa si dos transiciones salen del
Juan Pablo Marzetti
61

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

mismo estado? Cul ser elegida? Todas las respuestas a estas preguntas deben ser
capturadas por la semntica de este lenguaje.
6.4.4. Relaciones
En el mundo real, los lenguajes no estn aislados, sino que estn relacionados con otros
lenguajes. Esto se puede dar de varias maneras:
Va traduccin: donde los conceptos de un lenguaje son traducidos a
conceptos de otro lenguaje de equivalencia semntica.
Abstraccin: donde el lenguaje puede estar relacionado con un segundo
lenguaje el cual tiene un diferente nivel de abstraccin.
La captura de estas relaciones es una parte importante de la definicin del lenguaje y sirve
para posicionar el nuevo elemento en el contexto del mundo. Adems, las relaciones
existentes entre los componentes internos del lenguaje, como entre la sintaxis concreta y
la abstracta son una parte importante de su arquitectura.
6.4.5. Beneficios al definir un DSL.
Por qu es necesario definir un DSL? Como respuesta a esta pregunta podramos decir
que simplemente, porque permiten especificar el dominio de mejor manera. Los
beneficios son los siguientes:
Abstracciones especficas del dominio: Un DSL provee abstracciones predefinidas
para representar directamente conceptos del dominio de aplicacin. De esta
manera los expertos del dominio pueden entender, validar, modificar y
frecuentemente desarrollar programas en el DSL.
Sintaxis concreta especfica del dominio: Un DSL ofrece una notacin natural para
un dominio determinado y evita las congestiones sintcticas que resultad de
utilizar un lenguaje de propsito general (GPL).
Verificacin de errores especfica del dominio: Un DSL permite construir
analizadores sintcticos que encuentren mayor cantidad de errores que los que

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

pertenecen a un GPL y pueden reportar dichos errores en un lenguaje familiar al
experto del dominio.
Optimizaciones especficas del dominio: Un DSL da la oportunidad de generar
cdigo optimizado basado en el conocimiento especfico del dominio, que
usualmente no est disponible para el compilador de un GPL.
Soporte para herramientas especficas del dominio: Un DSL da la oportunidad de
mejorar cualquier aspecto de los entornos de desarrollo incluyendo editores,
depuradores, control de versiones, etc. El conocimiento especfico del dominio que
captura un DSL puede utilizarse para proveer herramientas inteligentes a los
desarrolladores.
Al contrario de los GPLs, un DSL no necesita ser ejecutable. El modelo que se construye se
puede utilizar para representar el programa a implementar en otro lenguaje.
6.5. Sintaxis abstracta
El primer paso en el diseo de un lenguaje de modelado es construir su sintaxis abstracta.
Este paso es tan importante como construir un modelo del sistema en un diseo
orientado a objetos. La sintaxis abstracta describe los conceptos y las relaciones existentes
entre ellos. Adems, define reglas que determinan si un modelo escrito en ese lenguaje es
un modelo vlido. Estos conceptos, relaciones y reglas identificados en este paso proveen
el vocabulario y la gramtica para construir los modelos utilizando este lenguaje.
As, esta sintaxis constituye la base sobre la cual los otros artefactos del lenguaje se van a
definir.
6.5.1. Modelado de la sintaxis abstracta
Como se mencion, el propsito del modelo de la sintaxis abstracta es describir los
conceptos del lenguaje y las relaciones existentes entre ellos. En el contexto de la
definicin del lenguaje, un concepto puede ser cualquier cosa que represente parte del
vocabulario del lenguaje. El trmino de sintaxis abstracta enfatiza el hecho de que el foco
se encuentra en la representacin abstracta de estos conceptos y no en su representacin
Juan Pablo Marzetti
63

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

concreta. Como consecuencia de esto, la sintaxis abstracta se enfoca en las relaciones
estructurales existentes entre los conceptos del lenguaje y no en describir su semntica.
El modelo de una sintaxis abstracta tambin debe describir las reglas con las cuales se
determina si un modelo escrito en ese lenguaje est bien formado, es decir, es
sintcticamente vlido. Esto proporciona una descripcin ms detallada de las reglas
sintcticas del lenguaje que si slo describiramos los conceptos y sus relaciones. Las
reglas de buena formacin son particularmente tiles cuando se quiere implementar una
herramienta de soporte del lenguaje, ya que se pueden usar para validar el grado de
correccin de los modelos creados.
6.5.2. Proceso
Se pueden enumerar algunos pasos importantes en el desarrollo del modelo de una
sintaxis abstracta:
1. Identificacin de conceptos
2. Modelado de los mismos
3. Validacin y Verificacin de los modelos.
6.5.2.1. Identificacin de los conceptos
El primer paso en el modelado de la sintaxis abstracta de un lenguaje es utilizar cualquier
informacin disponible que ayude a identificar los conceptos del lenguaje, y cualquier
regla obvia que posibilite validar o invalidar esos modelos.
Los conceptos del dominio del problema tienen algunas caractersticas que los hacen
buenos candidatos a la hora de definir el lenguaje:
Son conocidos y usados: se usan frecuentemente mientras se habla con los
clientes, y tambin entre los desarrolladores. Esto hace que no sea necesario
introducir nuevos conceptos en el lenguaje, ya que se trabaja con los existentes,
usados y aceptados. Incluso la gente se siente ms cmoda con esos conceptos ya
que no tienen que invertir tiempo en aprenderlos.

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

Frecuentemente ya tienen establecida una semntica: el lenguaje se puede
definir entonces en base a estas definiciones existentes. Por ejemplo, en el
dominio de las aplicaciones para dispositivos mviles, se conoce el concepto de
soft key: son dos o ms teclas cuya funcin cambia basado en el contexto de la
aplicacin. De la misma manera, en todos los dominios existen conceptos
conocidos inherentes a ellos. Si la semntica de un concepto en particular no
puede ser definida, lo ms probable es que no sea un concepto relevante para el
lenguaje.
Establecen una relacin natural con el problema: hace que la creacin del modelo
sea ms fcil y hace posible operaciones como la reutilizacin de elementos del
modelo en el dominio. Una estrecha relacin con el dominio hace que los modelos
sean fciles de leer, entender, recordar, chequear y comunicar a los dems
integrantes del equipo de desarrollo. Es bueno recordar que no todos los
conceptos del dominio del problema son candidatos a ser conceptos del lenguaje.
Los Conceptos comunes que tienen todas las aplicaciones o productos no son
normalmente parte del lenguaje. Por qu querramos modelar algo que permanece
siempre igual? En ese caso debera proveerse mediante bibliotecas o componentes o ser
producido directamente por el generador. Al modelar un lenguaje deberan ser
modelados solamente los conceptos que permiten describir alguna variacin.
Los conceptos que pueden ser identificados a partir de una combinacin de otros
existentes tambin deben ser excluidos. Por ejemplo, en el caso de telefona mvil, las
acciones de cliquear, cancelar y seleccionar pueden ser representadas por diferentes
relaciones de navegacin: una para la seleccin, otra para cancelar y otra para acceder a
los mens. Es muy importante mantener el lenguaje lo ms acotado posible, ya que se
vuelve ms fcil de aprender y usar.
6.5.2.1.1. Fuentes de conceptos
Identificar los conceptos relevantes para el lenguaje depende en gran medida de las ideas
creativas y de la experiencia en el dominio. Se tiene una ventaja si se ha estado
Juan Pablo Marzetti
65

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

involucrado en tareas similares en el pasado. Siempre que sea posible se debe consultar a
personas con ms experiencia en el tema, como lo son los expertos en el dominio,
arquitectos, y lderes de los equipos de desarrollo. Sus opiniones y puntos de vista son la
principal fuente para la creacin de la solucin. Hay que tener en cuenta que la persona
que va a especificar el lenguaje e implementarlo como una herramienta no tiene que
tener necesariamente experiencia en el dominio.
Los conceptos candidatos para el lenguaje de modelado se pueden encontrar en
diferentes contextos. Se los puede hallar en la jerga utilizada, as como en el vocabulario
de uso. Frecuentemente los conceptos usados existen por una buena razn y es que la
gente los encuentra relevantes y concisos cuando discuten por un producto y sus
caractersticas. El vocabulario provee entonces un buen punto de partida, ya que la gente
no piensa en las soluciones en trminos de cdigo. Esto significa tambin que no hay
necesidad de introducir trminos nuevos, que no sean familiares o llamar los conceptos
existentes con otros nombres.
Algunas fuentes tpicas para encontrar conceptos candidatos incluyen:
La arquitectura: una descripcin de la arquitectura es una buena fuente de
informacin ya que aqu se opera con conceptos del dominio. Usualmente es la
parte ms estable y revela abstracciones importantes acerca de los elementos de
la aplicacin y su comportamiento.
Productos existentes: aplicaciones y correspondientes manuales. Estos capturan la
estructura, el comportamiento y la semntica, pero desafortunadamente hacer un
anlisis completo no siempre es prctico.
Patrones: Si la compaa tiene definidos un grupo de patrones, pueden ser una
fuente de conceptos del dominio y revelar estructuras comunes dentro del mismo.
Cdigo: Esto implica examinar las aplicaciones existentes y generalizar las
caractersticas encontradas en ellas. No est limitado solamente a encontrar
abstracciones para el lenguaje. Los conceptos provenientes del look and feel del

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

sistema y los del experto en el dominio tienen un nivel ms alto de abstraccin que
aquellos originados a partir del cdigo, por lo que prevalecen sobre stos.
Es muy importante que durante este proceso se distinga entre la sintaxis concreta del
lenguaje y la sintaxis abstracta. Es muy comn que la estructura de la sintaxis abstracta
refleje su sintaxis concreta. Por ejemplo, consideremos un lenguaje que provee mltiples
vistas superpuestas de un pequeo nmero de conceptos del modelo. En este caso, la
sintaxis abstracta debera modelar solo los conceptos del modelo y no su sintaxis
concreta.
6.5.2.1.2. Casos de uso
Una tcnica til para identificar los conceptos del lenguaje de modelado es considerar
diferentes casos de uso asociados al uso del lenguaje. Esto es muy parecido a escribir una
interfaz para un metamodelo, es decir, una coleccin de operaciones que deberan ser
usadas cuando se interacta con el metamodelo.
6.5.2.2. Modelado de los conceptos
Tan pronto como se hayan identificado las partes relevantes del lenguaje de modelado, se
deben formalizar. La mejor forma de hacerlo es definiendo un metamodelo.
6.5.2.2.1. Reglas de buena formacin
Una vez que se construye un modelo bsico se comienzan a identificar ejemplos de
modelos validos e invlidos que se pueden escribir con el lenguaje creado. Esta
informacin se usa para definir un conjunto de reglas de buena formacin que regulan los
modelos ilegales. Cuando se definen estas reglas se busca identificarlas de la forma ms
general posible y se investiga qu pasa cuando se las combina.
6.5.2.2.2. El lenguaje OCL
Los lenguajes grficos de modelado son ampliamente aceptados en la industria. Sin
embargo su falta de precisin ha originado la necesidad de utilizar otros lenguajes de
especificacin, como por ejemplo OCL (Object Constraint Language), para definir
restricciones adicionales. Con el uso de OCL se ofrece al diseador la posibilidad de crear
Juan Pablo Marzetti
67

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

modelos precisos y completos del sistema en etapas tempranas del desarrollo. Sin
embargo para estimular su uso en la industria es necesario contar con herramientas que
permitan la edicin y evaluacin de las especificaciones expresadas en OCL.
Cualquier modelo puede ser enriquecido mediante informacin adicional o restricciones
sobre los elementos del modelo. Estas restricciones pueden ser escritas en lenguaje
natural, pero en ese caso no es posible chequear su validez de manera automtica y
pueden ser mal interpretadas.
Un diagrama UML, como por ejemplo un diagrama de clases, en general no est lo
suficientemente refinado para proveer todos los aspectos relevantes de una
especificacin. Existe, entre otras cosas, una necesidad de describir restricciones
adicionales sobre objetos del modelo. Esas restricciones son a veces descriptas en
lenguaje natural, pero en la prctica esto resulta siempre en ambigedades. OCL fue
desarrollado para solucionar este problema. Es un lenguaje formal y al mismo tiempo fcil
de leer y escribir. Es un lenguaje puro de especificacin, el cual garantiza estar libre de
efectos laterales. Cuando se evala una expresin OCL simplemente retorna un valor, sin
hacer modificaciones en el modelo. OCL no es un lenguaje de programacin, es decir, no
es posible escribir la lgica de un programa o flujos de control en OCL. No se pueden
invocar procesos o activar operaciones que no sean de consulta con OCL.
Como OCL es un lenguaje con tipos, cada expresin del mismo tiene un tipo definido. Para
que una expresin est bien formada, debe ajustarse a las reglas de operaciones entre
tipos del lenguaje; por ejemplo, no puede compararse un Integer con un String.
OCL permite especificar diferentes tipos de restricciones: Invariantes, Pre y
Postcondiciones. Con estas restricciones se pueden definir reglas de buena formacin para
el modelo.

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

6.5.2.2.2.1. Self
Cada expresin OCL est escrita en el contexto de una instancia de un tipo especfico. En
una expresin OCL la palabra reservada self es usada para referirse a esa instancia, a la
cual se le especifica la restriccin.
6.5.2.2.2.2. Invariantes
Si una expresin OCL es una invariante para un elemento, debe evaluar verdadera para
todas las instancias del elemento en todo momento. Por lo tanto, todas las expresiones
OCL que denotan invariantes son del tipo Boolean.
El elemento del cual predica la expresin OCL, forma parte de la invariante y se escribe
bajo la palabra clave context seguido del nombre del elemento. La etiqueta inv:
declara que la restriccin es una invariante.
Por ejemplo, para la definicin de un metamodelo basado en Ecore se podra pedir que no
pueda especificarse una jerarqua mltiple. En este caso la invariante debe definirse sobre
la meta-metaclase EClass de la siguiente manera:
context EClass inv:
self.eSuperTypes <= 1

En general, la sintaxis de una invariante es:

context [VariableName:] TypeName inv:
< OclExpression >

6.5.2.2.2.3. Pre y Postcondiciones
Una pre o postcondicin debe estar ligada a una operacin o mtodo. Se muestra
agregando pre o post en la declaracin segn corresponda. En este caso, la instancia
contextual self se refiere al elemento al que pertenece la operacin. En el caso de ser una
precondicin, la restriccin establece una condicin que debe cumplirse antes de ejecutar
la operacin. En el caso de ser una postcondicin, la restriccin establece una condicin
que debe cumplirse despus de ejecutar la operacin.
En general, la sintaxis para definir pre y postcondiciones es la siguiente:
Juan Pablo Marzetti
69

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

context Typename::operationName(param1 : Type1, ... ):
ReturnType
pre : param1 > ...
post: result = ...
La variable param1 se refiere a los parmetros de la operacin para la cual se define la
restriccin. La variable result se refiere al valor de retorno de la operacin.
Si una expresin OCL es definida como invariante, la restriccin debe cumplirse en todo
momento, en cambio en las precondiciones y postcondiciones debe cumplirse antes y
despus de ejecutar la operacin, segn sea el caso.
6.5.2.2.3. Reglas de buena formacin a nivel modelo
Como se ha visto, una invariante es una expresin OCL que debe ser verdadera para todas
las instancias del elemento del cual predica, en cualquier momento. Es posible especificar
invariantes a nivel modelo. Estas restricciones aseguran que los objetos a ser instanciados
cumplen determinadas propiedades. Estas restricciones predican entonces sobre los
elementos del modelo. Por ejemplo, en el contexto de un sistema de envo de newsletters
por correo electrnico, una regla de buena formacin sera la siguiente.
context Destinatario
inv: self.email.contains('@')

Esta invariante debe cumplirse para cada uno de los destinatarios concretos, es decir, para
cada una de las instancias de la clase Destinatario. Esta invariante chequea que los emails
de los mismos contengan el carcter @.
6.5.2.2.4. Operaciones y Consultas
Las operaciones y las consultas deben ser definidas apropiadamente. Un ejemplo de
operacin es la creacin de nuevos elementos del modelo, la asignacin de los valores
iniciales de los atributos, etc. Un ejemplo de consulta es verificar el estado de alguna
propiedad, para usar ese valor como entrada a una restriccin u operacin, o con
propsitos de validacin.

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

6.5.2.3. Validacin y Verificacin
Es de vital importancia verificar la validez del modelo de sintaxis abstracta. Una tcnica
til es construir instancias de la sintaxis abstracta que soporten los modelos dados por los
ejemplos. Un diagrama de objetos es una manera til de capturar esta informacin ya que
muestra objetos (instancias de clases) y enlaces (instancias de asociaciones). Existen
herramientas disponibles que ayudan a hacer diagramas de objetos y que tambin
verifican si son validos con respecto al modelo y a cualquier restriccin OCL que haya sido
definida.
6.6. Sintaxis Concreta
La sintaxis abstracta describe el vocabulario y la gramtica del lenguaje, pero no define
como se mostrara ese lenguaje al usuario. Estas vistas son descriptas por la sintaxis
concreta, y pueden ser en forma de diagrama o en forma de texto.
Muchos de los lenguajes de modelado usan sintaxis concreta en forma de diagramas,
como las maquinas de estado o los diagramas de clases; aunque frecuentemente se ven
limitados por el tamao del diagrama. Por otro lado, existen algunos lenguajes que tienen
slo una sintaxis textual. Ejemplo de esto ltimo es el lenguaje OCL.
El proceso de definir la sintaxis concreta tiene dos pasos: el primero es interpretar la
sintaxis y asegurar que sea vlida. El segundo es usar la sintaxis concreta para instanciar la
sintaxis abstracta. Estos pasos son igualmente aplicables si la sintaxis es en forma de texto
o de diagrama, aunque existe una diferencia importante en la manera en que las sintaxis
concretas se construyen por el usuario final. Los diagramas se crean comnmente en
forma interactiva e incremental y, como consecuencia, la sintaxis debe ser interpretada en
paralelo con la interaccin del usuario. Por otro lado, la sintaxis textual es frecuentemente
interpretada de manera serial. El usuario construye un modelo completo usando la
sintaxis, y luego este es pasado al intrprete. Este estilo es comparable a los compiladores
e intrpretes de los lenguajes de programacin.
Juan Pablo Marzetti
71

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

De la misma manera que la sintaxis abstracta juega un rol central en la descripcin del
lenguaje, la sintaxis concreta es crucial para el diseo. Adems se puede definir como un
elemento separado en la descripcin del lenguaje.
El rol de la sintaxis concreta es representar un programa a los sentidos del usuario.
Usualmente se hace por medio de una herramienta, siendo la ms importante de ellas el
editor, el cual se utiliza para crear o cambiar el modelo. El tipo de editor usado influye en
el modo en que se piensa en la sintaxis concreta y su relacin con la sintaxis abstracta.
Tambin hay que considerar si el lenguaje definido es textual o grafico.
6.6.1. Modelado de la sintaxis concreta
La descripcin de la sintaxis concreta debe incluir un alfabeto de smbolos junto con las
reglas que indican como transformar esos elementos en un grafo de sintaxis abstracta. La
descripcin completa de esta sintaxis debe definir:
Un alfabeto que provea los smbolos bsicos
Reglas de escaneo y anlisis, las cuales establecen la forma de combinar esos
smbolos para construir estructuras sintcticas.
Reglas de abstraccin que indican que elementos de la forma concreta tienen su
contraparte en la forma abstracta.
Reglas de enlace que establecen como juntar o separar elementos de la sintaxis
concreta, que representen los mismos o distintos elementos de la sintaxis
abstracta.
Por ltimo se podran incluir reglas de verificacin, pero es mejor hacerlo en la descripcin
de la sintaxis abstracta. Esto permite que el editor que se implemente sea menos
restrictivo.
Por ejemplo, la sintaxis concreta de una asociacin de un diagrama UML est compuesta
por una lnea solida, los nombres de los roles y sus cordialidades, la navegabilidad, etc.
Esto se corresponde con lo dicho en el primer tem de la lista previa. Dentro del conjunto
de reglas de escaneo y anlisis, se podra especificar en qu casos el fin de lnea y sus

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

adornos se consideran juntos. Esto se podra hacer definiendo una distancia mxima entre
ellos. Para el caso de reglas de abstraccin, se podra especificar el clasificador abstracto
que se asigna a una figura (el clasificador Class para los rectngulos del diagrama de clases
de UML). Por ltimo, una regla de enlace podra decir que, si dos elementos pertenecen al
mismo paquete y tienen el mismo nombre, hacen referencia al mismo objeto en la sintaxis
abstracta. Otra regla de este tipo podra decir que, si el tipo de un atributo tiene el mismo
nombre que una clase existente, se hace referencia a esta.
6.6.2. Fases en el proceso de reconocimiento
La manera en que se deriva la forma abstracta desde su representacin concreta, es un
proceso de reconocimiento. Se debe identificar qu partes de la forma concreta
representan cules elementos de la forma abstracta. Este proceso se define en forma
gradual. No hay un punto preciso donde la representacin concreta se convierte en la
forma abstracta. De todas maneras, el resultado final de este proceso ser lo que se
conoce como la forma abstracta del programa. A continuacin se presenta las distintas
fases del proceso.
6.6.2.1. Anlisis lxico y sintctico
Las siguientes fases en un compilador son las de anlisis lxico o scanning y anlisis
sintctico o parsing. En la primera un grupo de caracteres son combinados para formar
palabras. En la segunda, estas palabras se combinan para obtener un rbol de anlisis.
Estas fases son muy similares y, aunque haya tcnicas que las implementen de formas
diferentes, el hecho de que el anlisis sintctico se haga luego de hacer el lxico lo
simplifica. Ejemplos de generadores de analizadores lxicos y sintcticos para lenguajes
textuales son Yacc y Lex, Bison, Antlr y javaCC.
Mientras que en el caso textual el resultado es un rbol de anlisis, en el cado de los
lenguajes grficos el resultado debera ser un grafo de anlisis. La mayora de los nodos en
este grafo son smbolos con posicin, mientras otros representan conceptos ms
complejos. Todos los nodos se encuentran conectados segn su posicin o su grupo
sintctico.
Juan Pablo Marzetti
73

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

6.6.2.2. Anlisis semntico - Abstraccin
Los rboles de anlisis incluyen nodos que representan elementos puramente sintcticos.
En lenguajes textuales lo son palabras claves y caracteres especiales, como por ejemplo
los corchetes. En los lenguajes grficos, lo son las flechas y rectngulos, que estn
presentes en el grafo de anlisis. La primera accin de la fase de anlisis es abstraerse de
estos elementos puramente sintcticos para formar el rbol de sintaxis abstracta para el
caso de lenguajes textuales o rbol de sintaxis abstracta para los grficos. Esta fase junto
con el enlace y verificacin se conoce como anlisis de semntica esttica.
6.6.2.3. Anlisis semntico - Enlace
El rbol de sintaxis abstracto no es an el resultado requerido por procesamientos futuros
tales como generacin de cdigo o transformacin de modelos. Este rbol puede contener
aun elementos sin ligar los cuales representen una referencia a otro elemento en el rbol
que no est conectado. Estas referencias podran apuntar a partes que podran no existir
por un error del usuario o a una especificacin incompleta.
9.6.2.4. Anlisis semntico - Verificacin esttica
Finalmente algunas verificaciones son realizadas en el rbol de sintaxis abstracta. La ms
conocida es la verificacin de tipos, la cual se puede realizar cuando todas las variables
estn ligadas. Otra verificacin que se debe realizar en esta fase es el anlisis de control de
flujo para reconocer cdigo inalcanzable. Aunque ambos ejemplos se pueden encontrar
en lenguajes textuales, no significa que en los lenguajes grficos no se realicen
verificaciones similares. Por ejemplo, de acuerdo a la especificacin de UML la flecha
implements debe ir solamente desde una clase a una interface. La mayora de las
herramientas UML no permiten a los usuarios dibujar esa flecha en otro caso. Pero,
cuando el diagrama es importado desde otra fuente, es necesario realizar el chequeo.
6.7. Semntica
El propsito de este apartado es describir como se puede usar el metamodelado para
describir la semntica de los lenguajes de modelado o los de programacin. La semntica

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

de un lenguaje de modelado describe el significado del mismo en trminos de su
comportamiento, sus propiedades estticas o su traduccin a otro lenguaje.
6.7.1. Definicin
La semntica de un lenguaje describe el significado de los conceptos del mismo. La
semntica del lenguaje describe qu sucede en una computadora cuando una instancia
del mismo es ejecutada. Es por eso que cuando se utiliza un lenguaje, es necesario asignar
un significado a sus conceptos para lograr entender cmo usarlo. Por ejemplo, en el
contexto de un lenguaje de modelado, la definicin de lo que es una maquina de estados
o una clase, es una parte clave al modelar un aspecto especfico en cierto dominio.
Existen varias maneras de describir el significado de un concepto de lenguaje. Por
ejemplo, se pueden definir en trminos de otros conceptos a los cuales se les dio un
significado previamente, describiendo sus propiedades y comportamiento o
especializando otro concepto existente. De la misma manera se podra hacer describiendo
las propiedades que comparten todas las posibles instancias del concepto, o indicando
una relacin entre los conceptos de un lenguaje con pensamientos y experiencias de
conceptos del mundo real.
6.7.2. Objetivo
Una semntica es esencial para comunicar el significado de los modelos o programas,
entre los miembros del equipo de desarrollo de un sistema. La semntica tiene un rol
central ya que define las capacidades del lenguaje como su ejecucin, anlisis y
transformacin. Por ejemplo, un lenguaje que soporta comportamiento como las
maquinas de estado, requiere una semntica para describir cmo se van a ejecutar los
programas o modelos escritos en el mismo.
Tradicionalmente la semntica de muchos lenguajes de modelado era escrita de manera
informal, algunas veces con lenguaje natural, y otras con ejemplos. Por ejemplo, gran
parte de la especificacin de UML, en las versiones 1.x, utiliza el lenguaje natural para las
descripciones semnticas.
Juan Pablo Marzetti
75

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

Una semntica informal trae consigo varios de los siguientes problemas:
Debido a que los usuarios tienen que asignar un significado informal o intuitivo a
los modelos, hay un riesgo importante de mala interpretacin y, por consiguiente,
puede llevar a que los usuarios hagan un mal uso del lenguaje.
Una semntica informal no puede ser interpretada o entendida por las
herramientas. Los desarrolladores de herramientas deben implementar entonces
su propia interpretacin de la semntica. Desafortunadamente, esto significa que
el mismo lenguaje puede ser implementado de diferentes maneras. De esta forma,
dos herramientas distintas pueden ofrecer implementaciones contradictorias de la
misma semntica. Por ejemplo, la misma mquina de estados puede ejecutar de
manera diferente segn la herramienta que se est utilizando.
Una semntica informal hace ms complicada la tarea de definir lenguajes nuevos.
Dificulta identificar reas en las cuales los conceptos son semnticamente
equivalentes, o donde hay contradicciones. Adems hace ms complicado
extender un lenguaje existente.
6.7.3. Semntica y metamodelos
Mientras est claro que la semntica es una parte crucial en la definicin de un lenguaje,
no queda muy en claro como se la debe describir. Una propuesta es expresar la semntica
en trminos de un lenguaje matemtico formal. En este sentido, existen muchas
publicaciones describiendo la semntica de lenguajes de modelado. Pero la complejidad
de estas descripciones matemticas resulta difcil de entender y tienen un uso prctico
limitado. Una segunda propuesta es expresarla en trminos de un lenguaje de
programacin externo. Esta es una propuesta mucho mas practica, pero aun as el
resultado es especfico a un lenguaje de programacin, lo que compromete la
caracterstica de independencia de plataforma. Y ms aun, el hecho que se describa en un
lenguaje de programacin, hace que el proceso de definicin no sea intuitivo.
Una estrategia alternativa es describir la semntica usando metamodelos, lo cual brinda
algunos beneficios importantes. Primero, la semntica del lenguaje est completamente

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

integrada a la definicin del mismo. Esto significa que est incluida dentro de los otros
elementos del lenguaje, como la sintaxis concreta, relaciones, sintaxis abstracta, etc.
Segundo, como se usa el mismo lenguaje de metamodelado para las definiciones de todos
los lenguajes, las definiciones semnticas se convierten en aserciones reusables que
pueden ser integradas y extendidas con relativa facilidad. Finalmente y lo ms importante
es que las definiciones semnticas son independientes de plataforma, se pueden
intercambiar y, si son entendidas por la herramienta que las importa, las puede usar para
conducir la forma en que esta interacta con el lenguaje. Por ejemplo, una semntica que
describe como se ejecuta una maquina de estados puede ser usada para guiar
simuladores a travs de un conjunto de herramientas.
Es importante notar que un metamodelo de la semntica es bastante diferente del
modelo de sintaxis abstracta de un lenguaje, el cual define la estructura del mismo. Sin
embargo, un modelo de sintaxis abstracta es prerrequisito para la definicin de la
semntica, ya que la semntica agrega una capa al significado de los conceptos definidos
por la sintaxis abstracta.
6.7.4. Propuestas para la definicin de gramticas
Existen varias propuestas diferentes para describir la semntica de un lenguaje en un
metamodelo. En esta seccin se examinan las propuestas ms importantes y se enumeran
ejemplos de su aplicacin. Todas estas propuestas fueron motivadas por otras para definir
la semntica que han sido ampliamente aplicadas en los dominios de los lenguajes de
programacin. La diferencia principal es que se usan metamodelos para expresar las
definiciones semnticas.
6.7.4.1. Semntica definida por traduccin
La semntica definida por traduccin se basa en dos nociones:
La semntica de un lenguaje se define cuando se traduce el lenguaje en otra
forma, llamado lenguaje destino.
El lenguaje destino puede ser definido por un pequeo nmero de construcciones
primitivas que tienen una semntica bien definida.
Juan Pablo Marzetti
77

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

La intencin de esta propuesta por traduccin es definir el significado de un lenguaje en
trminos de conceptos primitivos que si tienen su propia semntica bien definida.
Comnmente esos conceptos primitivos tienen una semntica operacional.
La ventaja de esta propuesta es que si existe una maquinaria que ejecute el lenguaje
destino, es posible obtener una semntica ejecutable para el lenguaje va la traduccin.
Esta propuesta est muy relacionada al rol jugado por un compilador cuando implementa
un lenguaje de programacin ms rico en trminos de primitivas ejecutables.
La principal desventaja de esta propuesta es que la informacin se pierde durante el
proceso de transformacin. Cuando el resultado es una coleccin de primitivas, no resulta
obvio como estaban relacionadas con los conceptos originales.
6.7.4.2. Semntica operacional
Una semntica operacional describe cmo se pueden ejecutar los modelos o los
programas escritos en un lenguaje. Esto involucra la construccin de un intrprete. Por
ejemplo, una sentencia de asignacin V:=E se puede describir por un intrprete que
ejecuta los pasos que implica evaluar la expresin E y luego cargar el valor en la variable V.
La ventaja de una semntica operacional es que puede ser expresada en trminos de
operaciones sobre el lenguaje mismo. En contraste con la semntica definida por
traduccin que se define en trminos de otro lenguaje, posiblemente distinto. Como
resultado, una semntica operacional puede ser fcil de entender y escribir.
6.7.4.3. Semntica extensional
En la propuesta extensional, la semntica de un lenguaje se define como una extensin de
otro lenguaje. Los conceptos de modelado del nuevo lenguaje heredan la semntica de los
conceptos en el otro lenguaje. Adems, pueden extender la semntica, por ejemplo
agregando nuevas capacidades. Las ventajas de esta propuesta es que los conceptos
semnticos complejos pueden ser reusados con un mnimo esfuerzo. Por ejemplo, una
entidad de negocios no necesita definir qu significa crear nuevas instancias, ya que
puede heredarlo de Class.

L
e
n
g
u
a
j
e
s

E
s
p
e
c
f
i
c
o
s

d
e

D
o
m
i
n
i
o

La propuesta extensional tiene algunos puntos en comn con la nocin de perfil de UML.
Un perfil provee una coleccin de estereotipos que pueden ser vistos como subclases de
los elementos de UML o de MOF. Sin embargo, usando la extensin en el nivel de
metamodelado, se provee un mayor poder expresivo, ya que puede arbitrariamente
agregar extensiones semnticas a los nuevos conceptos. Una herramienta podra hacer
uso de esta informacin para permitir una implementacin rpida de un nuevo lenguaje
de modelado, ya que podra reconocer que ha ocurrido una extensin y usar los
estereotipos para adaptar los smbolos del lenguaje de modelado original para soportar el
nuevo lenguaje.
6.7.4.4. Semntica denotacional
El propsito de la semntica denotacional es asociar objetos matemticos, como
nmeros, tuplas, o funciones con cada concepto del lenguaje. El concepto se dice que
denota el objeto matemtico, y el objeto se llama denotacin del concepto. Los objetos
asociados con el concepto se llaman el dominio semntico del concepto.
Una semntica denotacional puede ser pensada como una semntica por ejemplos.
Proveyendo todos los posibles ejemplos de los significados de los conceptos es posible
definir de manera precisa que significan. Para describir la semntica de un Integer, se
necesita el conjunto de todos los nmeros positivos, es decir, la denotacin de Integer es
0..infinito. Las descripciones denotacionales de la semntica tienden a ser estticas, es
decir, enumeran las instancias validas de los conceptos de una manera no ejecutable.
Juan Pablo Marzetti
79

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

7. Entorno de desarrollo Eclipse
Eclipse es un entorno de desarrollo integrado, de cdigo abierto y multiplataforma para
desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecidas", opuesto a las
aplicaciones "Cliente-liviano" basadas en navegadores. Esta plataforma, tpicamente ha
sido usada para desarrollar entornos de desarrollo integrados (IDE por sus siglas en
ingls), como el IDE de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ)
que se entrega como parte de Eclipse (y que son usados tambin para desarrollar el
mismo Eclipse).
Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de
herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundacin Eclipse, una
organizacin independiente sin fin de lucro que fomenta una comunidad de cdigo
abierto y un conjunto de productos complementarios, capacidades y servicios.
7.1. Arquitectura
La base para Eclipse es la Plataforma de cliente enriquecido (Rich Client Platform RCP). Los
siguientes componentes constituyen RCP:
Plataforma principal - inicio de Eclipse, ejecucin de plug-ins
OSGi - una plataforma para empaquetamiento estndar.
El Standard Widget Toolkit (SWT). Un kit de componentes visuales portable.
JFace - manejo de archivos, manejo de texto, editores de texto
El Workbench de Eclipse - vistas, editores, perspectivas, asistentes.
Los widgets de Eclipse estn implementados por una herramienta de widget para Java
llamada SWT, a diferencia de la mayora de las aplicaciones Java, que usan las opciones
estndar Abstract Window Toolkit (AWT) o Swing. La interfaz de usuario de Eclipse
tambin tiene una capa GUI intermedia llamada JFace, la cual simplifica la construccin de
aplicaciones basada en SWT.


E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

Figura 10. Arquitectura de la plataforma Eclipse
El entorno de desarrollo integrado (IDE) de Eclipse emplea mdulos (en ingls plug-in)
para proporcionar toda su funcionalidad al frente de RCP, a diferencia de otros entornos
monolticos donde las funcionalidades estn todas incluidas, las necesite el usuario o no.
Este mecanismo de mdulos permite tener una plataforma ligera para componentes de
software. Adicionalmente le permite a Eclipse extenderse usando otros lenguajes de
programacin como son C/C++ y Python. No slo se puede extender el IDE para lenguajes
de programacin, tambin Eclipse trabaja con lenguajes para procesado de texto
como LaTeX, aplicaciones en red como Telnet y Sistema de gestin de base de datos. La
arquitectura de plug-ins permite escribir cualquier extensin deseada en el ambiente,
como sera Gestin de la configuracin, administracin de servidores de aplicacin, etc.
La definicin que da el proyecto Eclipse acerca de su software es: "una especie de
herramienta universal - un IDE abierto y extensible para todo y nada en particular".
En cuanto a las aplicaciones clientes, Eclipse provee al programador con frameworks muy
ricos para el desarrollo de aplicaciones grficas, definicin y manipulacin de modelos de
Juan Pablo Marzetti
81

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

software, aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing Framework -
Framework para la edicin grfica) es un plug-in de Eclipse para el desarrollo de editores
visuales que pueden ir desde procesadores de texto WYSIWYG hasta editores de
diagramas UML, interfaces grficas para el usuario (GUI), etc.
7.1.1. Arquitectura del ncleo y Plug-ins
Un plug-in es la unidad ms pequea de funcionalidad para la plataforma Eclipse. Puede
desarrollarse y distribuirse de manera separada e independiente del entorno. Mientras
que herramientas pequeas son desarrolladas y distribuidas como un plug-in simple, las
complejas se dividen en varios plug-ins y se distribuyen por separado. Con excepcin de
un ncleo pequeo llamado Platform Runtime, toda la funcionalidad de Eclipse son plug-
ins.
Estos complementos son desarrollados en Java y consisten en una librera JAR que
contiene las clases Java compiladas, algunos archivos de slo lectura, recursos como
imgenes, plantillas web, catlogos de mensajes internacionalizables, etc. Algunos plug-
ins no contienen cdigo ejecutable como es el caso de aquellos que contienen las pginas
de ayuda de alguna herramienta instalada en eclipse. Existe tambin un mecanismo que
permite que un plug-in sea sintetizado a partir de varios fragmentos, cada uno en su
propio directorio o archivo JAR. Este es el mecanismo que se utiliza para distribuir
complementos con diferentes paquetes de idiomas.
Cada complemento tiene un archivo manifest que declara las interconexiones del mismo
con otros plug-ins. El modelo de interconexin consiste en declarar un nmero de plug-ins
de los que depende y un nmero de puntos de extensin que son los puntos de acceso a
la plataforma. Un punto de extensin permite a un plug-in declarar de qu manera ste
aporta al entorno: puede agregar mens contextuales, ayuda, pginas de preferencias,
compiladores, asistentes, editores, etc.
Al iniciar, el Platform Runtime explora y organiza el conjunto de plug-ins disponible, lee su
archivo manifest y construye un registro en memoria. Un plug-in es activado slo cuando

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

su cdigo necesita ser ejecutado permitiendo al IDE una carga inicial rpida y no
congestionar la memoria con grandes cantidades de informacin que no se utiliza.
7.2. Eclipse Modeling Framework (EMF)
El proyecto EMF consiste en un framework de modelado y generacin de cdigo para
construir herramientas y otras aplicaciones basadas en un modelo de datos estructurado.
EMF utiliza XMI como forma cannica para definir modelos. Existen diversas maneras de
obtener un documento XMI:
Crearlo directamente utilizando un editor XML o de texto.
Exportar un modelo de una herramienta de modelado como Rational Rose.
Anotar interfaces Java con propiedades de modelado.
Utilizar esquemas XML para describir la forma en que se serializa un modelo.
Con el archivo que representa el modelo puede generarse un archivo genmodel (una
versin aumentada del modelo con especificaciones para la generacin de cdigo) que a
su vez puede utilizarse para generar el cdigo Java que describe e implementa nuestro
modelo.
Es posible adems crear un editor en lnea de comandos y otro grfico a partir de este
archivo genmodel como plug-ins de eclipse sin tener que escribir una sola lnea de cdigo.
Todo esto nos permite leer, modificar y guardar archivos que representan instancias de
nuestro modelo en formato XMI.
EMF consiste en tres piezas fundamentales que veremos a continuacin.
7.2.1. Ncleo EMF
Incluye un metamodelo (Ecore) para describir modelos y suporte en tiempo de ejecucin
para persistencia, notificacin de cambios y una API relfectiva para manipular objetos EMF
de forma genrica.
Juan Pablo Marzetti
83

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

7.2.1.1. Metamodelo Ecore
Ecore es el modelo utilizado para representar los modelos en EMF. Ecore es en s mismo
un modelo EMF por lo que es su propio metamodelo. Ecore permite modelar un conjunto
simplificado de UML ya que se focaliza en el modelado de clases (aspecto esttico de
UML.
MOF es comparable con Ecore aunque en el diseo de Ecore se eliminaron algunas de las
caractersticas complejas de MOF. Ecore tiene muchas similitudes con MOF como la
capacidad de especificar clases y sus caractersticas estructurales y de comportamiento,
herencia, paquetes y reflexin. Difieren en el rea del ciclo de vida del modelo, las
estructuras de tipos de datos, relaciones entre paquetes y los aspectos complejos de las
asociaciones.
A continuacin se presenta un diagrama del metamodelo Ecore. Las clases sombreadas
corresponden a clases abstractas.

Figura 11. Modelo completo de Ecore.

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

7.2.2. Framework EMF.Edit
El framework EMF.Edit incluye clases genricas y reutilizables para construir editores de
modelos EMF. Provee:
Clases de proveedores de contenido y etiquetas, soporte para edicin de
propiedades y otras clases que permiten que los modelos EMF puedan ser
mostrados utilizando los visores y editores estndar de JFace.
Un framework de comandos y un conjunto genrico de clases de implementacin
para construir editores que soportan las acciones deshacer y rehacer.
7.2.3. Generacin de Cdigo EMF-Codegen
Este mdulo de generacin de cdigo es capaz de generar todo lo necesario para construir
un editor completo para un modelo EMF. Incluye un formulario GUI donde se pueden
especificar opciones de generacin y los generadores a invocar aprovechando los
beneficios y servicios aportados por el JDT (Java Development Tooling) de eclipse.
Se soportan tres niveles de generacin de cdigo:
Modelo: provee interfaces Java y clases de implementacin para todas las clases
del modelo junto con una clase de implementacin Factory y otra Package
Adaptadores: Genera clases de implementacin (llamadas ItemProviders) que
adaptan las clases del modelo a un formato entendible por los editores y
visualizadores.
Editor: produce un editor estructurado que conforma con el estilo recomendado
para los editores de modelos EMF y sirve como punto de partida para empezar a
personalizarlo.
Todos los generadores soportan regeneracin de cdigo mientras preservan las
modificaciones del usuario.
7.3. Xtext
Xtext es un framework para el desarrollo de lenguajes especficos de dominio y otros
lenguajes de programacin textuales. Est ntegramente integrado con Eclipse Modeling
Juan Pablo Marzetti
85

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

Framework y aprovecha todos los servicios del Eclipse Platform para proveer un entorno
integrado de desarrollo.
En contraste con los generadores de analizadores como (JavaCC o ANTLR) Xtext ofrece
mucho ms que un parser y un analizador lxico a partir de una gramtica de entrada. El
lenguaje de la gramtica (la entrada de informacin para Xtext) se utiliza para generar:
Un parser y analizador lxico incremental basado en ANTLR 3 para leer un modelo
a partir del texto de entrada.
Modelos Ecore
Un clase para serializar un modelo generando nuevamente el texto.
Un enlazador para establecer referencias cruzadas entre los elementos del
modelo.
Una implementacin de la interfaz de recursos EMF que permite cargar y guardar
modelos EMF.
Una integracin del nuevo lenguaje al entorno Eclipse:
o Coloreado de sintaxis
o Navegacin del modelo
o Completado de cdigo
o Vista Outline
o Plantillas de cdigo
El objetivo principal de Xtext es soportar el desarrollo de lenguajes especficos de dominio
de manera rpida e iterativa pero puede ser utilizado para implementar entornos de
desarrollo de lenguajes de propsito general.
7.3.1. Uso de Xtext
Para comenzar a trabajar con Xtext se crea un nuevo proyecto dentro de eclipse
seleccionando del men: File New Project... Xtext Xtext project
Se selecciona un nombre significativo para el nuevo lenguaje y una extensin para los
archivos fuentes del lenguaje. El asistente tambin puede crear un proyecto de

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

generacin de cdigo de ejemplo que tomar un modelo instanciado a partir de un cdigo
fuente del lenguaje generado y generar cdigo segn una plantilla XPand.

Figura 12. Creacin de un nuevo proyecto Xtext.

7.3.2. Estructura del proyecto
Si observamos la Figura 19, en el explorador de paquetes puede verse tres proyectos que
corresponden con diferentes complementos del nuevo lenguaje. El proyecto
ar.edu.um.umgenesis es donde se define la gramtica y se configuran los aspectos
de tiempo de ejecucin del lenguaje. El editor, la vista outline y el completado de cdigo
se ubican en el proyecto ar.edu.um.umgenesis.ui. Ambos proyectos consisten en
clases generadas derivadas de la gramtica definida y cdigo manual tal como la
gramtica en s misma o clases personalizadas que extienden la funcionalidad de las cases
generadas por Xtext.
Para mantener el cdigo generado separado del cdigo introducido manualmente o
manipulado por el desarrollador ambos proyectos tienen una estructura bien definida.
Todo el cdigo generado se incluye dentro de las carpetas src-gen y el cdigo manual
Juan Pablo Marzetti
87

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

se ubica en src. Los cambios manuales que se introduzcan en src-gen sern
sobrescritos por el generador.
Un tercer proyecto ar.edu.um.umgenesis.generator contiene un generador de
cdigo que utiliza el modelo creado con el editor DSL para generar cdigo segn una
plantilla.
7.3.3. Gramtica
El asistente crea automticamente una gramtica de ejemplo llamada
Entities.xtext. Una gramtica tiene dos propsitos: se utiliza para describir la
sintaxis concreta del lenguaje y contiene informacin acerca de la manera en que el
analizador crear un modelo durante la etapa de anlisis. Describe adems la estructura
del rbol de sintaxis abstracta (AST). Usualmente cada regla gramatical se corresponder
con un nodo del rbol.
El formato de la gramtica est definido por unos encabezados y reglas gramaticales. La
primera regla definida ser el nodo raz del AST. Cada regla gramatical termina con punto
y coma y las reglas son descritas utilizando expresiones de la forma Backus Naur
Extendida.
grammar org.xtext.example.MyDsl with
org.eclipse.xtext.common.Terminals

generate myDsl "http://www.xtext.org/example/MyDsl"

Model :
(imports+=Import)*
(elements+=Type)*;

Import :
'import' importURI=STRING;

Type:
SimpleType | Entity;

SimpleType:
'type' name=ID;

Entity :
'entity' name=ID ('extends' extends=[Entity])? '{'

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

properties+=Property*
'}';

Property:
'property' name=ID ':' type=[Type] (many?='[]')?;

7.3.3.1. Declaracin del Lenguaje
La primera lnea de la gramtica declara el nombre de la misma. Xtext utiliza el mecanismo
del classpath de Java lo que significa que cualquier nombre completo vlido de Java es
vlido aqu. Este nombre debe corresponder con el nombre y la ubicacin del archivo cuya
extensin ser xtext. La primera lnea adems puede utilizarse para definir un segundo
lenguaje utilizado en la definicin de este a travs de la palabra clave with
7.3.3.2. Definicin de EPackage
Los analizadores creados con Xtext instancian modelos Ecore (metamodelos). Estos
metamodelos consisten en EPackage, EClass, EDataType y EEnum. Xtext puede inferir un
metamodelo Ecore desde la gramtica o tambin puede instanciar metamodelos
existentes. Puede adems, usarse mltiples metamodelos existentes y crear uno nuevo.
Para inferir un modelo se utiliza la palabra clave generate seguida del nombre del
paquete y del URI de espacio de nombres para el metamodelo. Para importar
metamodelos existentes se utiliza la palabra clave import seguida del URI de espacio de
nombres del metamodelo. Puede verse una descripcin completa de cmo se realiza la
inferencia de metamodelos en Ecore model inference
7.3.3.3. Reglas Terminales
Las reglas terminales son la unidad lxica bsica y ms pequea. El analizador lxico toma
como entrada una secuencia de caracteres y produce como salida tokens que se
corresponden con las diferentes reglas terminales. Convencionalmente estas reglas se
nombran en maysculas.
Juan Pablo Marzetti
89

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

En el ejemplo precedente no se han definido reglas terminales porque se utilizan aquellos
que provienen de la gramtica importada: org.eclipse.xtext.common.Terminals. Si nos
vamos a la definicin de ID podemos ver que es como sigue:
terminal ID:
('^')?('a'..'z'|'A'..'Z'|'_') ('a'..'z'|'A'..'Z'|'_'|'0'..'9')*;

Podemos ver que se trata de una definicin basada en expresiones regulares identificada
con la palabra clave terminal.
El orden en que se definan las reglas terminales es importante ya que el analizador sigue
este orden y si una regla engloba a otra y aparece primero, est siempre ser seleccionada
en lugar de la segunda.
Una regla terminal devuelve un valor que ser una cadena de texto (ecore::EString)
a menos que se indique otra cosa. Si se necesita otro tipo de datos, se puede especificar
dentro de la misma definicin. La regla INT hace uso de esta caracterstica:
terminal INT returns ecore::EInt : ('0'..'9')+;

A la hora de ejecutar el analizador, ser necesario que ste sepa cmo convertir la cadena
de entrada en el tipo de datos requerido. Por ello deber escribirse una implementacin
propia de IValueConverterService para este propsito.
7.3.3.4. Reglas de Produccin
El analizador lee una secuencia de tokens y utilizando las reglas de anlisis instancia el
AST. Una regla de anlisis no produce un token sino un rbol de terminales y no
terminales. Existen ciertos elementos que se utilizan en estas reglas para indicar cmo se
construye el AST que se explican a continuacin.
7.3.3.4.1. Asignaciones
Se utilizan para establecer la informacin analizada en una propiedad del objeto actual del
modelo. El tipo del objeto actual es EClass y es especificado por el tipo de retorno. Si no se
especifica ningn tipo Xtext generar una clase en el metamodelo que se llame igual que

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

el nombre de la regla. El tipo de la propiedad es inferido por el valor que est a la derecha
en la asignacin. Por ejemplo:
Import :
'import' importURI=STRING;

En este caso el generador crear una clase Import con una propiedad importURI que
ser de tipo EString (que es el tipo de datos devuelto por el terminal STRING)
Los operadores de asignacin son:
El signo igual simple = cuya funcionalidad es la asignacin simple.
El signo +=. Este operador generar una propiedad que sea de tipo coleccin de
elementos. Estos elementos sern del tipo especificado por el lado derecho de la
asignacin. Se trata de una asignacin acumulativa por lo que el analizador
agregar instancias del valor de la derecha a medida que se cumpla la regla.
El signo ?=. Este operador generar una propiedad de tipo EBoolean que ser
asignada a true slo si se encuentra presente el valor a la derecha de la asignacin.
7.3.3.4.2. Referencias cruzadas
Una de las caractersticas nicas de Xtext es la posibilidad de definir referencias cruzadas
dentro de la misma gramtica. Aunque estas referencias se definen en la gramtica no se
establecen en la fase de anlisis sintctico sino en la fase de enlace. Para definir una
referencia cruzada utilizamos los corchetes como en el ejemplo:
Property:
'property' name=ID ':' type=[Type] (many?='[]')?;

En el atributo type se est indicando al compilador que acepte identificadores que
representen un elemento producido por la regla Type. Este atributo ser entonces del
tipo de datos que devuelve la regla Type. Existe una parte opcional en esta definicin
que permite indicar al analizador cual ser el terminal que deber aceptar como
identificador del elemento referenciado. Si no se indica nada, por defecto ser el terminal
ID. Para ver como se indica lo contrario vemos un ejemplo donde se utilizan
identificadores con una ruta:
Juan Pablo Marzetti
91

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

FQID: ID('.' ID)*;

Property:
'property' name=ID ':' type=[Type|FQID] (many?='[]')?;

En este caso indicamos al compilador que puede referenciar elementos Type a travs de
FQID que son identificadores como los que utiliza java. En este caso se deber realizar una
implementacin especfica de ILinkingService que indique al enlazador qu
referencias establecer a partir de los terminales encontrados.
7.3.3.4.3. Acciones Simples
Por defecto el objeto que una regla de produccin devuelve es creado en la primera
asignacin y determinado por el tipo de retorno especificado o por el nombre de la regla.
Con la acciones estas creaciones de objetos pueden hacerse explcitas y permiten tambin
determinar la jerarqua de clases en el metamodelo. Si en un punto se necesita forzar la
creacin de un tipo especfico se pueden utilizar alternativas o acciones simples. En el
ejemplo que sigue TypeB debe ser un subtipo de TypeA.
Ejemplo con alternativas:
MyRule returns TypeA :
"A" name=ID |
MyOtherRule
;

MyOtherRule returns TypeB :
"B" name = ID
;

Ejemplo con acciones simples:
MyRule returns TypeA :
"A" name=ID |
"B" {TypeB} name=ID
;

Generalmente la instancia se crea tan pronto como el analizador alcanza la primera
asignacin. Sin embargo las acciones permiten instanciar explcitamente cualquier
EObject. La notacin {TypeB} crear una instancia de TypeB y la asignar al
resultado de la regla de produccin.

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

7.3.3.4.4. Reglas sin asignacin
Se ha explicado anteriormente que el objeto a ser devuelto por una regla es instanciado
en la primera asignacin. Pero qu pasa si no ocurre ninguna asignacin? Este es el caso
de estas reglas en las que slo aparecen llamadas a otras reglas. El valor devuelto ser
asignado al valor devuelto por la regla que se llame. Un ejemplo de lo explicado es lo
siguiente:
AbstractToken :
TokenA |
TokenB |
TokenC
;

La regla AbstractToken puede devolver instancias de TokenA, TokenB o TokenC.
Por ello es lgico que cualquier de las tres ltimas reglas sea un subtipo de
AbstractToken. Xtext inferir los atributos que tengan las subclases en comn y se los
asignar a la clase padre.
7.3.3.4.5. Smbolos terminales ocultos
Como las reglas de produccin definen una secuencia de patrones de entrada es necesario
dejar pasar slo las partes que interesan. Xtext introduce el concepto de terminales
ocultos para manejar elementos irrelevantes para la semntica como pueden ser espacios,
comentarios, nuevas lneas, etc.
Los terminales ocultos pueden o no aparecer entre cualquier otro terminal y en cualquier
cardinalidad. Pueden ser especificados para toda la gramtica o por cada regla de
produccin. La gramtica org.eclipse.xtext.common.Terminals viene con un
conjunto razonable de terminales ocultos para toda la gramtica que se defina (excluye espacios
en blanco, comentarios y nuevas lneas)
Para definir los smbolos que una regla esconde podemos observar el siguiente ejemplo:
Person hidden(WS, ML_COMMENT, SL_COMMENT):
name=Fullname age=INT ';'
;

Juan Pablo Marzetti
93

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

7.3.3.5. Reglas de Tipo de Datos
Son reglas que se evalan en la fase de anlisis sintctico que crean instancias de
EDataType en lugar de EClass. Son muy similares a las reglas terminales pero tienen
la ventaja de:
1. Se sensibles al contexto
2. Permiten el uso de terminales ocultos.
Un ejemplo de este tipo de construccin lo vimos antes en la definicin de referencias
cruzadas:
FQID: ID('.' ID)*;

Es preciso notar que si una regla no llama a otras reglas de produccin y no tiene
asignaciones ni acciones, se la considera una regla de tipo de datos y su valor (a menos
que se especifique otra cosa con returns) ser una instancia de un subtipo de
EDataType.
7.4. Framework para generar cdigo
El proyecto de cdigo libre openArchitectureWare fue incluido y fusionado con el Eclipse
Modeling Project. El framework est compuesto por tres lenguajes distintos (Xpand, Check
y Xtend) los cuales se orientan al trabajo sobre metamodelos para transformarlos y
generar, a partir de ellos, cdigo textual.
Cada lenguaje de este framework est construido sobre un lenguaje de expresiones y un
sistema de tipos comunes. Pueden operar sobre los mismos modelos, metamodelos y
meta-metamodelos. El framework de expresiones provee una capa de abstraccin
uniforme sobre diferentes meta-metamodelos como (EMF Ecore, Eclipse UML, JavaBeans,
XML Schema). Ofrece, adems, un poderoso lenguaje de expresiones con tipos estticos
que se utiliza en todos los lenguajes.

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

7.4.1. Sistema de Tipos
Es la capa de abstraccin que provee acceso a los tipos internos y a diferentes
implementaciones de metamodelos.
7.4.1.1. Tipos
Cualquier objeto (elementos de modelo, valores, etc.) tiene un tipo. Estos contienen
propiedades y operaciones y podran heredar de otros tipos (incluso podra haber
herencia mltiple)
7.4.1.1.1. Nombres de los Tipos
Generalmente un tipo tiene un nombre simple como String y un espacio de nombres
opcional para distinguirlo entre dos tipos con el mismo nombre. El delimitador para el
espacio de nombres es ::. Un nombre completamente calificado se ve as:
my::fully::qualified::MetaType

El espacio de nombres y nombre utilizados por un tipo concreto est definido por la
implementacin del metamodelo al que corresponde. La implementacin de Ecore se
llama EmfMetaModel y mapea EPackage un espacio de nombres y EClassifiers
a un nombre.
7.4.1.1.2. Nombres de los Tipos Coleccin
El sistema de tipos interno contiene colecciones: Collection, List y Set. Al ser este
un lenguaje de expresiones con tipos estticos no se permiten casts y por ello se
introduce el concepto de tipos parametrizados. La sintaxis para utilizarlos es:
Collection[my::Type]
List[my::Type]
Set[my::Type]

7.4.1.1.3. Elementos
Cada tipo ofrece diferentes elementos y existen de diversos tipos:
1. Propiedades: tienen un nombre y un tipo. Pueden ser invocadas en instancias del
tipo correspondiente.
Juan Pablo Marzetti
95

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

2. Operaciones: tienen nombre, parmetros y un tipo de valor retornado. Pueden ser
invocadas en instancias del tipo correspondiente.
3. Propiedades estticas: Son equivalentes a enumeraciones o constantes y deben
ser invocadas estticamente.
7.4.1.1.4. Tipos Internos
Object
Define algunas operaciones bsicas como equals(). Todos los tipos deben extender
Object.
Void
El tipo Void puede ser especificado como un tipo de retorno para operaciones.
String
Soporta las operaciones de java.lang.String y algunas especiales como
toFirstUpper, toFirstLower, expresiones regulares, etc.
Boolean
Ofrece los operadores usuales
Integer y Real
Ofrece los operadores usuales y aritmtica simple. Integer extiende Real.
Collection, List y Set
Collection es el tipo base de las colecciones. Los tres tipos tienen las operaciones que
se definen en los homnimos de java.
7.4.1.2. Implementaciones de Metamodelos
Por defecto el sistema de tipos slo conoce los tipos internos. Para registrar metatipos
propios es necesario registrar una implementacin de metamodelos. Dentro de la lista de
implementaciones que encontramos en el EMF estn:
JavaBeans
Metamodelo Ecore
Eclipse UML
XML Schema

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

7.4.2. Lenguaje de Expresiones
El lenguaje de expresiones es una mezcla sintctica de Java y OCL.
Para acceder a una propiedad y a las operaciones se utiliza el punto.
myModelElement.name
myModelElement.doStuff()

Las expresiones aritmticas y booleanas son iguales a las de Java.
Las colecciones tienen una variedad de operaciones que permiten tratarlas:
select: collection.select(v | expresin booleana con v)

Selecciona los elementos para los cuales la expresin devuelve verdadero.
reject: collection.reject(v | expresin booleana con v)

Selecciona los elementos para los cuales la expresin devuelve falso.
typeSelect: collection.typeSelect(nombre de la clase)

Selecciona los elementos cuyo tipo corresponde con el nombre especificado.
collect: collection.collect(v | expresin con v)

Devuelve una coleccin de los resultados de la expresin especificada.
forAll: collection.forAll(v | expresin booleana con v)

Devuelve el resultado de evaluar todas las expresiones relacionadas con el operador AND.
exists: collection.exists(v | expresin booleana con v)

Devuelve el resultado de evaluar todas las expresiones relacionadas con el operador OR.
7.4.3. Xpand
Xpand es un lenguaje diseado para controlar la generacin de salida a travs de
plantillas. Se basa en plantillas textuales que especifican qu y cmo se generar el texto
de salida.
Juan Pablo Marzetti
97

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

Los delimitadores de las plantillas son ( y ) y todo lo que est fuera de ellos se imprime en la
salida directamente. Los archivos de las plantillas utilizan la extensin .xpt.
7.4.3.1. Estructura general de un archivo de plantillas
IMPORT meta::model
EXTENSION my::ExtensionFile

DEFINE javaClass FOR Entity
FILE fileName()
package javaPackage();

public class name {
// implementation
}
ENDFILE
ENDDEFINE

Un archivo de plantillas consiste en un nmero variable de sentencias IMPORT, seguidos
por un nmero variable de sentencias EXTENSION, seguidos por uno o ms bloques
DEFINE.
7.4.3.2. Sentencia IMPORT
IMPORT meta::model

Puede utilizarse esta sentencia para importar un espacio de nombres de un metamodelo
en orden a evitar los nombres completamente calificados en cada sentencia. El ejemplo
anterior es similar a la sentencia java: import meta.model.*.
7.4.3.3. Sentencia EXTENSION
Los metamodelos son tpicamente descritos de una manera estructural. Un problema de
esto es que es difcil especificar comportamientos adicionales (consultas, propiedades
derivadas). Adems es una buena prctica el no ensuciar el modelo con elementos de
informacin que son especficos de la plataforma.
Las extensiones son un mecanismo flexible y conveniente para definir atributos
adicionales en las metaclases. Esto se realiza con el lenguaje Xtend. Para importar un
archivo escrito en dicho lenguaje se utiliza la sentencia EXTENSION.
EXTENSION my::ExtensionFile

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

El archivo debe residir en el classpath de Java. Por ello utilizan el mismo mecanismo de
espacio de nombres y sintaxis que los tipos para acceder al archivo.
7.4.3.4. Sentencia DEFINE
El concepto central de XPand es el bloque DEFINE, tambin denominado plantilla. Es la
unidad ms pequea en un archivo de plantillas. La etiqueta consiste en un nombre, una
lista opcional de parmetros separados por una coma y el nombre de la clase del
metamodelo para la cual se define la plantilla.
DEFINE nombre(Tipo p1, Tipo p2) FOR MetaClass
Secuencia de sentencias
ENDDEFINE

Dentro del cuerpo del bloque existe siempre un parmetro this que hace referencia a la
instancia de la metaclase para la cual se llamo a esta plantilla. El cuerpo de la plantilla
puede incluir cualquier secuencia de sentencias y texto a imprimir.
Las plantillas utilizan un mecanismo completo de polimorfismo paramtrico. Si existen dos
plantillas definidas con el mismo nombre para dos metaclases distintas que heredan de la
misma superclase, XPand utilizar la que corresponda a la instancia para la cual se
expanda la plantilla. Esto no slo es vlido para la metaclase sino tambin para todos los
parmetros.
Teniendo en cuenta el siguiente metamodelo:

Figura 13. Metamodelo de Ejemplo

Juan Pablo Marzetti
99

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

Se asume que existe un modelo que tiene una coleccin almacenada en la propiedad
listOfAs. sta contiene instancias de A, B y C. Se podra escribir la siguiente plantilla:
DEFINE someOtherDefine FOR SomeMetaClass
EXPAND implClass FOREACH listOfAs
ENDDEFINE

DEFINE implClass FOR A
// codigo generado para la superclase A
ENDDEFINE

DEFINE implClass FOR B
// codigo generado para la subclase B
ENDDEFINE

DEFINE implClass FOR C
// codigo generado para la subclase C
ENDDEFINE

Para cada instancia de B en la lista, la plantilla definida para B es ejecutada. Para cada
instancia de C, la plantilla de C es ejecutada. Para el resto (que son instancias de A) la
plantilla por defecto es ejecutada.
7.4.3.5. Sentencia FILE
La sentencia FILE redirecciona la salida generada de las sentencias en su cuerpo al
archivo especificado.
FILE expression [outletName]
ENDFILE

El archivo destino est especificado por la expresin que devuelve su nombre (este
nombre es relativo al directorio especificado como directorio de salida del generador).
Adicionalmente puede especificarse un identificador que determine un OUTLET. Los
outlets son definiciones de directorios especficos para redireccionar la salida y controlar si
los archivos se sobrescriben o no.
7.4.3.6. Sentencia EXPAND
Esta sentencia expande otro block DEFINE e inserta su salida en la ubicacin actual y
contina con la siguiente sentencia. Es un concepto similar a una llamada de subrutina.

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

EXPAND definition [(parameterList)]
[FOR expression | FOREACH expression [SEPARATOR
expression] ]

Si se especifica FOR la definicin es ejecutada para el resultado de la expresin
determinada. Si se especifica FOREACH la expresin debe evaluar a una coleccin y la
definicin es ejecutada para cada elemento de la misma. Si se especifica un separador,
ste se incluir entre cada generacin para cada elemento de la coleccin.
7.4.3.7. Sentencia FOREACH
Esta sentencia expande el cuerpo del bloque para cada elemento de la coleccin
resultante de la expresin. El elemento de cada iteracin se referencia por el nombre de
una variable.
FOREACH expression AS variable [ITERATOR iterador]
[SEPARATOR expression]
Secuencia de sentencias que utilizan variable para acceder
los elementos de la iteracion
ENDFOREACH
7.4.3.8. Sentencia IF
La sentencia IF permite expansiones condicionales. Puede especificarse cualquier
nmero de sentencias ELSEIF. El bloque ELSE es opcional.
IF expression
[ ELSEIF expression ]
Secuencia de sentencias ]
[ ELSE
Secuencia de sentencias ]
ENDIF

7.4.3.9. Sentencia PROTECT
Las regiones protegidas se utilizan para marcar secciones en el cdigo generado que no
deberan ser sobrescritas por subsecuentes ejecuciones del generador. Estas secciones
tpicamente contienen cdigo escrito manualmente.
PROTECT CSTART expression CEND expression ID expression
(DISABLE)?
ENDPROTECT
Juan Pablo Marzetti
101

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

Los valores de las expresiones CSTART y CEND se utilizan para encerrar las regiones
protegidas con marcas en la salida. Deberan construir inicios y finales vlidos de
comentarios.
7.4.3.10. Sentencia LET
Let permite especificar variables locales:
LET expression AS variable
ENDLET
7.5. Xtend
De la misma manera que el lenguaje de expresiones ofrece expresiones para todos los
lenguajes textuales del framework existe otro lenguaje utilizado comnmente llamado
Xtext.
El lenguaje permite definir libreras ricas de operaciones independientes y no invasivas
para el metamodelo. Las mismas pueden basarse tanto en expresiones del lenguaje de
expresiones como en operaciones basadas en mtodos Java.
7.5.1 Archivos de Xtend
Un archivo de Xtend debe residir en el classpath de Java. Adicionalmente la extensin del
archivo debe ser .ext.
import my::metamodel;
extension other::ExtensionFile;

/**
* Documentation
*/
anExpressionExtension(String stringParam) :
doingStuff(with(stringParam))
;

/**
* java extensions are just mappings
*/
String aJavaExtension(String param) : JAVA
my.JavaClass.staticMethod(java.lang.String)
;

E
n
t
o
r
n
o

d
e

d
e
s
a
r
r
o
l
l
o

E
c
l
i
p
s
e

7.5.2 Sentencias Import
A travs de la sentencia import se pueden importar espacios de nombres de diferentes
tipos.
import my::imported::namespace;

7.5.3 Extensiones
La sintaxis de una extensin simple es como la siguiente:
ReturnType extensionName(ParamType1 paramName1,
ParamType2...): expresin que utiliza los parmetros;

Por ejemplo:
String getterName(NamedElement ele):
'get'+ele.name.firstUpper();

El tipo del primer parmetro definido es el elemento al que se asocia la extensin.
Generalmente este parmetro suele llamarse this.
7.5.3 Extensiones JAVA
En algunos casos es necesario utilizar una llamada a un mtodo Java desde una expresin.
Pueden definirse extensiones que conecten con mtodos Java.
Void myJavaExtension(String param) :
JAVA my.Type.staticMethod(java.lang.String);

La implementacin se redirige a un mtodo esttico y pblico en una clase de Java. No se
puede utilizar ningn espacio de nombres importado por lo que el tipo de retorno, el
mtodo y los tipos de parmetros deben especificarse con nombres completamente
calificados.
Juan Pablo Marzetti
103

C
a
s
o

d
e

E
s
t
u
d
i
o

8. Caso de Estudio
En el presente captulo se presenta una aplicacin de los conceptos estudiados de manera
integradora para crear un lenguaje especfico de dominio, su editor, compilador y un
generador de cdigo a partir del mismo.
El lenguaje sobre el que se trabaj ha sido inventado sobre la base de las necesidades que
he tenido en mi experiencia laboral, las cuales se manifiestan en el apartado 2.3
Motivacin. En miras al mbito del presente trabajo y a las restricciones que el desarrollo
del mismo presentaba se ha desarrollado un generador de cdigo para una plataforma
especfica. No obstante ello, la estructura del mismo ha sido diseada para permitir
extensiones y la creacin de generadores para diversas plataformas de una manera
sencilla y de fcil integracin.
8.1. Introduccin al lenguaje UMGnesis
UMGnesis es un lenguaje de dominio especfico que permite modelar aplicaciones
basadas en acceso a datos. Est diseado para permitir modelar rpidamente la mayor
parte de la aplicacin, incluyendo una vista esttica del modelo de datos y una dinmica
del trabajo sobre ellos. Permite definir ciertas reglas de negocio, validacin de datos e
integridad de los mismos. El modelo dinmico utiliza una definicin interconectada de sus
unidades de trabajo (usos que permite definir el flujo de los mismos para la interaccin
con el usuario. Para los casos de funcionalidad no contemplada dentro del modelo,
UMGnesis permite definir funcionalidades extra que sern implementadas durante la
fase de codificacin manual.
8.1.1. Vista esttica del Modelo
UMGnesis define el concepto de entidad. Este concepto es similar al que definen los
frameworks de persistencia orientados a objetos. Una entidad consiste en una clase que
define atributos y relaciones con otras entidades y cuyo tiempo de vida generalmente es
mayor al de la aplicacin (es decir que pueden ser persistentes). En UMGnesis una
entidad es la base sobre la que se construye una aplicacin. La vista dinmica del modelo

C
a
s
o

d
e

E
s
t
u
d
i
o

de la aplicacin permite definir instancias que hace uso de las entidades. Un ejemplo de
definicin de una entidad es el siguiente:
entidad Persona
{
dni "DNI": cadena(8) mascara "\\d{8}"
nombre "Nombre": cadena = {""}
apellido "Apellido": cadena
nacimiento "Fecha de Nacimiento": fechahora
edad "Edad": entero formula
{diferenciaTiempo(hoy(), nacimiento, "ao")}
hijos "Hijos" -> Persona[]
unicos {dni}
}

La entidad del ejemplo nos permite ver que en la definicin de la misma UMGnesis
permite definir los atributos con sus tipos de datos, los valores iniciales (estos pueden ser
literales o expresiones), y la forma en que se obtienen los mismos. En el caso de edad, se
ha definido que es un valor calculado y por ello no ser persistente a menos que se
indique.
Las entidades pueden no ser persistentes. Como dijimos stas son la base sobre la que se
construye el resto del modelo. Definen los tipos de datos complejos del modelo. Por ello a
veces es necesario definir un tipo de datos que no ser guardado, ser voltil. Con la
palabra clave volatil se puede indicar que una entidad ser utilizada dentro del tiempo
de ejecucin de la aplicacin. UMGnesis no admite herencia en la definicin de las
entidades en orden a mantener simple la implementacin del lenguaje y sus generadores.
8.1.2. Vista dinmica del Modelo
UMGnesis define el concepto de uso. Inspirado en el diagrama de casos de uso cada uso
representa una funcionalidad de la aplicacin a partir de la visin del usuario. UMGnesis
genera cdigo completo para cuatro tipos de uso que ofrecen una funcionalidad
predefinida: insercin, eliminacin, modificacin y listado de la informacin. Adems de
estos casos UMGnesis contempla un uso de tipo genrico que permite modelar el resto
de funcionalidades de la aplicacin y cuya implementacin ser codificada manualmente
luego de la generacin de cdigo. Los usos estn interconectados entre s definiendo el
Juan Pablo Marzetti
105

C
a
s
o

d
e

E
s
t
u
d
i
o

flujo que la aplicacin permite recorrer a los usuarios. Los usos estn atados a una entidad
particular por lo que para definir funcionalidades que sean trasversales a los distintos usos
de la aplicacin se pueden definir servicios que se estarn disponibles para los usos que
los soliciten.
A continuacin se presenta un ejemplo de un listado sobre la entidad Alumnos.
uso ListarAlumnos(curso: Curso) : listado(Alumno)
{
titulo "Listado de Alumnos del Curso"
campos {legajo, apellido, nombre, direccion, telefono}
filtros {legajo, apellido, nombre}
usos {EditarAlumno, AgregarAlumno, ListarMaterias}
}

El ejemplo precedente muestra un uso de tipo listado sobre la entidad Alumno que
muestra un listado de alumnos perteneciente a un curso determinado. Define los campos
que sern mostrados en el listado, los campos por los que se permitir filtrar el listado y
los usos a los que el usuario podr acceder a partir de ste.
8.1.3. Servicios
Los servicios permiten modelar funcionalidades que aportan al sistema pero que son
especficas y sern implementadas luego en cdigo. Ofrecen una manera de definir una
interfaz con sus mtodos para luego ser utilizados por la aplicacin.
El siguiente corresponde a un servicio que implementa la seguridad de la aplicacin. Se
basa en una entidad llamada Usuario.
servicio Seguridad
{
usuarioActual(): Usuario
usuariosConectados(): Usuario[]
iniciarSesion(nombre: cadena, clave: cadena): Usuario
tienePermiso(usuario: Usuario, permiso: Permiso): logico
cerrarSesion(): logico
}


C
a
s
o

d
e

E
s
t
u
d
i
o

8.2. Sintaxis Concreta
UMGnesis ha sido diseado y desarrollado utilizando Xtext con Eclipse Modeling
Framework. Esta herramienta permite realizar el proceso de definicin del DSL de dos
maneras distintas. Una es comenzando por la definicin de la gramtica (sintaxis concreta)
y luego inferir la sintaxis abstracta. El otro camino es el opuesto. A partir de un
metamodelo que modele la sintaxis abstracta se define la sintaxis concreta. Al definir
UMGnesis hemos optado por el primer camino por lo que partimos por mostrar la
sintaxis concreta del lenguaje y la definicin de su gramtica.
8.2.1. Definicin de la Gramtica de Xtext
A continuacin se presenta el cdigo que define la gramtica de Xtext. Los comentarios
dentro de la definicin constituyen una breve explicacin de lo que cada regla de
produccin genera.
/*
Proyecto de Tesis: Generador de aplicaciones basado en MDE
Universidad de Mendoza
Ingeniera en Informtica
Juan Pablo Marzetti
*/
grammar ar.edu.um.UMGenesis hidden(WS, ML_COMMENT, SL_COMMENT)

/*
Nombre del paquete ECore donde se generar el
metamodelo inferido para la gramtica
*/
generate umgenesis "http://www.umgenesis.org"

/*
Uso del metamodelo ECore para los tipos de datos
que los terminales devuelven.
*/
import "http://www.eclipse.org/emf/2002/Ecore" as ecore

/*
REGLA: Sistema
Es el elemento raiz del rbol de sintaxis abstracta y adems
el contenedor del modelo. A una instancia de Sistema estn
asociadas las instancias de todas las vistas del modelo.

Debe definirse un identificador que ser utilizado como
la base del espacio de nombres de los elementos generados
*/
Sistema:
"proyecto" name=IdCompuesto ("titulo" titulo=CADENA)?
(
Juan Pablo Marzetti
107

C
a
s
o

d
e

E
s
t
u
d
i
o

modeloEstatico+=Entidad |
servicios+=Servicio |
modeloDinamico+=Uso
)*;

/*
MODELO ESTATICO....................................................
Parte esttica del modelo: Entidades. Cada entidad es mapeada a una
tabla de la base de datos a menos que sea volatil (utilizada para
pasar informacion entre los usos)
===================================================================

REGLA: Entidad
*/
Entidad:
"entidad" volatil?="volatil"? name=ID "{"
propiedades+=Propiedad+
indicesUnicos+=Unico*
"}";

Propiedad:
Atributo | ReferenciaListado |
ReferenciaSimple | ReferenciaListadoMuchos;

/*
REGLA: Atributo
Define una propiedad que contiene un valor escalar. Este tipo
de propiedades admite un valor por defecto, una frmula de
clculo (en cuyo caso el valor ser voltil a menos que se
fuerce su persistencia), una regla de validacin del valor
y su obligatoriedad. Para todas las propiedades puede
definirse un ttulo que ser el texto mostrado para nombrar
al campo en la aplicacin.
*/
Atributo:
name=ID nombrePublico=CADENA? ":" tipo=Tipo
(("formula" "{" formula=Expresion "}")
persistente?="persistente"?)?
("validacion" "{" regla=Expresion "}")? opcional?="opcional"?;

/*
REGLA: Referencia*
Este tipo de propiedades, como su nombre lo indica, apuntan
a otras entidades y puede definirse la cardinalidad de la
relacin.

ReferenciaSimple: 1 a 1
ReferenciaListado: 1 a n
ReferenciaListadoMuchos: n a m
*/
ReferenciaSimple:
name=ID nombrePublico=CADENA? "->" relacion=[Entidad]
opcional?="opcional"?;

ReferenciaListado:

C
a
s
o

d
e

E
s
t
u
d
i
o

name=ID nombrePublico=CADENA? "->" relacion=[Entidad]"[]";

ReferenciaListadoMuchos:
name=ID nombrePublico=CADENA? "->" relacion=[Entidad]"[*]";

/*
REGLA: Unico
Definicin de ndices que comprueban que no se repita un conjunto
de campos entre todas las instancias de una entidad.
*/
Unico:
"unicos" name=ID? "{" campos+=[Propiedad]
("," campos+=[Propiedad])* "}";

/*
REGLA: Tipo*

Define los tipos de datos escalares que se especifican en los
atributos. Cada tipo tiene una correspondencia con un tipo de
datos del lenguaje de programacin para el que se generar el
cdigo y tambin con el tipo de datos del motor de base de
datos.
*/
Tipo:
TipoEntero | TipoReal | TipoCadena | TipoTexto |
TipoBooleano | TipoFechaHora;

TipoEntero: nombreTipo="entero" ("=" "{" valorDefecto=Expresion "}")?;

TipoReal: nombreTipo="real" ("=" "{" valorDefecto=Expresion "}")?;

TipoCadena: nombreTipo="cadena" ("(" largoMaximo=NATURAL ")")?
("=" "{" valorDefecto=Expresion "}")? ("mascara" mascara=CADENA)?;

TipoTexto: nombreTipo="texto" ("=" "{" valorDefecto=Expresion "}")?;

TipoFechaHora: nombreTipo="fechahora"
("=" "{" valorDefecto=Expresion "}")? ("mascara" mascara=CADENA)?;

TipoBooleano: nombreTipo="logico" ("=" "{" valorDefecto=Expresion "}")?;

/*
MODELO DINAMICO....................................................
Parte dinmica del modelo: Usos. Representan los usos que se le
dan a la aplicacin. De esta definicin se crean las pantallas y
los flujos de informacin y navegacin dentro de la aplicacin.
===================================================================

Un uso puede definir parmetros de entrada con los
que contar al iniciar el mismo. Adems debe definir qu tipo
de uso ser y la entidad sobre la cual trabajar.

Los usos iniciales son los que se presentan en el men al iniciar
la aplicacin. Si se define slo un uso inicial, la aplicacin
mostrar este primer uso, si se definen varios, aparecer un men
para seleccionar a cual se desea ir. Si no se define ninguno como
Juan Pablo Marzetti
109

C
a
s
o

d
e

E
s
t
u
d
i
o

inicial, todos los usos sern considerados iniciales.
*/
Uso:
"uso" inicial?="inicial"? name=ID
("(" parametros+=UsoParametro ("," parametros+=UsoParametro)* ")")?
":" tipo=UsoTipo;

UsoParametro:
name=ID ":" entidad=[Entidad]listado?="[]"?;

/*
REGLA: UsoTipo*

UMGnesis contempla 5 tipos de uso. Cuatro de ellos sern
completamente implementados
por el generador de cdigo mientras que el uso generco est
pensado para ser
implementado en la etapa de generacin manual.
*/
UsoTipo:
UsoTipoListado | UsoTipoInsercion | UsoTipoVista |
UsoTipoEdicion | UsoTipoEliminacion | UsoTipoGeneral;

UsoTipoListado:
tipo="listado" "(" entidad=[Entidad] ")" "{"
("titulo" titulo=CADENA)?
("campos" "{" camposMostrados+=[Propiedad|ID]
("," camposMostrados+=[Propiedad|ID])* "}")?
("filtros" "{" propiedadesFiltro+=IdCompuesto
("," propiedadesFiltro+=IdCompuesto)* "}")?
("usos" "{" usosRelacionados+=[Uso]
("," usosRelacionados+=[Uso])* "}")?
("servicios" "{" serviciosInvolucrados+=[Servicio]
("," serviciosInvolucrados+=[Servicio])* "}")?
"}";

UsoTipoInsercion:
tipo="insercion" "(" entidad=[Entidad] ")" "{"
"}";

UsoTipoEdicion:
tipo="edicion" "(" entidad=[Entidad] ")" "{"

C
a
s
o

d
e

E
s
t
u
d
i
o

"}";

UsoTipoVista:
tipo="vista" "(" entidad=[Entidad] ")" "{"
"}";

UsoTipoEliminacion:
tipo="eliminacion" "(" entidad=[Entidad] ")" "{"
confirmar?="confirmar"?
("retorno" "{" usosRelacionados+=[Uso]
"}";

UsoTipoGeneral:
tipo="general" ("(" entidad=[Entidad] ")")? "{"
"}";

/*
Servicios

Un servicio define mtodos que sern luego utilizados por la
aplicacin. Tanto en los parmetros como en el valor devuelto
se admiten entidades y valores escalares
==============================================================
*/

ServicioFuncionParametro:
name=ID ":" (tipoEscalar=("cadena"|"entero"|"real"|
"fechahora"|"logico"|"texto") |
entidad=[Entidad]) listado?="[]"?;

ServicioFuncion:
name=ID "(" (parametros+=ServicioFuncionParametro
("," parametros+=ServicioFuncionParametro)*)? ")"
(":" (tipoEscalar=("cadena"|"entero"|"real"|"fechahora"|
"logico"|"texto") | entidad=[Entidad]) listado?="[]"?)?;

Servicio:
"servicio" name=ID "{"
funciones+=ServicioFuncion+
"}";

Juan Pablo Marzetti
111

C
a
s
o

d
e

E
s
t
u
d
i
o

/*
ACCESORIOS.........................................................
Se definen accesorios para la gramtica como son las expresiones
que servirn para generar valores o validarlos.
===================================================================
*/

Valor:
literalCadena=CADENA | literalEntero=(ENTERONEGATIVO|NATURAL) |
literalReal=REAL | literalLogico=(KW_VERDAD|KW_FALSO) |
funcion=Funcion | variable=IdCompuesto |
"(" expresion=Expresion ")";

Funcion:
name=ID "(" argumentos=Argumentos? ")";

Argumentos: argumentos+=Expresion ("," argumentos+=Expresion)*;

Elemento: operacion=("!"|"~")? izquierda=Valor;

ElementoDerecha: operacion=("*"|"/"|"%") expresion=Elemento;

Factor: izquierda=Elemento derecha+=ElementoDerecha*;

FactorDerecha: operacion=("+"|"-") expresion=Factor;

Termino: izquierda=Factor derecha+=FactorDerecha*;

Expresion5: izquierda=Termino
(operacion=("<"|"<="|">"|">=") derecha=Termino)?;

Expresion4: izquierda=Expresion5
(operacion=("<>"|"=") derecha=Expresion5)?;

Expresion3: izquierda=Expresion4 ("&" derecha+=Expresion4)*;

Expresion2: izquierda=Expresion3 ("|" derecha+=Expresion3)*;

Expresion1: izquierda=Expresion2 ("&&" derecha+=Expresion2)*;

Expresion: izquierda=Expresion1 ("||" derecha+=Expresion1)*;

IdCompuesto returns ecore::EString:
ID("." ID)*;

//Terminales

terminal KW_VERDAD returns ecore::EBooleanObject: "verdadero";
terminal KW_FALSO returns ecore::EBooleanObject: "falso";

terminal ENTERONEGATIVO returns ecore::ELongObject: "-""0".."9"+;

terminal NATURAL returns ecore::ELongObject: "0".."9"+;

terminal REAL returns ecore::EDoubleObject:

C
a
s
o

d
e

E
s
t
u
d
i
o

(ENTERONEGATIVO|NATURAL)"."NATURAL+
(("E"|"e")(ENTERONEGATIVO|NATURAL))?;

terminal CADENA returns ecore::EString:
"\"" ( "\\" ("b"|"t"|"n"|"f"|"r"|"\""|"\'"|"\\") |
!("\\"|"\"") )* "\"";

terminal ID : ("a".."z"|"A".."Z")
("a".."z"|"A".."Z"|"0".."9")*;

terminal ML_COMMENT : "/*" -> "*/";
terminal SL_COMMENT : "//" !("\n"|"\r")* ("\r"? "\n")?;

terminal WS : (" "|"\t"|"\r"|"\n")+;

8.2.2. Elementos de la sintaxis de UMGnesis
8.2.2.1. Entidad
entidad [volatil] <identificador>
{
<definicin de campo>
...
<definicin de campo>

<definicin de ndice nico>
...
<definicin de ndice nico>
}
8.2.2.1.1. Identificador
Los identificadores en UMGnesis estn definidos de la siguiente manera:
[a-zA-Z]([a-zA-Z]0-9)*. Deben comenzar con una letra de la A-Z o a-z y seguir
con cualquier combinacin de las mismas o de cifras numricas.
8.2.2.1.2. Definicin de Campo Escalar

<identificador> [<titulo del campo>] : <tipo de datos> [= {expresion}]
[formula {<expresion>} [persistente]] [validacion {<expresion>}]
[opcional]

Los campos escalares permiten modelar datos simples del dominio. UMGnesis admite
valores de tipo cadena, texto, logico, entero, real y fechahora. Slo es
necesario para definir un campo especificar su nombre y su tipo. Los dems parmetros
Juan Pablo Marzetti
113

C
a
s
o

d
e

E
s
t
u
d
i
o

son todos opcionales. A continuacin se detallan los tipos de datos y los distintos
parmetros que los modifican.

8.2.2.1.2.1. Tipos de datos
cadena[(largo mximo)]: Permite definir un atributo que contiene caracteres
hasta un mximo de 255. Para definirlo puede escribirse slo la palabra clave cadena en
cuyo caso se tomar con el largo mximo posible o se puede informar una longitud
mxima menor agregando el nmero entre parntesis. Ej: nombre: cadena(32) Las
cadenas permiten especificar una mscara de entrada para restringir los valores vlidos.
Dicha mscara ser ingresada en formato de expresiones regulares como una cadena. Ej.
dni: cadena(8) mascara "\\d{8}" ocho dgitos numricos.
texto: Permite almacenar grandes cantidades de informacin textual.
entero: Corresponde a enteros con signo de 64bits o 32bits (segn el valor mximo
permitido por la plataforma a la que se genera).
real: Valores en punto flotante doble.
logico: Valores de tipo booleano verdadero y falso.
fechahora: Valores de tipo temporal. Permite ingresar fechas, horas o ambas. Para
controlar la informacin ingresada y mostrada se puede especificar una mscara segn los
siguientes cdigos de campos:
Smbolo Significado Ejemplo
a
Nmero del ao 2010
m
Mes del ao 1, 01, Ene o Enero
d
Da del mes 1 o 01
h
Hora del da (12 horas) 5, 05
H
Hora del da (24 horas) 17
i
Minutos 55
s
Segundos 30

C
a
s
o

d
e

E
s
t
u
d
i
o

De uno a tres smbolos seguidos se representa la forma abreviada del elemento. Por
ejemplo: d = 1 dd = 01 ddd = Lun. Cuatro o ms repeticiones indican la forma
extensa. Ejemplo dddd= Lunes, aaaa = 2010, mmmm = Enero.
8.2.2.1.2.2. Valores iniciales
Se puede determinar que un campo tenga un valor inicial que ser especificado por una
expresin. Dicha expresin deber devolver un valor cuyo tipo de datos sea compatible
con el del campo.
Opciones Generales para todos los tipos de Datos
Ttulo del
Campo
Es una cadena de texto que permite expresar un ttulo ms presentable y explicativo
del campo en la aplicacin.
Frmula Permite indicar que el campo es un valor autocalculado. Para ello se debe
especificar la expresin que se utilizar para dicho fin. Ej: Para un campo que asigne
valores automticamente en orden creciente, podra ingresarse la siguiente frmula:
numero: entero formula{maximo(numero)+1} Los campos con este
parmetro no sern persistidos en la base de datos a menos que se agregue luego
de la expresin la palabra persistente que indicar que an siendo autocalculado
sus valores debern ser guardados. Este comportamiento modifica la manera en que
se autocalculan campos, realizndose slo la primera vez (cuando el campo tiene un
valor nulo) y mantenindose ese valor.
Validacin Permite ingresar una regla de validacin para el campo actual. Dicha regla se
especificar como una expresin que deber devolver siempre un valor lgico. Se
admitirn como validos aquellos valores cuya validacin devuelva verdadero.
Opcional Los campos opcionales no son requeridos a la hora de ser persistidos en cuyo caso
sern guardados en la base de datos como NULL. Tampoco se realiza validacin de
estos campos en las pantallas de la aplicacin.
8.2.2.1.3. Definicin de Referencia 1 a 1

<identificador> [<titulo del campo>] -> <entidad> [opcional]

Juan Pablo Marzetti
115

C
a
s
o

d
e

E
s
t
u
d
i
o

Permite definir una referencia 1 a 1 a otra entidad definida dentro del modelo. Si la
entidad referenciada es voltil, el campo no ser persistente y ser responsabilidad de los
desarrolladores a la hora de la implementacin especfica determinar los datos del campo.
Si por el contrario la entidad padre es voltil obviamente ninguno de los campos ser
persistente, aunque s podr contener campos con referencias a entidades persistentes.
Una vez ms ser responsabilidad de los desarrolladores rellenar con datos los objetos de
dichas entidades.
8.2.2.1.3. Definicin de Referencia 1 a n

<identificador> [<titulo del campo>] -> <entidad>[]

Nota: Los corchetes dobles [] al final de la definicin no indican opcionalidad en la
definicin. Son los caracteres especficos que definen la relacin 1 a n.
Permite definir una referencia 1 a n a otra entidad definida dentro del modelo. Este tipo
de referencias se implementan con acciones en cascada a la hora de actualizar y eliminar
las entidades que las contienen. Deben tenerse en cuenta las mismas consideraciones que
para los campos de referencia 1 a 1.
8.2.2.1.4. Definicin de Referencia n a m

<identificador> [<titulo del campo>] -> <entidad>[*]

Nota: Los corchetes dobles [*] al final de la definicin no indican opcionalidad en la
definicin. Son los caracteres especficos que definen la relacin n a m.
Permite definir una referencia n a m a otra entidad definida dentro del modelo. Este tipo
de referencias NO se implementan con acciones en cascada a la hora de actualizar y
eliminar las entidades que las contienen. Deben tenerse en cuenta las mismas
consideraciones que para los campos de referencia 1 a 1.
8.2.2.2. Uso
Todos los usos permiten recibir parmetros como entrada a los mismos. UMGnesis
tratar de completar dichos parmetros si es capaz de inferir los datos a partir de la

C
a
s
o

d
e

E
s
t
u
d
i
o

informacin del uso anterior (la entidad del uso anterior, debe tener campos que
coincidan en nombre y tipo de datos con los parmetros del uso al que se dirige). A
continuacin se muestra la sintaxis y la funcionalidad de cada tipo de uso.

8.2.2.2.1. Parmetros

<identificador> : <entidad>[]

Cada parmetro indicado estar definido por un identificador y como tipo de datos slo se
permiten entidades (persistentes o voltiles). Si se agrega *+ luego del nombre de la
entidad el parmetro recibe un listado de entidades en lugar de un valor escalar.
8.2.2.2.2. Uso de Listado de Datos

uso <identificador>[(<parametros>)] : listado(<entidad>) {
[titulo <cadena>]
[campos {<campos>}]
[filtros {<campos>}]
[usos {<usos>}]
[servicios {<servicios>}]
}

El Uso de Listado de Datos muestra un listado de las instancias de la entidad definida
como base. Permite determinar que campos se mostrarn y si se permitir filtrar por
alguno de ellos.
Campos Enumeracin de los campos a mostrar en el listado. Slo se admiten campos escalares
o de referencia 1 a 1.
Filtros Enumeracin de los campos por los que se permitir filtrar la informacin.
Usos Usos relacionados con este uso. Si se enumeran en este campo usos que tengan como
base a la misma entidad que el uso actual, los accesos a estos usos sern ubicados por
cada tem del listado y asociados al tem en particular. Si los usos no tienen a la misma
entidad base se ubicarn en un men aparte (depende de cada generador).
Servicios Todos los servicios declarados en este listado estarn disponibles para ser utilizados
por el controlador del uso cuando lo necesite.
Juan Pablo Marzetti
117

C
a
s
o

d
e

E
s
t
u
d
i
o

8.2.2.2.3. Uso de Vista de Datos

uso <identificador>[(<parametros>)] : vista(<entidad>) {
[titulo <cadena>]
[campos {<campos>}]
[usos {<usos>}]
}

El Uso de Vista de Datos permite mostrar los datos de una instancia de la entidad
correspondiente. Este uso es una vista bsica que puede ser modificada para presentar los
datos de la manera que sea necesaria.
Campos Enumeracin de los campos a mostrar en la vista. Se admiten todos los tipos de datos.
Usos Usos relacionados con este uso.
Servicios Todos los servicios declarados en este listado estarn disponibles para ser utilizados
por el controlador del uso cuando lo necesite.

8.2.2.2.4. Uso de Insercin de Datos

uso <identificador>[(<parametros>)] : insercion(<entidad>) {
[titulo <cadena>]
[campos {<campos>}]
[usos {<usos>}]
}

El Uso de Insercin de Datos permite agregar nuevas instancias de la entidad indicada.
Tambin puede verse el uso Edicin de Datos que es similar a este slo que requiere que
las instancias de la entidad existan. Para ver un detalle de los parmetros de este uso
referirse al Uso de Vista de Datos
8.2.2.2.5. Uso de Edicin de Datos

uso <identificador>[(<parametros>)] : edicion(<entidad>) {
[titulo <cadena>]
[campos {<campos>}]
[usos {<usos>}]

C
a
s
o

d
e

E
s
t
u
d
i
o

}

El Uso de Edicin de Datos permite modificar los valores de las instancias de la entidad
indicada. Para ver un detalle de los parmetros de este uso referirse al Uso de Vista de
Datos

8.2.2.2.5. Uso de Eliminacin de Datos

uso <identificador>[(<parametros>)] : eliminacion(<entidad>)
{
[titulo <cadena>]
[confirmar]
[retorno {<usos>}]
}

El Uso de Eliminacin de Datos permite eliminar una instancia de la entidad sealada.
Confirmar Si se indica esta orden, el uso mostrar una pantalla para confirmar la operacin
antes de realizarla.
Retorno Uso al que se dirigir luego de eliminar una instancia.
8.2.2.2.6. Uso de Tipo General

uso <identificador>[(<parametros>)] : general(<entidad>) {
[titulo <cadena>]
[usos {<usos>}]
}

Para los casos no contemplados por UMGnesis existe este uso que permite definir la
estructura bsica en el modelo y luego implementar la funcionalidad especfica en el
cdigo.
8.2.2.3. Servicio

servicio <identificador> {
<definicion de funcin>
}
Juan Pablo Marzetti
119

C
a
s
o

d
e

E
s
t
u
d
i
o

<definicion de funcion> ->
<identificador>([<parametros>])[: <tipo escalar|entidad>[]]
<parametros> ->
<identificador> : <tipo escalar|Entidad>[]

Un servicio define mtodos que sern luego utilizados por la aplicacin. Tanto en los
parmetros como en el valor devuelto se admiten entidades y valores escalares (cadena,
real, entero, etc.) y si se agrega [] luego del tipo de datos, se puede trabajar con arreglos.
Los mtodos de los servicios pueden ser sobrecargados definiendo mtodos con el mismo
nombre pero diferente signatura.
8.2.2.4. Expresiones
El lenguaje de expresiones de UMGnesis permite definir valores por defecto, frmulas
para los campos que se autocalculan y reglas de validacin. Est basado en un
subconjunto de las expresiones de Java.
El lenguaje de expresiones trabaja con los atributos de una entidad especfica y en el
mbito de la misma. Los operadores slo admiten valores atributos, pero ciertas funciones
permiten trabajar con referencias mltiples para hacer agregacin de datos.
8.2.2.4.1 Precedencia de Operadores
Los operadores de UMGnesis se presentan a continuacin y se evalan teniendo en
cuenta un orden de precedencia. Los operadores de la tabla que estn ms arriba se
evalan antes que los de la parte inferior.
Operadores de Negacin
! ~ Operadores de negacin lgica y de bits
respectivamente
Operadores de Multiplicacin
* / % Operadores de multiplicacin, divisin y
mdulo o resto de la divisin entera.
Operadores de Adicin
+ - Suma y Resta
Operadores de Comparacin
< <= >= > Menor que, Menor o igual que, Mayor que,
Mayor o igual que.
Operadores de Igualdad
= <> Igual que, Distinto que
Operadores de conjuncin de
& AND para bits.

C
a
s
o

d
e

E
s
t
u
d
i
o

Bits
Operadores de disyuncin de
bits
| OR para bits.
Operadores de conjuncin
lgica
&& AND para valores lgicas.
Operadores de disyuncin
lgica
|| OR para valores lgicas.
Figura 14. Precedencia de Operadores en UMGnesis

8.2.2.4.2 Funciones definidas
UMGnesis permite utilizar un nmero reducido de funciones que cada generador debe
implementar.
8.2.2.4.2.1. Suma
Funcin de agregacin utilizada para sumar una lista de valores.
suma(<propiedad numrica>)

El argumento de esta funcin debe ser una propiedad numrica. Si se especifica una
propiedad de la propia entidad, se suman los valores pertenecientes a todas las instancias
de la entidad. Si se especifica una propiedad perteneciente a una entidad referenciada por
la entidad en la que se define la expresin que contiene a la funcin, se sumarn los
valores pertenecientes a todas las referencias.
8.2.2.4.2.2. Mximo
Funcin de agregacin utilizada para obtener el mximo valor de una lista de valores.
maximo(<propiedad numrica>)

Para una descripcin del argumento que acepta ver lo declarado en la funcin Suma.
8.2.2.4.2.3. Mnimo
Funcin de agregacin utilizada para obtener el mnimo valor de una lista de valores.
minimo(<propiedad numrica>)

Juan Pablo Marzetti
121

C
a
s
o

d
e

E
s
t
u
d
i
o

8.2.2.4.2.4. Promedio
Funcin de agregacin utilizada para obtener el valor promedio de una lista de valores.
promedio(<propiedad numrica>)

8.2.2.4.2.5. Cantidad
Funcin que devuelve la cantidad de instancias a las que hace referencia una propiedad.
cantidad(<propiedad de referencia 1 a n o n a m>)

8.2.2.4.2.6. Buscar
Funcin que devuelve el ndice posicional en que se encuentra aguja en pajar. Si no se
encuentra, devuelve -1.
buscar(pajar: cadena, aguja: candea)

8.2.2.4.2.7. Seccin
Funcin que devuelve una porcin de una cadena.
seccion(fuente: cadena, inicio: entero[, final: entero])

Si se especifica solo los dos primeros parmetros, seccion devolver la porcin de
cadena que empieza en inicio hasta el final de fuente. Si se especifican los tres
parmetros devolver la subcadena que empieza en inicio y termina en final.
8.2.2.4.2.8. aCadena, aTexto
Funcin que convierte un valor en su representacin textual.
aCadena(propiedad)

aTexto(propiedad)

8.2.2.4.2.9. aEntero
Funcin que convierte un valor en un nmero entero.
aEntero(propiedad)

C
a
s
o

d
e

E
s
t
u
d
i
o

El valor que retorna esta funcin depende del tipo de datos de entrada. Si la entrada es:
Real o Entero: Devuelve la parte entera del nmero.
Texto o Cadena: Trata de convertirlo a nmero o devuelve 0.
Logico: Devuelve 1 si es verdadero y 0 si es falso.
FechaHora: Devuelve el valor de tiempo en formato Unix.
8.2.2.4.2.10. aReal
Funcin que convierte un valor en un nmero real.
aReal(propiedad)

El valor que retorna esta funcin depende del tipo de datos de entrada y el
funcionamiento es anlogo al de aEntero.
8.2.2.4.2.11. aLogico
Funcin que convierte un valor en un valor lgico
aLogico(propiedad)

El valor que retorna esta funcin depende del tipo de datos de entrada. Si la entrada es:
Real o Entero: Devuelve verdadero si el nmero es distinto de 0.
Texto o Cadena: Devuelve verdadero si es igual a la palabra verdadero.
FechaHora: Devuelve siempre verdadero.
8.2.2.4.2.12. aFechaHora
Funcin que convierte una cadena en un valor de fecha y hora.
aFechaHora(cadena)

8.2.2.4.2.13. sumarTiempo
Funcin que permite manipular una fecha.
sumarTiempo(fecha, desplazamiento, tipo)

Juan Pablo Marzetti
123

C
a
s
o

d
e

E
s
t
u
d
i
o

El valor devuelto por esta funcin es de tipo fechahora y se calcula sumando el valor
especificado por desplazamiento al valor de fecha teniendo en cuenta el parmetro
tipo. Este parmetro especifica cul es la unidad en que se ha expresado
desplazamiento y puede valer: segundo, minuto, hora, dia, ao.

8.2.2.4.2.15. diferenciaTiempo
Funcin que permite obtener un valor temporal a partir de una diferencia.
diferenciaTiempo (fechaA, fechaB, tipo)

El valor devuelto por esta funcin es de tipo entero y expresa la diferencia fechaA -
fechaB en la unidad especificada por tipo. Este parmetro especifica cul es la unidad
en que se ha expresado el resultado y puede valer: segundo, minuto, hora, dia,
ao.
8.2.2.4.2.15. hoy
Funcin que devuelve la fecha y hora actuales.
hoy()

8.3. Sintaxis Abstracta
Como se mencion anteriormente, se opt por definir primero la sintaxis concreta del DSL
UMGnesis y luego dejar que Xtext infiriera la sintaxis abstracta y el metamodelo Ecore
que la respalda.
8.3.1. Metamodelo de la Sintaxis abstracta
A continuacin se presenta el metamodelo Ecore generado por Xtext seccionado en varias
imgenes dada su extensin.

C
a
s
o

d
e

E
s
t
u
d
i
o

Figura 15. Sintaxis abstracta de UMGnesis Vista Esttica
8.3.1.1 Sistema
Clase que representa la raz del rbol de sintaxis. Es el contenedor primario de donde se
refieren las entidades, los usos y los servicios.
8.3.1.1.1 Atributos
name: Nombre del proyecto que se modela. Los generadores lo utilizan como ruta
base de los paquetes donde almacenan las clases (en el caso de que el lenguaje
admita espacio de nombres). Admite una ruta completamente calificada. Ej:
org.umgenesis.stock.
titulo: Ttulo que se le da al sistema. Los generadores lo utilizarn para las
pantallas generadas. Ej. Sistema de Stock
Juan Pablo Marzetti
125

C
a
s
o

d
e

E
s
t
u
d
i
o

8.3.1.1.2 Referencias
modeloEstatico: Coleccin de todas las entidades definidas en el modelo.
modeloDinamico: Coleccin de todos los usos definidos en el modelo.
Servicios: Coleccin de todos los servicios definidos en el modelo.
8.3.1.2 Entidad
Clase que representa la informacin de una entidad de la vista esttica del modelo. Lo
descrito en la sintaxis concreta acerca de las propiedades de las entidades es aplicable
aqu.
8.3.1.2.1 Atributos
name: Nombre de la entidad. Se sugiere como convencin que este nombre
empiece con mayscula y siga con minsculas siendo mayscula cada inicio de
palabra.
volatil: Indica si una entidad es o no voltil. Si este valor es true la entidad es
considerada no persistente.
propiedades: Coleccin de todas las propiedades de la entidad. Estas pueden ser
atributos simples, referencias simples (1 a 1), referencias a listados (1 a n),
referencias a listados presentes en mltiples entidades (n a m).
indicesUnicos: Coleccin de todos los ndices definidos como grupos de atributos
que no pueden repetirse en dos instancias de un mismo tipo de entidad.
8.3.1.3 Propiedad
Clase que representa las propiedades de una entidad. Esta clase nunca se instancia ya que
sirve como generalizacin de los cuatro tipos de propiedad que UMGnesis admite.
8.3.1.3.1 Atributos
name: Nombre de la propiedad. Se sugiere como convencin que este nombre siga
la convencin camel case.

C
a
s
o

d
e

E
s
t
u
d
i
o

nombrePublico: Nombre con el que la propiedad se muestra en las pantallas de la
aplicacin.
8.3.1.3.2 Especificaciones
Atributo
ReferenciaSimple
ReferenciaListado
ReferenciaListadoMuchos
Las referencias son muy simples de comprender. Se utiliza el mecanismo de especificacin
para determinar el tipo de propiedad de que se trata. As tenemos tres clases Referencia*
que distinguen de qu tipo de propiedad se trata. Los atributos los estudiaremos con
mayor detalle a partir de otra porcin del diagrama que nos muestra los tipos de datos
aceptados y sus parmetros.

Figura 16. Sintaxis abstracta de UMGnesis Tipos de Datos Escalares
8.3.1.4 Atributo
Clase que representa la informacin de un atributo escalar.
Juan Pablo Marzetti
127

C
a
s
o

d
e

E
s
t
u
d
i
o

8.3.1.4.1 Atributos
opcional: Indica si este atributo ser requerido a la hora de persistir la entidad o no.
persistente: Indica si este atributo es guardado en la base de datos o no. El mbito
de validez de este atributo es en relacin a la existencia de una frmula de
autoclculo. Los atributos son persistentes por defecto, pero si se especifica una
frmula sern no persistentes a menos que este atributo sea true.
tipo: Tipo de datos del atributo y sus parmetros especficos.
regla: Expresin que debe evaluar a un valor de tipo lgico. Si se especifica se
utilizar para validar el valor del campo. Un campo ser considerado vlido si el
resultado de esta expresin es verdadero.
formula: Expresin que define cmo se obtendr el valor de este atributo. Debe
evaluar a un valor cuyo tipo de datos sea compatible con el tipo de datos del
atributo.
valorDefecto: Expresin que define cul ser el valor inicial de atributo. Debe
evaluar a un valor cuyo tipo de datos sea compatible con el tipo de datos del
atributo.
propiedades: Coleccin de todas las propiedades de la entidad. Estas pueden ser
atributos simples, referencias simples (1 a 1), referencias a listados (1 a n),
referencias a listados presentes en mltiples entidades (n a m).
indicesUnicos: Coleccin de todos los ndices definidos como grupos de atributos
que no pueden repetirse en dos instancias de un mismo tipo de entidad.

C
a
s
o

d
e

E
s
t
u
d
i
o

Figura 17. Sintaxis abstracta de UMGnesis Vista Dinmica - Usos
8.3.1.5 Uso
Clase que representa la informacin de un atributo escalar.
8.3.1.5.1 Atributos
inicial: Indica si este es un uso inicial.
name: Nombre del uso. Los controladores (si el generador utiliza MVC como
patrn de diseo) se llamarn con este nombre.
parametros: Listado de parmetros que el uso acepta como entrada. Los
parmetros pueden ser slo referencias simples o mltiples a entidades y no datos
escalares.
tipo: Instancia de una clase que representa el tipo particular del uso y sus
parmetros asociados.
8.3.1.6 UsoTipo
Clase que representa el tipo de uso. Esta clase nunca se instancia ya que es la base para
las clases de tipos especficos.
Juan Pablo Marzetti
129

C
a
s
o

d
e

E
s
t
u
d
i
o

8.3.1.6.1 Atributos
tipo: Nombre del tipo de uso
titulo: Nombre pblico con el que se denomina al uso.
usosRelacionados: Listado de usos a los que se podr acceder a partir de este uso.
serviciosInvolucrados: Listado de servicios cuyas instancias debern estar
presentes en el controlador del uso para la posterior implementacin que se le
necesite dar.
8.3.1.6.3 Especificaciones
UsoTipoListado
UsoTipoVista
UsoTipoEdicion
UsoTipoInsercion
UsoTipoEliminacion
UsoTipoGeneral

Figura 18. Sintaxis abstracta de UMGnesis Vista Dinmica Servicios

C
a
s
o

d
e

E
s
t
u
d
i
o

Como se explic en la seccin anterior (Sintaxis Concreta) los servicios son una forma de
modelar mdulos que ofrezcan cierta funcionalidad especfica de la aplicacin. La
estructura de la sintaxis abstracta refleja la porcin del metamodelo que permite modelar
un servicio con la signatura de sus funciones.
Los parmetros y los valores de retorno de las funciones hacen referencia tanto a
entidades como a valores escalares y pueden ser listados o simples.
8.4. Implementacin del analizador con Xtext
A continuacin se detallarn los pasos seguidos para implementar el DSL UMGnesis con
Xtext. La presente seccin explica cmo plasmar la gramtica anteriormente descrita.
Adems se explica las personalizaciones realizadas al cdigo generado por Xtext y los
beneficios o funcionalidades extra que aportan.
Una vez seguidos todos los pasos mencionados en esta seccin se obtiene tres plug-ins
para eclipse que ofrecen un editor textual para UMGnesis con completado de cdigo,
control de errores sintcticos y semnticos. Tambin ofrece vista outline personalizada,
formateado de cdigo, enlazador aumentado con referencias cruzadas y la instanciacin
del metamodelo Ecore para luego ser utilizado por los generadores.
8.4.1. Creacin del proyecto
En el captulo anterior, bajo la seccin 10.3.1 se indic como crear un proyecto Xtext. Para
crear el proyecto UMGnesis se eligieron los siguientes parmetros:
Nombre: ar.edu.um.umgenesis
Nombre del Lenguaje: ar.edu.um.Umgenesis
Extensin: umgen
Una vez creado, el rbol del explorador de proyectos luce como el siguiente:
Juan Pablo Marzetti
131

C
a
s
o

d
e

E
s
t
u
d
i
o

Figura 19. Proyectos de UMGnesis
Como se explic anteriormente, se generan dos carpetas de cdigo en cada proyecto: src
y src-gen para distinguir el cdigo fuente escrito manualmente del generado
respectivamente.
8.4.2. Especificacin de la gramtica y generacin de los artefactos
Una vez creado los proyectos, nos dirigimos al proyecto ar.edu.um.umgenesis y
dentro de la carpeta src encontramos una definicin de ejemplo para la gramtica
UMGnesis en el archivo Umgenesis.xtext. Introducimos la gramtica descrita
anteriormente en la seccin 8.2.1 y luego generamos todos los artefactos de software
corriendo el workflow GenerateUmgenesis.mwe.
El workflow es un archivo XML que especifica el orden en que se corren los procesos de
generacin de cdigo para generar todos los artefactos de software necesarios para darle
vida al DSL. Es parte de la implementacin del Eclipse Modeling Project.

C
a
s
o

d
e

E
s
t
u
d
i
o

Figura 20. Estructura del proyecto luego de la generacin de los artefactos.
En la Figura 20 vemos cmo se ha modificado la estructura del proyecto principal, cmo se
han creado los diversos artefactos de software y cmo se ha inferido el metamodelo
basado en Ecore de la sintaxis abstracta de nuestra gramtica. Es preciso recordar que
todo esto ha sido generado por Xtext. El nico dato de entrada ha sido la definicin de la
gramtica.
Los tres proyectos presentes en el explorador de proyectos constituyen en este punto tres
plug-ins para eclipse que ya son completamente funcionales. Si se hace clic en el botn
derecho sobre cualquiera de ellos y se selecciona Run as Eclipse Application lanzaremos
una nueva instancia del IDE con los plug-ins instalados y funcionando. Una vez ejecutado,
Juan Pablo Marzetti
133

C
a
s
o

d
e

E
s
t
u
d
i
o

creamos un nuevo archivo con extensin umgen y podremos editarlo utilizando el
analizador generado por Xtext.

Figura 21. Primera ejecucin del analizador generado
Como podemos observar, el cdigo generado nos provee un editor con coloreado de
sintaxis, deteccin de errores y anlisis al vuelo del cdigo. A la derecha de la imagen
tenemos la vista outline que nos muestra una instancia del metamodelo con los valores
del ejemplo.
El error que se muestra no corresponde con un error de sintaxis o semntico del ejemplo
presentado. Corresponde a un error interno del compilador: en la gramtica se ha
definido que los terminales numricos enteros devuelven ecore::ELong y no se
implement ningn convertidor. Xtext por defecto slo convierte la entrada a cadenas por
lo que si se trabaja con terminales que devuelven otro tipo de datos debe especificarse
cules son.
8.4.3. Personalizacin del analizador
El proyecto generado por Xtext posee diversas clases bajo la carpeta src que slo
extienden una clase abstracta correspondiente al funcionamiento que corresponde a cada

C
a
s
o

d
e

E
s
t
u
d
i
o

una. Las clases padre proveen funcionalidades genricas por lo que para personalizar el
analizador, deben sobrescribirse ciertos mtodos en las clases hijas. A continuacin
detallamos las diferentes clases implementadas y la funcionalidad que se agreg o
modific al analizador.
8.4.3.1. Conversin
Se implement la clase UMGenesisValueConverterService dentro del paquete
ar.edu.um.conversion que convierte diversos terminales al tipo de datos que se
especific retornan. Entre ellos estn:
CADENA: Si bien Xtext maneja los terminales de caracteres alfanumricos como
cadenas, no elimina las comillas que delimitan las cadenas ni elimina los caracteres
de escape. La conversin definida para este terminal realiza tales modificaciones.
KW_VERDAD y KW_FALSO: Para ambos devuelve un valor de tipo Boolean
true o false respectivamente.
ENTERONEGATIVO y NATURAL: Transforma la cadena que contiene al nmero en
un valor de tipo Long.
REAL: Transforma la cadena que contiene al nmero en un valor de tipo Double.
8.4.3.2. Formateado de Cdigo
Eclipse permite dar un formato ordenado a los archivos textuales que maneja. Xtext
permite que el editor de los DSL que define tambin posea esta caracterstica. Para ello
debe implementarse la clase UMGenesisFormatter dentro del paquete
ar.edu.um.formatting.
A continuacin se presenta un trozo de cdigo de dicha implementacin:
UMGenesisGrammarAccess f = (UMGenesisGrammarAccess)
getGrammarAccess();

c.setNoLinewrap();
c.setIndentationSpace(" ");

Juan Pablo Marzetti
135

C
a
s
o

d
e

E
s
t
u
d
i
o

//Entidades
c.setLinewrap()
.before(f.getEntidadAccess().getLeftCurlyBracketKeyword_3());

c.setLinewrap()
.before(f.getEntidadAccess().getRightCurlyBracketKeyword_6());

c.setLinewrap(2)
.after(f.getEntidadAccess().getRightCurlyBracketKeyword_6());

c.setIndentation(f.getEntidadAccess().
getLeftCurlyBracketKeyword_3(),
f.getEntidadAccess().getRightCurlyBracketKeyword_6());

8.4.3.3. mbitos
Xtext permite definir cul es el mbito para una determinada regla de produccin y qu
referencias estn presentes en dicho mbito. Es preciso recordar que Xtext permite definir
referencias cruzadas y cul es el elemento con el que se nombran. Por defecto Xtext
enlazar las referencias cuando la regla de nombramiento es ID y coincide con una
propiedad name del elemento referenciado.
En UMGnesis se han implementado los siguientes mbitos:
ndices nicos: Dentro de la definicin de ndices nicos, se hace referencia a las
propiedades que no deben repetirse. Para esta referencia se implementa un
listado de las propiedades que pueden ser listadas en este mbito.
Variables: Dentro de una expresin pueden incluirse referencias a atributos
pertenecientes a la entidad donde se est definiendo la expresin. Para poder
mostrar y enlazar dichos atributos se provee una lista de los mismos.
Campos mostrados: Para los usos: listado, insercin, edicin y vista, se provee una
lista de los campos que pueden ser enumerados para ser mostrados. Estos campos
pertenecen a la entidad base del uso.
Campos de filtro: El Uso de tipo listado permite especificar por qu campos se
podr filtrar el listado y para stos se provee un listado de los avalados.

C
a
s
o

d
e

E
s
t
u
d
i
o

8.4.3.4. Validaciones al modelo
Parte del trabajo del analizador es determinar que el modelo que se obtiene ser
semnticamente correcto. Para ello puede implementarse una clase que realice las
validaciones necesarias.
Xtext sugiere realizarlas directamente utilizando cdigo Java o el lenguaje propuesto por
openArchitectureWare Xcheck. El mismo consiste en una implementacin de un lenguaje
similar a OCL basado en el sistema de tipos de Xtend y utilizando sus mismas expresiones.
En el mbito de este proyecto se opt por utilizar OCL ya que si se desea extenderlo a un
editor visual utilizando el Eclipse Graphical Modeling Framework se puede validar el
modelo a partir de restricciones expresadas en este lenguaje.
A continuacin se presenta slo un ejemplo de cdigo que permite validar que los
nombres de las entidades sean nicos. Para un mayor detalle observar las clases ubicadas
dentro del paquete ar.edu.um.validation.
public boolean validarNombreUnico(Entidad entidad) {
return validarRestriccion((Sistema)entidad.eContainer(),
UmgenesisPackage.Literals.ENTIDAD, entidad,
"sistema.modeloEstatico->forAll(e:Entidad| e <> self implies
e.name <> self.name) and " +
"sistema.modeloDinamico->forAll(u:Uso| u.name <> self.name)
and " +
"sistema.servicios->forAll(s:Servicio| s.name <> elf.name)"
);
}
Las restricciones que se validan sobre el modelo son:
Entidad:
o Que el nombre sea nico en el conjunto de entidades, usos y servicios.
o Que las propiedades tengan nombres nicos y que ninguna se llame id.
o Que los ndices nicos (si estn nombrados) tengan nombres nicos y que
las propiedades listadas no se repitan dentro del mismo ndice.
o Que los ndices nicos no contengan referencias a campos de tipo texto, ni
a referencias mltiples.
Juan Pablo Marzetti
137

C
a
s
o

d
e

E
s
t
u
d
i
o

o Que los atributos que definen un valor por defecto o frmula presenten
coincidencia de tipos entre el tipo del atributo y el cual al que evala la
expresin.
o Que las reglas de validacin de los atributos devuelvan valores lgicos.
Uso:
o Que los parmetros de un uso tengan nombres distintos.
o Que no se repitan los usos relacionados definidos para un uso.
o Que no se repitan los servicios involucrados definidos para un uso.
o Que no se repitan los campos mostrados definidos para un uso.
o Que no se repitan los campos de filtro definidos para un uso de tipo listado.
Servicio:
o Que no exista dos funciones con el mismo nombre a menos que tengan
diferente signatura.
o Que los parmetros de una funcin tengan nombres distintos.
8.4.4. Personalizacin del editor y del entorno del IDE
As como Xtext permite personalizar la forma en que se comporta el analizador, tambin
permite definir personalizaciones a los elementos del entorno de eclipse facilitar el
trabajo de los desarrolladores. Estas personalizaciones se realizan en el proyecto
ar.edu.um.umgenesis.ui. A continuacin se comentan las que se han definido
para UMGnesis.
8.4.4.1. Proposicin de cdigo
Al presionar Ctrl + Espacio en el mbito del editor del cdigo de UMGnesis, Xtext
muestra por defecto las sugerencias que son esperables como prxima entrada. A veces
estas sugerencias no son suficientes o errneas. En los listados de elementos como
propiedades en un ndice nico, campos mostrados y dems, no debera sugerirse una
propiedad que ya fue especificada en el mismo listado. Para todos estos casos se ha

C
a
s
o

d
e

E
s
t
u
d
i
o

definido en UMGenesisProposalProvider los diferentes mtodos que sugieren
cdigo a partir del mbito en el que se encuentran.

Figura 22. Sugerencias de cdigo de UMGnesis
8.4.4.2. Etiquetado
Como podemos observar en la Figura 22 los atributos tienen una imagen distinta a la
referencia 1 a n de hijos. Xtext permite definir qu imagen y etiqueta sern utilizados
para cada elemento del modelo. A continuacin se presentan las imgenes utilizadas. Se
ha manutenido el nombre que Xtext sugiere ya que es el nombre asignado a cada
elemento.
Entidad
Atributo
Referencia
Uso de tipo Listado
Uso de tipo Vista
Uso de tipo Edicin
Uso de tipo Insercin
Uso de tipo Eliminacin
Uso de tipo General
Juan Pablo Marzetti
139

C
a
s
o

d
e

E
s
t
u
d
i
o

Servicio
8.4.4.3. Vista Outline
Esta vista de eclipse permite observar y recorrer rpidamente el modelo instanciado a
partir del anlisis del cdigo de UMGnesis. Xtext permite redefinir la estructura de esta
vista para mostrar lo que el desarrollador considere importante sobre el modelo y de la
manera ms conveniente.
Por defecto esta vista hace uso de las etiquetas explicadas anteriormente por lo que no
hay que redefinir, si no de desea, las imgenes y textos a utilizar. A continuacin se
muestran dos imgenes que comparan la vista por defecto que ofrece Xtext y la redefinida
para UMGnesis.

Figura 23. Comparacin de Vistas Outline por defecto y personalizada

C
a
s
o

d
e

E
s
t
u
d
i
o

8.4.4.4. Asistente para crear nuevos modelos
Eclipse permite personalizar sus asistentes para creacin de proyectos y archivos.
UMGnesis implementa un asistente para crear nuevos archivos .umgen con un mnimo
contenido inicial.
Dentro del proyecto ar.edu.um.umgenesis.ui, en el paquete ar.edu.um.ui.wizards
se encuentran las clases que implementan dicho asistente. Para utilizarlo, cuando estn
instalados los plug-ins de UMGnesis se elige File Other y en la lista se observar la
categora UMGnesis dentro de la cual est la opcin Modelo UMGnesis como puede
observarse en la Figura 24

Figura 24. Asistente para crear modelos UMGnesis
Juan Pablo Marzetti
141

C
a
s
o

d
e

E
s
t
u
d
i
o

8.5. Implementacin del Generador con Xpand
Una vez implementados todos los aspectos que le dan vida al lenguaje (analizador y editor
textual para el IDE) se desarroll un generador de cdigo para una plataforma especfica.
UMGnesis no determina cmo ser la arquitectura de la aplicacin generada por los
generadores de cdigo. La razn de esta decisin es que diversas plataformas no
comparten siempre una arquitectura similar para el desarrollo de software. UMGnesis s
sugiere, en cambio, que se utilice el patrn Modelo Vista Controlador (MVC) para la
aplicacin generada.
La plataforma elegida para el generador de cdigo es Java Server Faces, persistencia JPA
(utilizando la implementacin de Hibernate) y RichFaces como capa de presentacin.
Como se explic anteriormente, la idea en el diseo de UMGnesis es que se pueda
extender su funcionalidad a travs de nuevos generadores y que stos puedan hacer uso
de la funcionalidad de los existentes.
A continuacin estudiaremos la estructura bsica de un generador genrico, los
parmetros que se definen y cmo se implementa para funcionar con el resto de los
generadores. Seguidamente analizaremos el ncleo de generacin de UMGnesis (el
encargado de conectar los generadores) y finalmente estudiaremos las partes que
constituyen la implementacin del Generador de Aplicaciones Java Server Faces.
8.5.1. Estructura de un Generador
UMGnesis especifica una estructura simple para desarrollar generadores permitiendo
que stos sean rpidamente conectados con el sistema de base. La fi nos muestra la
estructura de clases que sirven de base para implementar un generador. En las secciones
siguientes podremos estudiar cada aspecto que debe ser tenido en cuenta e
implementado para dar vida a un generador.
8.5.1.1. Tipos de Generadores
Se definen cuatro tipos de generadores para UMGnesis basados en la arquitectura del
patrn MVC:

C
a
s
o

d
e

E
s
t
u
d
i
o

Motor de Base de Datos: UMGnesis permite generar los archivos de definicin de
esquemas de la base de datos apropiados para un motor particular. Si bien esto es
parte del mbito del modelo (en este caso nos referimos a modelo como el
aspecto de definicin del dominio que plantea el patrn MVC) se ha elegido
separar este aspecto para otorgar mayor flexibilidad e independencia a la capa de
persistencia.
Capa de Mapeo Objeto Relacional: La mayora de las plataformas de desarrollo
trabaja definiendo cada entidad del dominio como una clase y mediante el uso de
algn mecanismo de persistencia, relaciona cada clase con una tabla en una base
de datos relacional. Los generadores de este tipo generarn todas las clases de las
entidades, la implementacin de los mecanismos de persistencia y las relaciones
entre ellos. Esta capa junto con la anterior deberan proveer al generador siguiente
todo lo respectivo al aspecto del modelo de MVC.
Framework (Capa de Negocio): Los generadores de este tipo aprovecharn el
cdigo generado por los dos anteriores y generarn las clases (controladores de
MVC) que implementan las funcionalidades especificadas por los usos descritos en
el cdigo de UMGnesis.
Presentacin: Este generador es opcional ya que muchas veces los frameworks
utilizados para desarrollar la aplicacin admiten slo un tipo de presentacin, y
esta podr ser generada por el generador anterior (no existe la posibilidad de
elegir entre dos o ms alternativas).
8.5.1.2. Requerimientos
El sistema de generacin de cdigo de UMGnesis permite al usuario elegir qu
generadores utilizar por separado (uno por cada tipo de generador). Cmo no se define
una estructura fija de cmo son las arquitecturas de los artefactos que cada uno genera,
se utiliza un sistema de requerimientos en los que cada generador define con qu
generadores puede trabajar de las diferentes capas.
Juan Pablo Marzetti
143

C
a
s
o

d
e

E
s
t
u
d
i
o

Un generador puede definir en su interfaz de acceso cules son los generadores con los
que es compatible para cada tipo. Por ejemplo el generador implementado para JPA de
UMGnesis especifica como requerimiento previo que se haya seleccionado el generador
de motor de base de datos MySQL.
Los requerimientos guan el proceso de seleccin de los diversos tipos de generadores
permitiendo de esta manera un sistema ms flexible que puede utilizar generadores
previamente desarrollados. As, si se deseara generar aplicaciones GUI en Java Swing, se
podra utilizar el generador de JPA y el de MySQL.
8.5.1.3. Parmetros
Cada generador puede establecer un cierto nmero de parmetros que estarn presentes
para todos los generadores a la hora de generar el cdigo. Estos parmetros pueden ser
modificables o no por el usuario y puede especificarse su tipo de datos. UMGnesis
actualmente soporta parmetros de tipo String, Boolean o Enumeraciones. Este
mecanismo aporta tambin mayor flexibilidad a la hora de seleccionar un generador y
permite que los generadores puedan pasarse informacin de una manera simple.
En el caso del generador de JPA, ste se beneficia de una serie de parmetros que obtiene
del generador del motor de base de datos como son: nombre calificado de la clase del
driver JDBC y los datos de conexin.
8.5.1.4. Interfaz de acceso
Todo generador UMGnesis debe implementar la interfaz IGenerador. La clase que
implemente dicha interfaz ser el punto de acceso a la informacin del generador y
tambin el punto desde el cul este ser invocado. Puede elegirse entre implementar la
interfaz o extender la clase abstracta GeneradorAbstracto que implementa
IGenerador y contiene ciertas funcionalidades tiles para cualquier generador. Entre
ellas se cuentan preparar todo el entorno de Xpand para llamar al motor de plantillas,
nombres de parmetros comunes, convertir la salida de Xpand a una salida vlida para el
sistema de tareas programadas de eclipse, etc.

C
a
s
o

d
e

E
s
t
u
d
i
o

A continuacin se detallan los mtodos de la interfaz y la funcionalidad que deberan
implementar:
public String[] getLenguajes();

Este mtodo debe devolver un arreglo con los lenguajes de programacin para los que es
compatible este generador. Si devuelve null indica que no depende de ningn lenguaje
en particular.
public ETipoGenerador getTipo();

Este mtodo debe devolver el tipo de generador de que se trata.
public Requerimiento[] getRequerimientos();

Mtodo que debe devolver un arreglo con los requerimientos previos. Los requerimientos
actan como filtros de manera que al no especificar requerimientos para un tipo de
generador no se tendr en cuenta qu generador fue utilizado para el tipo dado. Si
devuelve null no filtra nada.
public Parametro[] getParametros();

Listado de parmetros que el generador requiere. Los parmetros definidos como
editables sern los que aparezcan en el dilogo de generacin de cdigo.
public String getNombre();

Nombre del generador. Se trata de un identificador que debe ser nico dentro del
conjunto de los generadores de UMGnesis ya que ser utilizado como referencia en los
requerimientos.
public String getDescripcion();

Descripcin del generador y su funcionalidad.
public IStatus ejecutar(Sistema modelo, Map<String,
Object>parametros, IProgressMonitor monitor);

Juan Pablo Marzetti
145

C
a
s
o

d
e

E
s
t
u
d
i
o

Mtodo que ser invocado como parte del proceso de generacin de cdigo. Debe
devolver un objeto que implemente la interfaz IStatus para indicar cmo ha resultado la
operacin.
public IStatus limpiarArchivos(Sistema modelo, Map<String,
Object>parametros, IProgressMonitor monitor);

Mtodo que ser invocado en el proceso de limpieza de los archivos del proyecto (til
para generaciones sucesivas de cdigo). Este proceso se invoca antes del proceso de
generacin de cdigo.
public String comprobarParametro(Parametro parametro, Object
valor);

Mtodo utilizado para determinar si el valor de uno de los parmetros del generador es
vlido. Este mtodo se utiliza de manera que no se pueda proceder con el proceso de
generacin de cdigo si los parmetros necesarios no tienen los valores correctos. Si
devuelve null indica que no hay errores, de lo contrario devuelve una cadena con el
error a mostrar.
8.5.1.5. Descriptor del generador
Los generadores se implementan como fragmentos de plug-ins de Eclipse. Una vez
instalados, Eclipse los asocia a todos los fragmentos de generacin al plug-in
ar.edu.um.umgenesis.generator. Este mecanismo de flexibilidad permite
adems actualizar o combinar las funcionalidades de cada generador ya que todas ellas
estn disponibles en el mismo espacio de nombres de base.
El espacio de nombres de base de los generadores es ar.edu.um.umgenesis.generadores y
cada generador anexar un paquete correspondiente a su nombre. As el generador del
motor de base de datos MySQL utiliza el espacio de nombres de base
ar.edu.um.umgenesis.generadores.mysql.
Para registrar cada generador dentro del controlador de generacin de cdigo, cada
fragmento debe incluir un archivo descriptor que indique cual es la clase que implementa

C
a
s
o

d
e

E
s
t
u
d
i
o

IGenerador para que el controlador pueda instanciarla cuando sea necesario. Dicho
archivo debe llamarse generador.xml y debe estar ubicado en la raz del archivo jar del
fragmento (por ende, en la raz del proyecto).
La estructura es bien simple por lo que se muestra un ejemplo a modo de explicacin:
<?xml version="1.0" encoding="UTF-8"?>
<generador id="jpa">
<clase>ar.edu.um.genesis.generadores.jpa.Generador</clase>
</generador>
8.5.2. Proceso de Generacin de Cdigo
Dentro del proyecto ar.edu.um.umgenesis.generator se encuentra todo lo
necesario para correr los generadores de UMGnesis. Este proyecto, como se explic en la
seccin anterior es el plug-in base de eclipse al que se conectan todos los fragmentos que
implementen algn tipo de generador.
El proyecto adems de definir la API utilizada por todos los generadores, implementa un
cuadro de dilogo flexible que permite seleccionar los distintos tipos de generadores e
introducir los parmetros que cada uno solicita. Este dilogo se implementa en la clase
DialogoPropiedadesGeneracion.
Por otro lado tambin agrega una extensin al men contextual del explorador de
proyectos. Para generar cdigo, se debe seleccionar un archivo de modelo de UMGnesis
y con el botn derecho hacer clic y elegir UMGnesis Generar Cdigo. Luego se
completan los datos requeridos y se hace clic en Generar Cdigo.
Juan Pablo Marzetti
147

C
a
s
o

d
e

E
s
t
u
d
i
o

Figura 25. Dilogo de Generacin de Cdigo
El proceso de generacin de cdigo est implementado utilizando el framework de tareas
programadas de eclipse por lo que el mismo puede administrarse de igual manera que
cualquier otro proceso disparado en el entorno. La pestaa Progress muestra el proceso
de generacin y permite cancelarlo.

Figura 26. Progreso del proceso de generacin de cdigo.

C
a
s
o

d
e

E
s
t
u
d
i
o

La clase ControladorGeneracion es el ncleo del proceso de generacin. A
continuacin se describen los pasos que realiza este proceso a partir del clic en el botn
Generar Cdigo
1. Preparacin de los parmetros: Todos los parmetros son preparados en una
coleccin que ser pasada como parmetro a todos los procesos de limpieza y
generacin de cdigo.
2. Anlisis e instanciacin del modelo: A partir del cdigo UMGnesis, se invoca al
analizador y compilador creado con Xtext para obtener una instancia del
metamodelo de sintaxis abstracta. En caso de producirse errores, el proceso
finaliza indicando la falla.
3. Generador del Motor de Base de Datos:
a. Limpieza de Archivos: Se invoca al proceso de limpieza de archivos definido
para este generador. En caso de producirse errores, el proceso finaliza
indicando la falla.
b. Generacin de cdigo: Se invoca al proceso de generacin de cdigo
definido para este generador. En caso de producirse errores, el proceso
4. Generador del Motor de Persistencia y Mapeo Objeto - Relacional:
indicando la falla.
5. Generador del Framework de Aplicaciones:
indicando la falla.
Juan Pablo Marzetti
149

C
a
s
o

d
e

E
s
t
u
d
i
o

6. Generador de la capa de presentacin (Si se ha especificado)
indicando la falla.
7. FIN: Llegados a este punto, si no se ha producido ningn error, el proceso termina
indicando su completitud exitosa.
8.5.3. Implementacin del Generador de Aplicaciones Java Server Faces
Con motivos prcticos se lo ha denominado as a un conjunto de generadores y no a uno
slo. De igual manera este conjunto es el que ejecutado completo genera una aplicacin
Java Server Faces completa y funcional.
Todos los generadores han sido implementados utilizando el sistema de plantillas Xpand
descrito en el captulo anterior.
8.5.3.1. Generador del Motor de Base de Datos MySQL
Genera un archivo {ruta de destino}/modelo/sql/modelo.sql que
contiene las instrucciones SQL para recrear la estructura de la base de datos necesaria
para modelar el sistema. A continuacin mostramos los parmetros que la interfaz
IGenerador devuelve en cada mtodo de informacin:


C
a
s
o

d
e

E
s
t
u
d
i
o

Nombre mysql
Tipo de Generador Motor de Base de Datos
Descripcin Generador de Esquema SQL para MYSQL
Lenguajes
Requerimientos
Parmetros URL de Conexin Editable
Usuario Editable
Clave Editable
Driver No Editable

8.5.3.1.1. Reglas de Generacin
Por cada entidad del modelo, este generador especifica una tabla en la base de
datos cuyo nombre ser el nombre de la entidad convertido en minsculas y con
cada paso de minsculas a maysculas se agrega un guin bajo. Por ejemplo: si la
entidad se llama ItemFactura la tabla se llamar item_factura.
Por cada entidad, la tabla contiene los siguientes elementos:
o Una columna id de tipo auto incremental que es clave primaria.
o Por cada atributo que deba ser persistido una columna con el nombre
convertido de la misma manera que el nombre de la tabla y el tipo de datos
segn la siguiente tabla:
Tipo de Datos UMGnesis Tipo de Datos MySQL
cadena(largo mximo) VARCHAR(largo mximo) o
VARCHAR(255)
texto TEXT
logico TINYINT
entero INT
real DOUBLE
fechahora DATETIME

Juan Pablo Marzetti
151

C
a
s
o

d
e

E
s
t
u
d
i
o

o Por cada referencia 1 a 1, una columna cuyo nombre se compone de el
nombre de la propiedad transformado como los anteriores con el sufijo
_id. Esta columna es de tipo INT y se especifica la referencia a la tabla y
columna apropiadas.
o Por cada referencia 1 a n en que la entidad est referenciada en otras
entidades (o en s misma) una columna cuyo nombre es: nombre de la tabla
referenciada + _ + nombre transformado de la propiedad que especifica
la referencia + _id.
o Por cada definicin de ndices nicos, una definicin UNIQUE con los
campos listados.
Por cada propiedad de tipo referencia n a m, una tabla adicional cuyo nombre se
conforma: nombre de la tabla perteneciente a la entidad donde se ha definido la
referencia + _ + nombre transformado de la propiedad que especifica la
referencia + _ + nombre de la tabla perteneciente a la entidad referenciada.
Esta tabla contiene dos columnas que conforman la clave primaria y cuyos
nombres son el nombre de la tabla de cada una de las entidades involucradas +
_id.

8.5.3.2. Generador de la Capa de Persistencia JPA
Genera todas las clases con anotaciones Java que sern persistidas, las clases que son
entidades voltiles, el archivo de configuracin para la Unidad de Persistencia, clases que
implementan el patrn DAO para cada entidad.
Las clases de las entidades implementan adems los valores auto-calculados y las
comprobaciones de datos vlidos al tratar de modificarlos. De esta manera la lgica bsica
del negocio funciona en cada instancia de las entidades an fuera de la aplicacin que
UMGnesis genera.


C
a
s
o

d
e

E
s
t
u
d
i
o

Nombre jpa
Tipo de Generador Capa de Mapeado Objeto Relacin
Descripcin Generador de Clases JPA
Lenguajes Java
Requerimientos Motor de Base de Datos: mysql
Parmetros Implementacin JPA (Hibernate es el nico valor
aceptado por ahora)
8.5.3.2.1. Estructura de las clases generadas
Este generador genera dos tipos de cdigo: uno que se sobrescribe con cada pasada de
generacin dentro de {ruta de destino}/src-gen y otro conjunto de clases
(generalmente las clases concretas) en {ruta de destino}/src. El ltimo grupo
no es sobrescrito en las pasadas sucesivas y es responsabilidad de los desarrolladores
mantenerlo actualizado o implementar las funcionalidades especficas que no se han
especificado en el modelo.
Teniendo en cuenta el siguiente modelo descrito en UMGnesis:
proyecto pruebas titulo "Pruebas del DSL"

entidad Persona
{
dni "DNI": cadena(8) mascara "\\d{8}"
nombre "Nombre": cadena = {""}
apellido "Apellido": cadena
nacimiento "Fecha de Nacimiento": fechahora
hijos "Hijos" -> Persona[]
unicos {dni, apellido}
}

entidad Producto
{
codigo "Cdigo" : cadena(6)
nombre "Nombre" : cadena(64)
descr "Descripcin" : texto
precio "Precio" : real validacion {precio >= 0}
fechaBaja "Fecha de Baja" : fechahora
unicos {codigo}
}

Juan Pablo Marzetti
153

C
a
s
o

d
e

E
s
t
u
d
i
o

entidad ItemFactura
{
producto "Producto" -> Producto
cantidad "Cantidad" : entero validacion {cantidad > 0}
precioUnitario "Px Unitario": real formula {producto.precio}
persistente
subtotal "Subtotal" : real formula {cantidad *
precioUnitario}
}

entidad Factura
{
numero "N" : entero = {maximo(numero)+1}
cliente "Cliente" -> Persona
fechaFactura "Fecha" : fechahora mascara "dd/mm/aaaa"
productos "Productos" -> ItemFactura[]
total "Total" : real formula {suma(productos.subtotal)}
unicos {numero}
}

El generador generar las siguientes clases con sus respectivas implementaciones:

Figura 27. Diagrama de Clases de las entidades generadas

C
a
s
o

d
e

E
s
t
u
d
i
o

Adems se implementan las clases que manejan el acceso, consulta y modificacin de
datos mediante el patrn DAO. A continuacin se muestra el diagrama de las clases
generadas:

Figura 28. Diagrama de Clases de los Controladores de Acceso a Datos 1

Juan Pablo Marzetti
155

C
a
s
o

d
e

E
s
t
u
d
i
o

Figura 29. Diagrama de Clases de los Controladores de Acceso a Datos 1

8.5.3.3. Generador para el framework Java Server Faces
Este generador genera dos tipos de cdigo: uno que se sobrescribe con cada pasada de
generacin dentro de {ruta de destino}/src-gen y otro conjunto de clases
(generalmente las clases concretas) en {ruta de destino}/src. El ltimo grupo
no es sobrescrito en las pasadas sucesivas y es responsabilidad de los desarrolladores
mantenerlo actualizado o implementar las funcionalidades especficas que no se han
especificado en el modelo.
Adicionalmente tambin genera las pantallas html, las plantillas y los archivos de
configuracin correspondientes a Java Server Faces dentro de {ruta de
destino}/Web Content.

C
a
s
o

d
e

E
s
t
u
d
i
o

Este generador se basa en el generador anterior y genera los siguientes artefactos de
software:
o Controladores (Beans) para cada uso. Los beans se crean por pares (una clase
abstracta que implementa la funcionalidad por defecto de UMGnesis para cada
uso y una concreta que extiende la anterior y permite que el desarrollador pueda
modificar las implementaciones)
o Sub-controladores para los editores anidados. stos aparecen en un uso de tipo
edicin o insercin cuando la entidad tiene referencias 1 a n o n a m.
o Una interfaz por cada servicio y una clase que la implementa (con los cuerpos de
los mtodos vacos)
o Pginas jsf con los elementos necesarios para mostrar los usos de tipos
predeterminados para los que UMGnesis genera una implementacin funcional.
El generador utiliza el framework de componentes de presentacin RichFaces y la
biblioteca para utilizar plantillas Facelets.
o Estructura de un proyecto Web JSF: web.xml, faces-confing.xml y un conjunto de
plantillas con estilos para la aplicacin.
Nombre jsfrf
Tipo de Generador Framework de Aplicaciones
Descripcin Generador para Java Server Faces - RichFaces
Lenguajes Java
Requerimientos Capa de Mapeado Objeto Relacin: jpa
Parmetros
8.5.3.3.1. Estructura de las clases generadas
Teniendo en cuenta el siguiente fragmento de cdigo de UMGnesis que define un uso de
tipo insercin sobre la entidad Factura:
uso InsertarFactura : insercion(Factura)
{
titulo "Agregar factura"
campos {numero, cliente, fechaFactura, productos, total}
usos {Ventas}
Juan Pablo Marzetti
157

C
a
s
o

d
e

E
s
t
u
d
i
o

servicios {Seguridad}
}

Las clases generadas son las siguientes:

Figura 30. Diagrama de Clases de un controlador (bean) para un uso

Para el caso de los servicios observamos el siguiente cdigo junto con la clase e interfaz
que se generan:
servicio Seguridad
{
usuarioActual(): Usuario
ingresar(usuario: cadena, clave : cadena) : Usuario
cerrarSesion(e: cadena)
tienePermiso(permiso: Permiso): logico
}


C
a
s
o

d
e

E
s
t
u
d
i
o

Figura 31. Diagrama de Clases de un servicio generado.
8.6. Ayuda de UMGnesis
Se ha desarrollado una breve documentacin de uso de UMGnesis junto con una gua
tutorial siguiendo el esquema de documentacin de Eclipse.
La documentacin generada est disponible en el centro de ayuda del entorno Eclipse
dentro del libro UMGnesis.
Juan Pablo Marzetti
159

C
a
s
o

d
e

E
s
t
u
d
i
o

Figura 32. Documentacin para Eclipse de UMGnesis
8.7. Datos Generales del Proyecto
El proyecto ha sido desarrollado utilizando el sistema de control de versiones CVS.
Adems los plug-ins ya compilados y empaquetados en archivos jar estn disponibles
junto con el cdigo fuente en el sitio del proyecto en souceforge.net
Sitio del Proyecto: https://sourceforge.net/projects/umgenesis/
Acceso a cdigo fuente:
Host: anonymous@umgenesis.cvs.sourceforge.net
Raiz: /cvsroot/umgenesis
Tipo: pserver
Juan Pablo Marzetti
161

C
o
n
c
l
u
s
i
o
n
e
s

9. Conclusiones
A la luz de los objetivos planteados al inicio del proyecto puede afirmarse que se han
logrado cumplir satisfactoriamente.
En cuanto al primer y segundo objetivos planteados para el presente trabajo se ha
investigado sobre la metodologa denominada Ingeniera Dirigida por Modelos. El universo
de herramientas, conceptos y trabajo desarrollado sobre la misma es vasto. Por ello, el
presente trabajo no ha agotado la investigacin sino que sirve como punto de partida
orientndose en un tema dentro de este universo.
MDE proporciona una amplia gama de posibilidades para encarar el desarrollo de
software desde un enfoque ingenieril teniendo en cuenta no solo el aspecto del desarrollo
sino tambin el aspecto de los costos, la vigencia de los productos desarrollados y la
productividad del equipo de desarrollo. Dentro de estas propuestas se encuentra la propia
del OMG denominada MDA que ha podido ser estudiada en el contexto de este trabajo.
MDA constituye una versin reducida (podra decirse un subconjunto) de MDE ya que
encara el problema del desarrollo slo desde el problema de las diferentes arqui tecturas y
plataformas (conceptos altamente ligados a la tecnologa) mientras que MDE incorpora
adems otras dimensiones como autora, aspectos del sistema, diferentes usuarios,
interesados, etc.
Finalmente se han podido cumplir los objetivos de estudiar un caso concreto para el que
pueda aplicarse MDE y se ha desarrollado un lenguaje (DSL) y una herramienta que
soportan la necesidad planteada.
A continuacin se detalla la conclusin del estudio terico de los temas planteados para
este proyecto final. Luego se comenta cules han sido las conclusiones y la experiencia
obtenida en el desarrollo de UMGnesis. Finalmente se proponen algunas lneas de
investigacin y aplicacin sobre el tema elegido.


C
o
n
c
l
u
s
i
o
n
e
s

9.1. Ingeniera dirigida por Modelos
El objetivo de la Ingeniera dirigida por Modelos es incrementar paralelamente la
productividad en el corto plazo largo plazo. Para alcanzar este objetivo es necesario
encarar el proceso de desarrollo del software utilizando un enfoque ingenieril como el que
MDE plantea. Dentro de su naturaleza (el desarrollo basado y dirigido por modelos) se
plantea la necesidad de establecer dimensiones adicionales a la dimensin
abstracto/concreto planteada por MDA.
Los modelos slo constituyen una especificacin de lo que es requerido. Es necesario un
proceso de ingeniera para obtener y mantener un sistema de software a partir de los
mismos. Este proceso involucra diferentes mtodos de desarrollo y una secuencia de
pasos a seguir. Desde un punto de vista macroscpico tenemos el proceso que describe el
orden en que los modelos son creados, compuestos y transformados (secuencia de pasos)
el cual puede llegar a ser muy complejo. Desde el punto de vista microscpico tenemos los
lineamientos y herramientas utilizados en la creacin de cada modelo. Entre estas ltimas
se encuentran los Lenguajes Especficos de Dominio.
El modelado especfico de dominio tiene como propsito crear modelos para un dominio
utilizando un lenguaje enfocado y especializado. Incluye la idea de generacin automtica
de cdigo ejecutable directamente desde los modelos, para que las aplicaciones finales
puedan ser generadas a partir de estas especificaciones en alto nivel.
Puede utilizarse DSL existentes o crear uno que se ajuste al dominio del problema con el
que se trabaja. El crear un DSL involucra varios aspectos: establecer su sintaxis abstracta y
concreta, implementar un analizador y compilador, implementar un generador de cdigo
que tome el modelo especificado por el DSL y genere el cdigo de la aplicacin.
Un DSL ofrece diversas ventajas importantes sobre un GPL:
Los DSL se construyen e involucran conocimiento del dominio y por ende permite
la conservacin y reutilizacin de este conocimiento.
Juan Pablo Marzetti
163

C
o
n
c
l
u
s
i
o
n
e
s

Los DSL constituyen una solucin que aborda la complejidad del desarrollo de
software permitiendo utilizar un lenguaje que sea entendible por los
desarrolladores y los expertos del dominio.
Liberan a los desarrolladores de la tarea de codificacin y mantenimiento del
cdigo fuente incrementando significativamente su productividad.
Al reducir la cantidad de lneas codificadas manualmente, se reduce drsticamente
los errores y defectos.
Es necesario mencionar que los beneficios anteriormente descritos no se obtienen
gratuitamente. El desarrollo de un DSL es una tarea difcil y requiere experiencia sobre el
dominio y sobre el desarrollo de lenguajes. Por otro lado el desarrollo de material de
entrenamiento, soporte para el lenguaje, estandarizacin y mantenimiento puede llevar
mucho tiempo si no se cuenta con un equipo de trabajo razonable y una comunidad de
usuarios importante.
De lo anteriormente dispuesto surge la conclusin que un DSL puede ser de gran ayuda en
el abordaje de proyectos grandes que consuman mucho tiempo y trabajo para mejorar la
productividad de un equipo de desarrollo y la vigencia del software generado. Otro caso
donde es importante la utilizacin de DSL es cuando los proyectos que se abordan
pertenecen al mismo dominio (y son varios) o a reas de conocimiento similares bajo las
cuales se pueda construir un DSL sin caer en el error de construir uno de uso general.
9.2. Desarrollo de UMGnesis
El desarrollo de UMGnesis ha sido una tarea muy grata aunque ardua. Luego del estudio
del marco terico se conceptualiz la idea del lenguaje a partir de la experiencia
mencionada como motivacin del presente trabajo. Dicha definicin llevo varias revisiones
que fueron modificando la sintaxis (sobre todo abstracta) hasta la versin final.
El trabajo de desarrollo, prueba y revisin fue facilitado enormemente por el uso del
framework de Xtext. Si se considera que ste genera todo el cdigo necesario para el

C
o
n
c
l
u
s
i
o
n
e
s

editor, el analizador y el compilador, el hacer todo este proceso de forma manual hubiera
sido muy costoso.
Xtext provee una forma de trabajo y la arquitectura e implementaciones necesarias para
desarrollar un producto de calidad que se integra perfectamente con el entorno Eclipse
permitiendo rpidamente desarrollar un DSL. Estos beneficios disminuyen en parte uno de
los puntos negativos mencionados en las conclusiones referentes al desarrollo de
lenguajes especficos de dominio.
El desarrollo ms importante de UMGnesis se dio en el mbito de los generadores y la
arquitectura del sistema de generacin de cdigo. Se ha desarrollado de manera que sea
fcil y simple la implementacin de nuevos generadores permitiendo una gran flexibilidad
en el proceso de generacin de cdigo.
Los generadores se implementaron como fragmentos del plug-in de generacin de cdigo.
Esto otorga una gran facilidad de uso e instalacin de los generadores que son detectados
automticamente por el sistema de generacin de cdigo y habilitados para su uso.
Finalmente el trabajo de desarrollo de UMGnesis llev el estudio y adquisicin de
habilidades en todo lo referente a la plataforma para la que se genera cdigo as como
tambin del entorno Eclipse para el cual se estudi su sistema de complementos, sistema
grfico, framework de tareas programadas y sistema de documentacin.
9.3. Lneas futuras de investigacin y aplicacin
El campo del desarrollo y la ingeniera dirigida por modelos es vasto y muy reciente.
Existen herramientas, pero son pocas y no siempre adecuadas, para llevar a cabo los
procesos de desarrollo que plantea la metodologa.
El estudio que involucr el presente informe ha dejado abiertas diversas lneas de
investigacin y aplicacin:

Juan Pablo Marzetti
165

C
o
n
c
l
u
s
i
o
n
e
s

Lneas de investigacin:
o Estudio de aplicacin: consiste en estudiar cmo el proceso de ingeniera
dirigida por modelos mejora la productividad en el equipo de desarrollo.
o Arquitectura estandarizada para el desarrollo dirigido por modelos: Entre
los principios funcionales de la arquitectura a disear se encuentran: los
lenguajes especficos de dominio y las validaciones de modelo asociadas.
Entre los principios constructivos estn: generadores de cdigo o
intrpretes.
o Modelado de la Ontologa de una Empresa: consiste en el modelado de la
esencia de la organizacin en una forma coherente, comprensiva y
consistente.
Lneas de aplicacin:
o Implementar una sintaxis grfica para UMGnesis: Eclipse posee un
framework denominado Graphical Modeling Framework que permite
construir editores grficos para un metamodelo Ecore.
o Implementar un generador para otra plataforma
o Implementar una etapa intermedia: Implementar una etapa intermedia en
el proceso de generacin de cdigo para generar un modelo abstracto y
uno concreto de la aplicacin generada.

Juan Pablo Marzetti
167

B
i
b
l
i
o
g
r
a
f
a

10. Bibliografa
1. Kent Stuart (2002). Model Driven Engineering. Springer.
2. Budinsky Frank, Steinberg David, Merks Ed, Ellersick Ray, Grose Timothy. Eclipse
Modeling Framework (EMF). Addison Wesley Professional.
3. Atkinson Colin y Khne Thomas (2003). Model-Driven Development: A
Metamodeling Foundation. IEEE Software.
4. Atkinson Colin y Khne Thomas (2001). Processes and products in a multi-level
metamodeling architecture. International Journal of Software Engineering and
Knowledge Engineering.
5. OMG (2002) MetaObjectFacility (MOF) Specification 1.4
6. OMG (2003). MDA Guide Version 1.0.1. http://www.omg.org/mda
7. OMG (2006) Object Constraint Language 2.0
8. OMG (2007). OMG Unified Modeling Language.
9. Den Haan Joan (2008). http://www.theenterprisearchitect.eu: Model Driven
Engineering
10. Den Haan Joan (2009). http://www.theenterprisearchitect.eu: MDE - Model
Driven Engineering - reference guide
11. Den Haan Joan (2008). http://www.theenterprisearchitect.eu: MDA, Model
Driven Architecture, basic concepts
12. Den Haan Joan (2008). http://www.theenterprisearchitect.eu: Combining general
purpose languages and domain specific languages for Model Driven Engineering
13. Den Haan Joan (2008). http://www.theenterprisearchitect.eu: DSL and MDE,
necessary assets for Model-Driven approaches
14. Eclipse Foundation. Eclipse IDE. http://www.eclipse.com/
15. Eclipse Foundation. Eclipse Modeling Framework. http://www.eclipse.com/emf/.
16. Eclipse Foundation. Graphical Modeling Framework.
http://www.eclipse.com/gmf/
17. Eclipse Foundation. Xtext. http://www.eclipse.com/xtext/

B
i
b
l
i
o
g
r
a
f
a

18. Eclipse Foundation. Xtext Documentation.
http://www.eclipse.org/Xtext/documentation/0_7_2/xtext.html
19. Eclipse Foundation. Platform Plug-in Developer Guide.
http://help.eclipse.org/galileo/index.jsp
20. Eclipse Foundation. Plug-in Development Environment Guide.
http://help.eclipse.org/galileo/index.jsp
21. openArchitechtureWare. openArchitectureWare 4.3.1 Manual.
http://www.openarchitectureware.org/pub/documentation/4.3.1/html/contents/
22. Fowler Martin (2005). Language Workbenches: The Killer-App for Domain Specific
Languages?
23. Andino Luciano Omar y Ruiz Germn Estban (2009). Anlisis y uso de los
frameworks de Eclipse para la definicin de DSLs. Universidad Nacional de La Plata.
24. Burcio Mnica (2009). Definidor Visual Bajo Eclipse Europa. Universidad Carlos III
de Madrid.
25. Hibernate, https://www.hibernate.org
26. (RAE 2001) Real Academia Espaola, Diccionario de la Lengua Espaola 22 Edicin
(2001)
27. HUMAN PERFORMANCE CENTER (HPC), Arquitectura de Software, (2002).
https://www.spider.hpc.navy.mil/index.cfm?RID=TTE_OT_1000025

UMGenesis PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

UMGenesis PDF

Cargado por

Copyright:

Formatos disponibles

Universidad de Mendoza

También podría gustarte