1. HERRAMIENTA CASE PARA MODELADO DE
ALMACENES DE DATOS BASADA EN LENGUAJES
ESPECÍFICOS DE DOMINIO
AUTORES:
ENRIQUE CATALA BAÑULS
VICENTE SORIANO CLAVER
TUTOR:
JUAN CARLOS TRUJILLO MONDEJAR
DEPARTAMENTO:
DPTO. DE LENGUAJES Y SISTEMAS INFORMÁTICOS
CURSO:
2005-2006

2. Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de Enrique Catalá Bañuls y Vicente Soriano Claver
Año académico 2005-2006
2
ÍNDICE
ÍNDICE................................................................................................................ 2
DSL Tools........................................................................................................... 4
¿Qué son y para qué sirven?.......................................................................... 4
Software Factories y MDA............................................................................... 4
Proceso de desarrollo ..................................................................................... 5
Modelo de dominio (DomainModel) ................................................................ 6
Diseñador gráfico (Designer) .......................................................................... 8
Plantillas de generación de código................................................................ 10
Compilación .................................................................................................. 11
Ejecución....................................................................................................... 11
Ejemplo sencillo ............................................................................................ 12
I. Gestión del proyecto...................................................................................... 17
Planificación.................................................................................................. 17
Proceso de desarrollo ................................................................................... 21
Diagrama de Gantt .................................................................................... 22
Repositorio.................................................................................................... 23
Gráfico de revisiones................................................................................. 24
Sincronización con el repositorio ............................................................... 26
Estadísticas de desarrollo.......................................................................... 27
Versiones estables por hito ....................................................................... 29
II. Lenguaje específico de dominio para modelado multidimensional ............... 30
Modelo de dominio........................................................................................ 30
Esquema conceptual ................................................................................. 30
Hacia un modelo compilable...................................................................... 33
Atributos embebidos .............................................................................. 33
Relaciones en el modelo........................................................................ 35
Errores de compilación .......................................................................... 38
Esquema definitivo .................................................................................... 42
Conectores............................................................................................. 42
La clase DegenerateFact...................................................................... 44
Conector del DegenerateFact ................................................................ 48
Esquema final del Modelo de Dominio................................................... 50
Interfaz de usuario ........................................................................................ 52
Clases y formas......................................................................................... 53
Conectores entre clases............................................................................ 55
Problemas encontrados............................................................................. 58
Cambio de iconos en la Toolbox............................................................ 58
Etiquetas en los conectores (Text Decorators) ...................................... 59
Iconos en las Compartment Shapes ...................................................... 60
Iconos transparentes.............................................................................. 63
Restricciones y validaciones ......................................................................... 63
Archivos de recursos ................................................................................. 64

3. Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de Enrique Catalá Bañuls y Vicente Soriano Claver
Año académico 2005-2006
3
Soft Constraints ......................................................................................... 66
Añadir cardinalidades en las relaciones................................................. 68
Restricciones de la clase Base .............................................................. 71
Restricciones de los conectores del DegenerateFact ............................ 74
Atributos derivados ................................................................................ 75
Hard Constraints........................................................................................ 77
AggregationConnector ........................................................................... 79
AssociationConnector ............................................................................ 81
BaseAssociatesBaseConnector............................................................. 84
BaseInheritsBaseConnector .................................................................. 86
DegenerateFactConnector..................................................................... 88
Library.................................................................................................... 90
Mensajes de error...................................................................................... 93
Lista de errores original (modelo de la Universidad de Alicante) ........... 93
Lista de errores del proyecto.................................................................. 96
Menú de comandos..................................................................................... 102
Cambios en el CommandSet................................................................... 103
Ficheros embebidos como recursos........................................................ 105
Cuadros de diálogo.................................................................................. 110
Modelo Estrella .................................................................................... 111
Modelo SnowFlake............................................................................... 114
Modelo Oracle WarehouseBuilder ....................................................... 119
III. Generación de código................................................................................ 121
Modelo de generación de código ................................................................ 121
Introducción............................................................................................. 121
Descripción del proceso de procesamiento de los diagramas OOMM .... 123
Tipos de datos implicados en la generación de código ........................... 135
Enumeración MotorBBDD.................................................................... 135
Clase TClaveAjena .............................................................................. 136
Clase MetodosBase............................................................................. 138
Clase Validacion .................................................................................. 141
Clase Tcolumna ................................................................................... 152
Clase TTabla........................................................................................ 153
Clase TTablaMultidimensional ............................................................. 174
Especificación del motor de BBDD destino de la generación de código . 184
Extensión de nuevos motores de BBDD destino ..................................... 185
Modelo de validación del generador de código........................................... 189
Generación de código ................................................................................. 190
Generación de código SQL Estrella......................................................... 195
Generación de código SQL Snowflake.................................................... 204
Generación de código Oracle Warehouse Builder................................... 216
Detector de palabras reservadas ................................................................ 223
Abstracción de tipos de datos ..................................................................... 225
BIBLIOGRAFÍA............................................................................................... 228

4. Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de Enrique Catalá Bañuls y Vicente Soriano Claver
Año académico 2005-2006
4
DSL Tools
¿Qué son y para qué sirven?
Un Lenguaje Específico de Dominio (Domain-Specific Language, o DSL) es un
lenguaje diseñado para realizar una determinada tarea o para resolver un problema
específico, en contraste con los lenguajes de propósito general (C#, Java…). Al usar
lenguajes específicos de dominio, se pueden construir herramientas de modelado
personalizadas y, básicamente, diseñar un nuevo lenguaje de modelado e implementarlo de
una forma muy sencilla. Por ejemplo, un lenguaje específico puede usarse para describir
una interfaz de usuario, un proceso de negocio, una base de datos o un flujo de
información, y después, a partir de estas descripciones, ser usado para generar código.
Las Domain-Specific Language Tools (a partir de ahora, DSL Tools) o
herramientas para construir DSLs, pueden ser usadas para construir herramientas de diseño
personalizadas, adaptadas a cualquier problema. Por ejemplo, se puede crear una
herramienta de modelado para un proceso de negocio usando las DSL Tools, para describir
así determinados conceptos de cómo funcionan los modelos de negocio de tu organización.
Si estás construyendo una herramienta para representar diagramas de estados, puedes
describir qué es un estado, las propiedades que tiene un estado, qué tipos de estados
existen, cómo están definidas las transiciones entre estados, etc. Un diagrama de estado
usado para describir el estado de los contratos en una compañía de seguros y otro para
especificar la interacción del usuario entre las páginas de un sitio Web son
superficialmente similares, pero los conceptos subyacentes que representan son totalmente
distintos. Creando una herramienta de diseño personalizada, se puede especificar
exactamente la definición de los conceptos del diagrama de estado que se necesitan para
dicha herramienta.
Software Factories y MDA
En los últimos años, han surgido dos principales metodologías que siguen el
paradigma de desarrollo software dirigido por modelos: la Model Driven Architecture
(MDA) y las Software Factories. La MDA es una propuesta del Object Management
Group (OMG) y es una de las aproximaciones más divulgadas en la comunidad científica
por su estado de madurez. Por otro lado, una aproximación más reciente y que está
teniendo un gran impacto es la denominada Software Factories, propuesta por Microsoft.
El término MDA se refiere a un enfoque sobre el desarrollo dirigido por modelos
basado en el uso de tecnologías de modelado del OMG, haciendo especial hincapié en el
Lenguaje de Modelado Unificado (UML - Unified Modeling Language) y en el Servicio
para Meta-Objetos (MOF – MetaObjects Facility). La esencia de MDA consiste en hacer
una distinción entre los modelos de plataforma independiente (PIMs – Platform
Independent Models) y los modelos de plataforma específica (PSMs - Platform Specific
Models). Para desarrollar una aplicación con MDA es necesario primero construir un PIM
de la aplicación, luego transformarlo a un PSM usando un mapeado estandarizado para así,
finalmente, obtener de este último el código de la aplicación.

5. Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de Enrique Catalá Bañuls y Vicente Soriano Claver
Año académico 2005-2006
5
Las fábricas de Software utilizan conocimientos de dominio específicos,
arquitecturas de solución, herramientas y otros activos reutilizables para ayudar a sus
usuarios a producir tipos específicos de soluciones de software. Una fábrica de Software se
basa en tres puntos claves:
 Un sistema para la fábrica de software.
 Una plantilla para la fábrica de software
 Un entorno de desarrollo extensible.
La fábrica de software configura el entorno de desarrollo extensible, como por
ejemplo Eclipse, Borland Jbuilder o Microsoft Visual Studio Team System (VSTS),
utilizando un paquete de instalables llamado plantilla de la fábrica de software o paquete
de instrucciones. Si se configura de esta forma, el entorno de desarrollo se vuelve una
utilidad especializada que acelera el desarrollo de un tipo específico de solución de
software, como una interfaz del usuario o una capa de acceso a una base de datos, o tal vez
toda una aplicación en un dominio empresarial como por ejemplo el cuidado de la salud o
la seguridad nacional.
La plantilla de la fábrica de software se organiza por medio de un modelo llamado
sistema de la fábrica de software. El sistema define uno o más puntos de vista que son
relevantes para las partes interesadas en la producción de la solución de software deseada.
Cada punto de vista define artefactos del ciclo de vida producidos o consumidos por los
interesados, las actividades que ellos realizan con estos artefactos y los bienes reutilizables
disponibles para soportarlos al realizar estas actividades. La metodología de la fábrica de
software integra el Desarrollo Orientado por un Modelo (MDD – Model Driven
Development), el Desarrollo Basado en el Componente (CBD – Component-Based
Development) y las prácticas de desarrollo ágil, incluyendo el uso de patrones y lenguaje
de patrones con modelos, marcos y Herramientas (Ver “Recursos”).
Para nivelar los modelos de forma efectiva para las varias formas de
automatización, las fábricas de software hacen gran uso de los lenguajes específicos de
dominio. La tecnología DSL es mucho más nueva que varias de las otras tecnologías
utilizadas en las fábricas de software, y depende de familias de lenguajes extensibles. Sin
embargo, los marcos y herramientas de creación del DSL han estado en desarrollo por
algún tiempo en los grupos académicos, y han comenzado a aparecer recientemente en
forma comercial (como las DSL Tools).
Proceso de desarrollo
Para llevar a cabo un proyecto guiado por las DSL Tools hay que tener en cuenta un
proceso de desarrollo necesario para cada nuevo proyecto. Dicho proceso no es secuencial,
hay una serie de pasos que se repiten y a los que se vuelve atrás a fin de ir avanzando en el
desarrollo del modelo. Dichos pasos se pueden esquematizar de la siguiente forma:

6. Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de Enrique Catalá Bañuls y Vicente Soriano Claver
Año académico 2005-2006
6
Lo primero es crear un nuevo proyecto DSL, seleccionando File, New, Project…, y
en la parte de Other Project Types, Extensibility buscar el Domain Specific Language
Designer.
El cuadro central se refiere a la creación del lenguaje de dominio. Se compone de
dos partes, la definición del modelo de dominio y la del diseñador gráfico. Ambas partes se
realizan de forma paralela, se debe estar sincronizándolas conforme avanzamos para crear
así un lenguaje válido.
Cada vez que creamos un doblete Modelo de dominio – Diseñador Gráfico
consistente, debemos después transformar los templates, depurar y/o ejecutar el código,
modelar el nuevo lenguaje creado en la ventana de depuración del Visual Studio y, por
último, escribir las plantillas de generación de código para ese lenguaje.
Una vez acabado se puede volver a definir el DSL, depurar, modelar y generar
código, así hasta que se logre el lenguaje específico de dominio que se anda buscando.
Modelo de dominio (DomainModel)
Un proyecto dirigido por las DSL Tools se divide en dos partes fundamentales,
aunque muy relacionadas. La primera de ellas consiste en crear un modelo del lenguaje o
metamodelo. De forma esquemática, se pretende mostrar el funcionamiento que va a tener
nuestro lenguaje específico de dominio. Para ello se utilizan conceptos ya conocidos, como
relaciones, herencia, clases, propiedades… El fichero que guarda este modelo es el
DomainModel.dsldm, contenido en el proyecto DomainModel.

7. Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de Enrique Catalá Bañuls y Vicente Soriano Claver
Año académico 2005-2006
7
La figura básica del modelo es la clase. Con las clases podemos representar
cualquier elemento significativo de nuestro lenguaje (un diagrama, un cuadro de diálogo de
un asistente, un atributo de otra clase…). Dichas clases pueden estar compuestas de
propiedades. Estas propiedades pueden ser de los tipos de datos más comunes: String,
Boolean, Int32, Int64, Double… También se pueden definir tipos de datos enumerados y
tipos de datos simples. Para visualizar las propiedades de una clase, debemos desplegar el
símbolo + que se encuentra más a la derecha de la clase. Tanto clases como propiedades se
dibujan arrastrando los elementos Class y Value Property de la Toolbox.
La clase que aparece con una X significa que es la raíz del modelo, y es de donde
deben derivar el resto de clases. Si una clase no está relacionada con la clase raíz no podrá
mostrarse posteriormente en la pantalla del diseñador.
Tenemos tres tipos de relaciones entre clases:
- Embedding: relaciones embebidas. Significa que una clase contiene a otra, o
que un concepto está formado por otro. Normalmente se suele utilizar para
establecer atributos dentro de las clases (ya que es necesario que sea una
Embedding relationship para que luego se pueda representar gráficamente de
esa manera). Representada por una línea continua.
- Reference: referencias entre clases. Simplemente es una relación entre dos
conceptos (A se relaciona con B). Representada por una línea discontinua.
- Inheritance: relaciones de herencia entre clases. Aquí existe una clase padre, y
una clase hija que hereda las propiedades del padre (y que contendrá además las
suyas propias). Se representa por una flecha que apunta al padre.

8. Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de Enrique Catalá Bañuls y Vicente Soriano Claver
Año académico 2005-2006
8
Todas ellas menos la relación de herencia se pueden representar a parte en el
esquema seleccionando la clase con el botón derecho y dándole a la opción “Show As
Class”. Las clases que representan relaciones se muestran en color rojo oscuro. Así le
podemos asignar también propiedades a las relaciones e incluso relacionarlas con otras
clases.
El triángulo y el rectángulo encima de las relaciones indican los roles y las
cardinalidades en ambos sentidos. Para el triángulo el sentido en que se lee es el que
indica, de izquierda a derecha, y para el rectángulo el sentido contrario. El texto que
aparece encima de la relación pertenece al nombre del role del triángulo. Para saber el
nombre del role rectángulo y el de la relación hay que seleccionarlos y mirar en la ventana
de propiedades.
Poniendo como ejemplo la figura anterior y las distintas cardinalidades que le
podemos asignar al role ‘Pages’, representado como el triángulo en la imagen, vamos a
explicar el significado de cada cardinalidad y cómo obtenerla (valores max y min en la
ventana de propiedades):
- 1 (max=1, min=1)  Una PageFlow debe tener exactamente una única Page.
- 0 (max=1, min=0)  Una PageFlow puede tener como mucho un Page (esto es,
o 0 o 1).
- + (max=0, min=1)  Una PageFlow debe tener 1 o más Pages.
- * (max=0, min=0)  Una PageFlow puede tener 0, 1 o más Pages.
Este significado se puede intuir con las relaciones máximo-mínimo. Para el caso de
0 y 1 es tal y como se supone: max y