Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
HERRAMIENTA CASE PARA MODELADO DE
ALMACENES DE DATOS BASADA EN LENGUAJES
ESPECÍFICOS DE DOMINIO
AUTORES:
ENRIQUE CATALA BA...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificación del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos
Proyecto de fin de carrera de E...
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO
Upcoming SlideShare
Loading in …5
×

HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO

Memoria de mi proyecto de fin de carrera. Herramienta CASE para modelado de almacenes de datos multidimensionales mediante la creación de un Domain Specific Language al que llamamos ObjectOrientedMultimensionalModel (OOMM)

  • Login to see the comments

  • Be the first to like this

HERRAMIENTA CASE PARA MODELADO DE ALMACENES DE DATOS BASADA EN LENGUAJES ESPECÍFICOS DE DOMINIO

  1. 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. 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. 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. 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. 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. 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. 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. 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 min expresan sus correpondientes valores máximo y mínimo. Para el caso de + y * es igual si pensamos que max=0 tiene el sentido de muchos. Diseñador gráfico (Designer) La segunda parte de la que se compone un proyecto con las DSL Tools es la del diseñador gráfico. Es la parte que relaciona los elementos del Domain Model con sus correspondientes en el entorno gráfico. El fichero principal que contiene todas las definiciones es el Designer.dsldd, contenido en el proyecto Designer.
  9. 9. 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 9 Dicho fichero contiene el código XML con todas las definiciones necesarias. Pero resulta algo complicado editarlo, porque la documentación es escasa y el código complicado. Afortunadamente una empresa (Modelisoft) creó una aplicación llamada DslDm2Dd para sincronizar el DomainModel.dsldm con el Designer.dsldd de forma gráfica y de manera muy intuitiva. Al instalarse la herramienta se puede arrancar directamente desde el entorno de Visual Studio seleccionando Tools/DslDm->Dd. A la izquierda se encuentran los elementos del Domain Model, y a la derecha sus correspondientes en el Designer. Las rayas rojas indican los que están relacionados entre sí. Si existe alguna incompatibilidad, aparecerá un mensaje de aviso en la ventana de abajo. Normalmente las clases en el Domain Model se corresponden con las Shapes en el Designer, y las RelationShip con los Connectors. En el ejemplo de la figura, ExampleClass se corresponde con ExampleShape; y ExampleRelation con ExampleConnector. Para editar las Shapes o los conectores basta con seleccionarlos y darle al botón derecho y ‘Edit’. Si tenemos un elemento en el Domain Model que aun no está relacionado con nada, para crear una nueva Shape o Connector habrá que seleccionarlo y arrastrarlo hasta la raíz de la parte del Designer. Enseguida aparecerá el asistente que nos ayudará en el proceso.
  10. 10. 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 10 Si una clase está embebida por otra, poder mostrar en el Designer esa clase como un atributo de la segunda. Para ello, al editar la clase principal hay que seleccionarla como Compartment Shape, y en la parte donde te piden los Compartments of the shape, añadir un nuevo compartment dándole al símbolo + y seleccionar la clase del desplegable melCollection Expression. Una vez acabado la edición, hay que guardar los cambios, cerrar la aplicación y volver al entorno del Visual Studio. Plantillas de generación de código Los ficheros del DomainModel.dsldm y el Designer.dsldd una vez definidos son utilizados para generar otro código. Ese es el código que será la base de nuestro lenguaje de dominio. Para generarlo y saber si hemos hecho todo correctamente, debemos darle al botón que se encuentra a la derecha de la ventana del Solution Explorer llamado “Transform All Templates”. Si no aparece ningún error, el Domain Model y el Designer estarán sincronizados correctamente. También existe otro tipo de ficheros que generan código. Son aquellos que podemos encontrar con extensión *.dslddt para el proyecto del Designer y *.dsldmt para los del Domain Model. Son ficheros templates, y si nos fijamos todos ellos tienen un archivo anidado, que corresponde al código que generan. Para generar dicho código se puede seleccionar el archivo de generación con el botón derecho y pinchar en “Run Custom Tool”. Esta Custom Tool está especificada en la ventana de propiedades del archivo, normalmente con valor TextTemplatingFileGenerator. Estos ficheros también generan su código cuando le damos al botón “Tranform All Templates”.
  11. 11. 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 11 Del mismo modo se pueden definir templates que generen código para el lenguaje específico de dominio final. Se pueden añadir en el proyecto destino, y utilizarlos de la misma manera que los anteriores. Pueden llevar extensiones como *.t4 o *.ReportTemplate. Compilación Una vez creado el lenguaje DSL y generados todos los templates correctamente, pasamos a depurar o ejecutar el código. Para ello no hay más que darle a F5 o al botón en forma de rectángulo verde en el entorno del Visual Studio. Al lado de dicho botón podemos seleccionar si queremos ejecutarlo en modo depuración o en modo release. Normalmente cuando se desarrollo un proyecto se ejecuta siempre en modo depuración. El release se usará cuando se esté desarrollando el instalador, para la versión final del proyecto. El hecho de que hayamos generado todos los templates correctamente no significa que el modelo sea correcto. Podemos encontrarnos errores debidos a otras circunstancias, como por ejemplo que hayamos introducido algunos nombres con espacios en blanco que posteriormente son transformados en variables. Habrá que estar atentos a los mensajes que nos aparezcan en la ventana de errores para poder solucionarlos. Ejecución Cuando conseguimos ejecutar el proyecto DSL, surgirá una nueva instancia de Visual Studio con un nuevo proyecto abierto, que corresponderá a nuestro lenguaje de dominio creado. En la ventana de la solución veremos los archivos incluidos en él. Algunos deben tener la extensión que decidimos que tendrían los archivos que representarían el nuevo lenguaje al crear el proyecto DSL. Si abrimos algunos de estos archivos, aparecerá la ventana del diseñador y un menú a la izquierda con las herramientas que podemos incluir en el: formas, conectores, etc.
  12. 12. 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 12 Para modelar simplemente habrá que arrastrar estos elementos de la Toolbox al campo de trabajo. Dependiendo de las cardinalidades y las restricciones que hayamos definido, se podrán conectar o no los elementos entre sí. Del mismo modo, podremos encontrarnos con errores de modelado si así se ha especificado con anterioridad. Al acabar de modelar, se podrá generar código a partir de nuestro modelo con aquellos archivos incluidos en el proyecto destinados para ese fin dándole al botón de Transform All Templates. Ejemplo sencillo Vamos a ver de forma rápida como crear un lenguaje específico de dominio para modelar tablas relacionales y generar su código sql correspondiente. Creamos un nuevo proyecto DSL Designer con nombre “LenguajeRelacional” a partir del Minimal Language. Le ponemos como nombre del lenguaje también “LenguajeRelacional”, el Namespace “UA.EjemploDSL.LenguajeRelacional” y la extensión “rlc”.
  13. 13. 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 13 Abrimos el fichero DomainModel.dsldm. La raíz del proyecto se llamará ModeloRelacional, estará formado por Tablas que a su vez estarán formadas por Atributos y por una Clave Primaria. Las tablas podrán relacionarse entre sí por claves ajenas. Para crear el modelo de dominio empezamos haciendo un “Replace All” de ExampleModel por ModeloRelacional, y otro de ExampleClass por Tabla. Reemplazamos los nombres necesarios en clases y conectores, y añadimos las relaciones embebidas para Atributo y Clave Primaria. Hay que asegurarse de que el rol triángulo de las relaciones embebidas tenga su propiedad Accepts a “All”. También le quitamos a Tabla la propiedad ExampleProperty y añadimos a Atributo la propiedad Tipo.
  14. 14. 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 14 Le damos al botón de “Transform All Templates” y ejecutamos el DslDm2Dd para sincronizar con el diseñador. Editamos el ExampleShape y el ExampleConnector a fin de cambiarles el nombre y sincronizarlos con Tabla y RelacionClavesAjenas. TablaShape será una CompartmentShape, que tendrá embebidas las clases Atributo y Clave Primaria. Salvamos el fichero y volvemos al Visual Studio. Volvemos a darle al botón de “Transform All Templates” y depuramos. Si todo ha ido bien, se abrirá una nueva ventana de Visual Studio donde podremos modelar tablas relacionales.
  15. 15. 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 15 Además, podemos incluir un fichero en el proyecto final que genere código sql para cualquier modelo que dibujemos. Para ello le damos al botón derecho en el proyecto LenguajeRelacionalDebugging y escogemos Add.. NewItem. Le llamamos GeneraSQL.ReportTemplate y añadimos el siguiente código: <#@ template inherits= "Microsoft.VisualStudio.TextTemplating.VSHost.ModelingTextTransformation"#> <#@ output extension=".sql" #> <#@ ModeloRelacional processor="LenguajeRelacionalDirectiveProcessor" requires="fileName='Test.rlc'" provides="ModeloRelacional=ModeloRelacional" #> <# foreach(Tabla tabla in this.ModeloRelacional.Elementos) { #> Create Table <#=tabla.Name#> ( <# foreach(Atributo atributo in tabla.atributos) { #> <#=atributo.Name#> <#=atributo.Tipo#> <# } foreach(ClavePrimaria cp in tabla.cp) { #> PrimaryKey <#=cp.Name#> <# } #>) <# } #> Añadimos en la propiedad Custom Tool del fichero el texto “TextTemplatingFileGenerator” y así veremos como se crea un fichero llamado GeneraSQL.sql con el siguiente código: Create Table Tabla1 ( Atributo1 String Atributo2 Int PrimaryKey CP1 )
  16. 16. 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 16 Create Table Tabla2 ( Atributo3 Float PrimaryKey CP2 ) Que se generará automáticamente a partir del modelo contenido en el fichero “Test.rlc”. Finalmente, y tan solo como nota aclaratoria, hemos de decir que en este apartado no se ha pretendido plasmar el modelo relacional por completo. Simplemente lo hemos utilizado como ejemplo para mostrar las posibilidades que nos ofrecen las DSL Tools.
  17. 17. 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 17 I. Gestión del proyecto Planificación Para la planificación del proyecto hemos utilizado Microsoft Proyects puesto que al ser dos personas no necesitábamos sistemas de planificación más avanzados y porque nos ofrecía lo que necesitábamos, que era la planificación de requerimientos entre tareas, la asignación de requisitos para llevarlas a cabo y la planificación de fechas. Esto añadido a la posibilidad de realizar diagramas de gantt de forma automática nos hizo decidirnos. Pese a que realizamos un primer estudio de la planificación de tareas que tenían que ser llevadas a cabo, a medida que avanzábamos en los conocimientos sobre las DSL Tools nos dimos cuenta que había que cambiar la planificación para adaptarla a la forma de programación del modelo y la generación de código. De esta forma podremos ver mas adelante como algunas de las tareas planeadas en un principio, como la fase de generación de código, cambiaron radicalmente al estudiar la forma en la que teníamos que utilizar las DSL Tools para generar código a partir de nuestros diagramas. De la misma forma, pasamos de tener prevista la finalización del proyecto el día 16 de Mayo al día 26 de Mayo como al final vimos que sería mas factible. Esta última fecha del día 26 de Mayo fue la que finalmente cumplimos puesto que dimos por acabado el proyecto ese mismo día, pese a que no teníamos finalizado el proyecto de instalación del pluggin, cosa que no habíamos contemplado en la planificación por ser algo extra. Vamos a ver un resumen de las 39 tareas en las que subdividimos el proyecto, para hacernos una idea algo mas general de lo que tuvimos que llevar a cabo para su desarrollo, para ello, adjuntamos la tabla de tareas realizadas del proyecto a día 28/06/2006, cuando ya habíamos terminado la fase principal del proyecto, pero aún no teníamos implementado el instalador de la aplicación:
  18. 18. 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 18
  19. 19. 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 19 En ella podemos ver de forma general, las 34 tareas que ya teníamos implementadas, así como los tiempos de desarrollo que invertimos en cada una de ellas. Ahora pasamos a mostrar el desglose de la planificación, atendiendo a los recursos que utilizamos, que fuimos tanto vicente como enrique, puesto que fuimos los dos únicos programadores del pluggin. Como recursos, a parte de nosotros dos, hacemos referencia a tres archivos llamados End-End.WizardUIPGuide.doc, Example.ValidationAndConstraints.doc y Example.DSLCustomizations.doc puesto que fueron tenidos en cuenta en los comienzos del desarrollo para estudiarnos el modelo, funcionamiento y programación de las DSL Tools. No se ha tenido en cuenta como recurso por otra parte, la información relativa al modelo multidimensional orientado a objeto que modela nuestra aplicación, puesto que eso fue algo que tuvimos que aprendernos antes de llevar a cabo el proyecto y no hemos creído conveniente incluir en los tiempos algo que se supone teníamos que saber para poder realizar la herramienta CASE.
  20. 20. 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 20
  21. 21. 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 21 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: El proceso de desarrollo usando DSL Tools, como podemos ver en el diagrama anterior, es un proceso incremental e iterativo. El proceso de desarrollo comienza con la creación de un nuevo proyecto Domain Specific Language Designer, que no es mas que el diseñador gráfico que representará nuestro modelo y luego a partir de el será cuando comencemos a programar la generación de código, la cual podemos ver representada mediante la transformación de templates a la generación de código. Pese a que en la planificación del proyecto que nos hicimos, podemos ver un una planificación en cascada, puesto que vamos haciendo una cosa cuando acabamos la otra, el modelo del lenguaje de dominio se ha realizado usando una metodología iterativa puesto que una vez teníamos una versión estable, volvíamos al principio para añadir funcionalidad y mejorar el modelo. No nos ha hecho falta realizar muchas iteraciones completas puesto que el modelo estaba muy bien especificado y pudimos realizar cada paso prácticamente conforme lo teníamos previsto, pero eso no quita que lo normal sea tener un proceso iterativo en la definición del modelo de dominio.
  22. 22. 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 22 Diagrama de Gantt A continuación se muestra el diagrama de Gantt de todo el proceso de desarrollo del proyecto, incluyendo la fase 1 de preparativos en la que estuvimos investigando el funcionamiento de las DSL Tools.
  23. 23. 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 23 Repositorio Decidimos montar un sistema de control de versiones para poder controlar el proyecto correctamente y no tener sobresaltos ante perdidas de información y sobre todo porque podemos tener el control del código siempre que queramos, pudiendo volver a versiones previas del desarrollo si llegábamos a algún punto de “no retorno” al ir programando. Las 3 opciones que barajamos eran:  CVS  Subversión  Visual SourceSafe La tercera fue inmediatamente descartada a pesar que es la que nos propone por defecto la herramienta Visual Studio 2005, puesto que su modelo de programación “en exclusiva” no permitía trabajar simultáneamente a los desarrolladores en los mismos archivos, quedando bloqueados siempre que los editaba alguien. Esto era un problema puesto que al trabajar físicamente dispersos, no podíamos estar pendientes el uno del otro en cada momento. CVS era una buena candidata al principio por tratarse de un sistema de control de versiones maduro y estable pero le faltaba algo, y este algo era que tiene la pega de que cada uno de los cambios que se realizaban se subían completamente al repositorio y esto quiere decir que si tenemos 1000 versiones distintas del mismo archivo con pequeños cambios, tenemos 1000 archivos idénticos pero con pequeños cambios entre ellos y que ocupan prácticamente lo mismo. Teniendo en cuenta que trabajaríamos con ficheros de documentación de varios megas, .dll´s que podrían ocupar cientos de kilobytes,…esto supondría una ocupación de disco bastante amplia para el servidor donde lo teníamos montado (un servidor propiedad de Enrique Catalá) que tenia disco limitado. Nos decantamos finalmente por Subversión por disponer de todo lo que necesitábamos además de tratarse del nuevo sistema de control de versiones que se está imponiendo en la comunidad de Software Libre para desarrollos distribuidos y que como principal ventaja era que las actualizaciones de archivos no eran completas, sino que se actualizaba en el repositorio única y exclusivamente la porción modificada. Incluso los archivos de .doc funcionaban de esta forma (no siendo el caso de los archivos binarios como imágenes, zip,…) y esto nos aseguraba actualizaciones mas rápidas, menos tráfico de red y menos consumo de espacio en disco del servidor. Finalmente instalamos subversión sobre un servidor con Sistema Operativo Ubuntu Hoary.
  24. 24. 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 24 Gráfico de revisiones A continuación se muestra el gráfico de revisiones que se ha ido formando a medida que realizábamos el proyecto. Podemos ver como en cada uno de los hitos conseguidos, realizábamos una nueva rama estable que almacenábamos en una carpeta de backup dentro del repositorio. Cada uno de los hitos está marcado en color gris. Cada vez que cumplíamos un hito hacíamos un “fork” sobre el proyecto en desarrollo que almacenábamos ( para nunca más tocar ) en una subcarpeta denominada “BackupsVersiones Estables” y que podemos ver gráficamente mediante los recuadros de color verde. Si nos fijamos, la ruta principal del proyecto es /ProyectoDSL/ObjectOrientedMultidimensionalModel, mientras que la ruta de los backups de los hitos es /ProyectoDSL/Backups/Version X/ObjectOrientedMultidimensionalModel Hemos de resaltar que la Revisión 208 podemos ver que es eliminada en la revisión 214 porque lo que se almacenaba no consideramos conveniente tomarlo como un hito, puesto que se trataba de la prueba de concepto de embeber los ficheros de generación de código en la dll del proyecto, pero que no funcionaba aún por lo que decidimos eliminarla.
  25. 25. 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 25 Podemos observar si vemos el gráfico, que hay una etiqueta de texto explicativa que se corresponde a la Revisión 225 ( versión 0.4 y última ), donde podemos ver que el 10 de Mayo de 2006 dimos por finalizada la tarea 30 que se correspondía con el paso de embeber los ficheros de generación de código en la .dll cumpliendo la planificación que nos marcamos y que podemos ver en el diagrama de Gantt.
  26. 26. 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 26 Sincronización con el repositorio Vamos a mostrar la pantalla que hemos estado utilizando para controlar cada una de las revisiones que realizábamos. Esta pantalla forma parte del programa TortoiseSVN (cliente de Subversión para Windows), que puede ser descargado de la Web http://tortoisesvn.sourceforge.net/downloads totalmente gratuito y con licencia GPL. La pantalla consta de 3 partes bien diferenciadas: 1. Podemos ver información sobre cada una de las revisiones, fecha, autor, mensajes que utilizábamos para describirla,.. 2. En la segunda podemos ver el comentario que realizábamos en cada actualización 3. En la tercera los archivos modificados, añadidos o eliminados que han intervenido en la revisión.
  27. 27. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 27 Estadísticas de desarrollo A continuación vamos a comentar algunos datos del proceso de desarrollo relativos a los dos programadores que intervinimos en el. En primer lugar vemos una pantalla que incluye las 9 semanas de desarrollo de proyecto única y exclusivamente, sin incluir las de documentación ni el instalador. *Grafico 1: No incluye las semanas de documentación, solo desarrollo En la siguiente captura (Gráfico 2), podemos ver un gráfico que compara a los dos desarrolladores en cuanto a confirmaciones por semana. *Grafico 2: Semanas de desarrollo de proyecto, sin documentación del mismo El primer pico de vicente se corresponde con los primeros pasos con el interfaz de diseño y podemos ver como enrique esta algo inactivo puesto que el se encarga del proceso de generación de código.
  28. 28. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 28 Una vez ya se obtuvo una primera versión de la interfaz de usuario, podemos ver como enrique comienza el desarrollo de la generación de código exhaustivamente, quedando vicente en un estado aletargado en el que se dedicaba a añadir y mejorar gráficamente la interfaz (recordemos el proceso iterativo comentado antes) pero que no podía continuar hasta que enrique no acabara con el modelado de la API de generación de código. Una vez enrique definió el estándar de generación de código, vicente ya pudo ponerse con todo el proceso de generación de código mediante eventos de ratón, sacando ventanas que preguntaban sobre lo que el usuario quería hacer y extendiendo las posibilidades de la interfaz gráfica,… El gráfico siguiente (Grafico 3) ya muestra las últimas semanas de proyecto en las que vicente esta más activo puesto que se ha encargado del proyecto del instalador del pluggin para Visual Studio. *Grafico 3: Desarrollo completo incluyendo documentación del proyecto. Acabaremos diciendo que las estadísticas son meramente informativas, no tiene que ver con que un desarrollador haya realizado mas proyecto que otro, puesto que estamos hablando de confirmaciones contra el repositorio y estas se suelen hacer al final del día y ante cada desarrollo de código satisfactorio pero obviamente podemos estar en un proceso de investigación, depuración, etc. y esto no se vería reflejado en estas estadísticas.
  29. 29. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 29 Versiones estables por hito Existen 4 versiones estables en diversos hitos del proyecto que hemos marcado como funcionales en la carpeta de backup y que se corresponden con las cuatro ramas que podemos observar en el gráfico de revisiones antes mencionadas. Estos cuatro hitos son:  Version 0.1: Primera versión compilable. Permite dibujar Fact, Dimension y Base, pero no permite relaciones ni nada aún.  Version 0.2: Version compilable. 99% de diseñador y comenzada la generación de código. Se permite generar código simple de create tables, sin cuerpo aún.  Version 0.3: Version compilable. En esta versión ya se genera SQL Estrella al 100% y se ha comenzado a programar la generación SQL snowflake.  Version 0.4: Version 0.4 estable y funcional. Soporta botón derecho para generar código y el 99% de los errores al diseñar te los muestra. 100% de generación de código.
  30. 30. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 30 II. Lenguaje específico de dominio para modelado multidimensional En esta parte explicamos como se ha trabajado en la creación de un lenguaje específico de dominio con el fin de poder modelar almacenes de datos multidimensionales. Trataremos de manera más concreta la interfaz de usuario y los pasos que hemos tenido que dar para lograr el modelo final. En un primer momento tuvimos que definir el esquema conceptual del modelo de dominio, tal y como ha sido expuesto en el capítulo referido a las DSL Tools. Los primeros modelos no fueron satisfactorios, daremos las razones de ello y cómo lo solucionamos hasta llegar al esquema definitivo. El siguiente paso, aunque realmente se ha sido realizando de forma paralela a la creación del modelo de dominio, fue la realización del modelo gráfico. Daremos una breve descripción de los pasos para desarrollarlo, pero explicaremos en más profundidad el resultado final, las clases, formas y conectores que lo componen. A continuación era necesario establecer las restricciones y validaciones sobre nuestro modelo, para así darle una semántica más fuerte. Hablaremos de los archivos de recursos, que nos han servido para organizar los mensajes de error y otros recursos necesarios, los dos tipos de restricciones que se han desarrollado: hard constraints y soft constraints; y, por último, la lista de los errores establecidos, y las pequeñas diferencias entre éstos y los errores del modelo inicial cedido por la Universidad de Alicante. Y, finalmente, hemos tratado de explicar como se desarrolló la apariencia final que tiene el software, la interacción con el usuario, los cambios que hemos debido de hacer en el archivo de comandos CommandSet.dslddt y las nuevas clases que dan como resultado los cuadros de diálogo que nos permiten elegir entre las distintas opciones de generación de código del modelo creado por el mismo usuario (elección de la base de datos, dimensiones a normalizar…). Modelo de dominio El primer paso para dar forma a nuestro modelo consistía en realizar un esquema conceptual del mismo. Las DSL Tools nos ofrecen esta misma posibilidad con las herramientas ya explicadas (clases, propiedades y relaciones), dándole además la función añadida de poder obtener un diseñador gráfico a partir de ese modelo. Iremos explicando como fue ese primer modelo, que plasmaba la idea conceptual inicial que teníamos del sistema, y de qué manera tuvimos que ir modificándolo para que pudiese adaptarse a las exigencias y restricciones de las DSL Tools, hasta poder obtener así el modelo final al que se ha llegado. Esquema conceptual Como se ha comentado, se ha realizado una reproducción del modelo multidimensional para almacenes de datos expuesto por la Universidad de Alicante en su artículo (ver referencia en bibliografía). De este modelo sólo se ha desarrollado el nivel 3 debido a limitaciones de la herramienta, por lo tanto los elementos necesarios se reducen a
  31. 31. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 31 Facts, Dimensions, Bases, Degenerate Facts, Asociaciones Rolls-up To y Completeness, y los atributos Degenerate Dimension, Fact Attribute, OID, Descriptor y Dimension Attribute. El boceto inicial para organizar todos estos conceptos era el siguiente: Se intentó organizar los conceptos de la manera más sencilla posible para así luego obtener un esquema de la misma manera sencillo. A la hora de intentar traducir este esquema a un modelo de dominio de las DSL Tools, se tuvo que tener en cuenta algunos aspectos:  Se necesita una clase raíz de la que deriven las demás clases para darle así sentido al modelo. A esta clase se le ha llamado “Esquema” Fact Dimension Base Class DegenerateFact Association Rolls-up To Completeness DegenerateDimension FactAttribute OID Descriptor DimensionAttribute Attributes Element
  32. 32. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 32  Tanto las clases como los atributos se debían especificar en el modelo como clases. La diferencia entre unos y otros se realizaría en la parte del diseñador, en donde para aquellos que sean atributos deberían embeberse en otras clases. Sin embargo, en el modelo, se podía hacer una superclase “Class” y otra superclase “Attribute” para distinguirlos, y darle características comunes de ser así necesario.  Las asociaciones se especifican como relaciones en el modelo de dominio. De todas maneras, la Rolls-up To y Completeness, al ser ambas asociaciones entre bases, se representarían como un atributo en dicha asociación, visible por lo tanto seleccionando las propiedades de la relación en la ventana de propiedades de Visual Studio.  La clase DegenerateFact, al ser una clase especial, se dejaría de momento a parte. De esta manera, el esquema conceptual inicial para el DomainModel de las DSL Tools quedó así:
  33. 33. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 33 Esquema que, por supuesto, no compilaba todavía… Hacia un modelo compilable Dado que el sencillo esquema conceptual anterior resultaba aún incompleto, decidimos dar un paso más hacia la primera compilación de nuestro proyecto. Entonces se nos presentaron una serie de problemas que fueron necesarios resolver antes de poder continuar. El primero de ellos era la organización de las clases y sus atributos, así como conseguir relacionarlos entre ellos. En segundo lugar, distinguir los distintos tipos de relaciones, y el aspecto que iban a tener en el modelo de dominio. Y, por último, fue necesario solucionar algunos errores de compilación que no nos permitían seguir avanzando en nuestra tarea. Atributos embebidos
  34. 34. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 34 Para que un atributo pudiese representarse como tal de una determinada clase era necesario que la clase que representa dicho atributo estuviese embebida en la clase que lo contiene. Gráficamente, si tenemos una clase 1 que embebe una clase dos, la relación entre ellas debe ser una Embedding relationship, como se muestra a continuación: Lo que más tarde se traduciría gráficamente por: Que era lo que se buscaba para poder representar los atributos de las clases. Para que el modelo compilara correctamente había que tener en cuenta una serie de restricciones (impuestas por las DSL Tools):  Debe haber entre ellas una relación embebida (como ya se ha explicado).  La propiedad Accepts del rol de la izquierda (el triángulo) debe estar marcada como “All”, mientras que la otra (la del rectángulo) debe ser “None”.  Para que una clase pueda embeber a otra, la clase embebida no puede estar ya embebida por otra clase. Por ejemplo, si tenemos una clase A que embebe a B, no puede existir una clase C que ya embeba a B. Gráficamente: Esto significa que una clase puede embeber a todas las que quiera, pero sin embargo una clase solo puede ser embebida por otra. Esto suponía un problema para los atributos DegenerateDimension y FactAttribute, ya que ambos estaban embebidos tanto por el Fact como por el DegenerateFact.
  35. 35. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 35 Como solución provisional se cambiaron las relaciones del DegenerateFact por referencias. Más adelante explicaremos como solucionamos el problema.  Y por último, en una relación embebida sólo hay cuatro posibles combinaciones en las cardinalidades de los roles: (*,0), (*,1), (+,0), (+,1). Cualquier otra combinación entre ellas dará error cuando intentemos generar los templates. El rol del rectángulo no te da opción a ningún otro valor que no sea 0 o 1, pero sin embargo el triángulo si que te permite cualquier valor. En este último rol, por lo tanto, el valor de max siempre deberá ser de ‘0’. Relaciones en el modelo Sabiendo esto, se añadieron al esquema todas las relaciones entre clases como references, y las de clases con atributos como embedding (a excepción de las del Degenerate Fact). Estas relaciones son:  Entre clases: o Base con Base:  BaseAssociatesBase: asociaciones entre bases. A su vez tiene 5 atributos: 1. type: RollsupTo o Completeness. 2. SourceMultiplicity: cardinalidad en el origen. 3. TargetMultiplicity: cardinalidad en el destino. 4. SourceRole: role en el origen (+d o +r). 5. TargetRole: role en el destino (+d o +r).  BaseInheritsBase: herencia entre bases o Dimension con Base:  DimBaseAssociation: asociaciones entre una dimensión y una base. o Fact con Dimension  Aggregation: agregaciones, siempre entre un hecho y una dimensión. Estas agregaciones, a su vez, pueden estar relacionadas con un DegenerateFact.  Entre clases y atributos: o Base:
  36. 36. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 36  Descriptor  DimensionAttribute  OID o Dimension (sin atributos) o Fact:  DegenerateDimension  FactAttribute o DegenerateFact:  DegenerateDimension  FactAttribute De este modo, el esquema quedó como indica la siguiente figura:
  37. 37. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 37 NOTA: Las relaciones Aggregation y BaseAssociatesBase son mostradas como clases debido a que una posee a su vez otra relación y la otra tiene atributos dependientes de ella, respectivamente. Y según las DSL Tools, para poder especificar esto es necesario
  38. 38. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 38 extraer la relación como clase (aunque sólo de forma visual, semánticamente siguen siendo relaciones). Esto se consigue seleccionando la relación y dándole al botón derecho elegir “Show As Class”. Errores de compilación Sin embargo, todavía no conseguíamos compilar el modelo del todo, nos encontramos con algunos errores de compilación que nos lo impedían. Pasaremos a explicarlos levemente: 1. Problemas derivados de usar palabras reservadas. Si nos fijamos en el siguiente esquema (1), hay dos roles que utilizan palabras reservadas. Si los dejamos tal y como están, a la hora de compilar nos darán errores extrañísimos, pero si nos fijamos en la zona del código donde se producen veremos que hay algunas palabras reservadas que se utilizan de manera incorrecta. En nuestro caso nos pasaba con las palabras “class” y “base”. La solución consiste en darle otro nombre, tales como “classRole” y “baseRole”, respectivamente. 2. Error de tipo de datos mal definido. En las asociaciones entre bases, para definir el tipo de asociación que representa (Rolls-upTo o Completeness), se ha añadido un atributo a dicha asociación, llamado type. El tipo de dato de este atributo es un enumerado llamado AssociationType. Pues bien, para cada tipo de dato que se defina como enumerado es obligatorio ponerle un valor por defecto (etiqueta Default en las propiedades de la propiedad type), y este valor debe ser un string que represente alguno de los tipos enumerados definidos, no su valor numérico. Si se pone como valor por defecto un valor numérico aparecerá un error en el código como el siguiente: Private Proyecto.Fincarrera.ObjectOrientedMultidimensionalModel.DomainModel.AssociationType typePropertyStorage = Proyecto.Fincarrera.ObjectOrientedMultidimensionalModel.DomainModel.AssociationType.0; Ese cero al final del código es sintácticamente incorrecto, debería aparecer un string dentro de los definidos en AssociationType. Vemos más claramente el error en la siguiente imagen:
  39. 39. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 39 Lo solucionamos poniendo “RollsupTo” en lugar del 0 en el atributo Default.
  40. 40. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 40 (1) Esquema que muestra el mal uso de palabras reservadas
  41. 41. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 41 3. Problema del carácter no válido dentro de una enumeración. Este error está también relacionado con el anterior. En la enumeración antes descrita, hay que tener cuidado con los caracteres utilizados para definir cada elemento, ya que todos esos strings serán más adelante convertidos en código que deberá ser correcto sintácticamente. Nuestra enumeración inicial era: Donde se puede apreciar que el tipo Rolls-upTo tiene un guión, que a la hora de traducirlo a código daría la siguiente definición de tipo enumerado: public enum AssociationType { Rollsup-To=0, Completeness=1, } Lo que es incorrecto, y hace que el compilador nos diga que esperaba un “;”. La solución es tan sencilla como quitar dicho guión. Por lo tanto, después de todos estos detalles y errores de compilación, conseguimos así el primer modelo compilable. El esquema del modelo de dominio es el mismo que en (1), y el resultado gráfico que se obtiene es el siguiente: Todavía no se habían probado los conectores, pero cada una de las clases queda representada con el efecto gráfico que buscábamos.
  42. 42. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 42 Esquema definitivo Tras conseguir el primer modelo compilable, quedaban aún por resolver diversas cuestiones. Entre ellas se encontraban el conseguir realizar las asociaciones entre elementos del modelo (conectores), el problema ya comentado de varios atributos que deben estar embebidos en distintas clases y decidir qué hacer con la clase DegenerateFact. Pasaremos a tratar cada uno de estos temas hasta así lograr obtener el diagrama final a partir del cual se ha trabajado en la generación de código. Conectores Para conseguir mostrar las asociaciones en el esquema final, era necesario asociarlos en el diseñador como conectores entre clases. Explicaremos como se realiza esto más adelante, en el siguiente apartado sobre la creación del diseñador gráfico. La cuestión que se nos plantea ahora era el resultado visual que nos daba. Cuando tenemos una referencia entre una clase A y otra clase B de tipos distintos, si queremos definir un conector para dicha referencia en el Designer.dsldd tenemos que especificar un (y sólo un) sentido en el que el conector será dibujado, esto es, desde un rol hasta otro. En nuestro caso muchos de los conectores actúan de esta manera, por lo que no existe ninguna dificultad. El problema se plantea cuando queremos que nuestro conector pueda dibujarse en ambos sentidos. Si queremos que se pueda navegar desde la Shape A hasta la Shape B y viceversa, una posible solución consiste en que en el modelo de dominio ambas clases deriven de una superclase ficticia (o real, en el caso de que ya derivaran de otra clase), llamémosla clase C, y crear un conector desde la clase C a sí misma. Gráficamente, De esta manera ya podremos crear un conector desde la Shape A que represente a la clase A hasta la Shape B que represente a la clase B, y viceversa. Sólo hay que poner las Shapes permitidas en la etiqueta <permittedShapes> del Designer.dsldd (para más información sobre el Designer, consultar apartado Creación del diseñador gráfico). En nuestro caso particular, queríamos tener la posibilidad de relacionar la clase Dimension y la clase Base en ambos sentidos, por lo que se tuvieron que hacer los cambios explicados en el modelo de dominio. De esta manera pasamos de tener este esquema:
  43. 43. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 43 a tener este otro, donde la relación entre dimensión y base se especifica en la relación de “Class” a “Class”:
  44. 44. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 44 Perdemos en claridad a la hora de leer en modelo, ya que no resulta tan intuitivo que existe una relación entre Dimension y Base, pero ganamos en funcionalidad. El problema es que las restricciones que nos obligan a relacionar una clase Dimension con una Base hay que especificarlas a otros niveles. La clase DegenerateFact Hasta ahora habíamos dejado la clase DegenerateFact aparte, por tratarse de una clase especial. Cuando hablábamos del esquema conceptual, antes de meternos en asuntos concretos de las DSL Tools, veíamos como el concepto DegenerateFact era a la vez una clase y una asociación. Esto es porque une dos conceptos, solo puede darse en una relación entre una instancia de un Fact con una instancia de una Dimension, de otra manera no tiene sentido. Hasta el momento, el esquema que tenemos es el siguiente (se han contraído en el esquema la clase Base y la asociación Aggregation para simplificar):
  45. 45. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 45
  46. 46. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 46 Como se puede apreciar, no se puede acceder a la clase DegenerateFact desde ninguna ruta a partir de la clase raíz “Esquema”, por lo que no aparecerá en el diseñador cuando depuremos el modelo. Como tenemos dos tipos principales de clases que dependen de la raíz, Attributes y Classes, lo más lógico es englobarlo dentro de las Classes, ya que guarda muchas más similitudes con ellas. Por lo tanto, ahora la clase DegenerateFact heredaría de la clase Class al igual que las otras clases. Pero todavía queda por solucionar el tema de sus atributos. Como hemos explicado ya en el punto Atributos embebidos, una clase no puede estar embebida por otra si ya existe una clase que la embebe. Recordemos que los atributos de DegenerateFact (DegenerateDimension y FactAttribute) ya están embebidos por la clase Fact. Si intentamos establecer una relación embebida que vaya de DegenerateFact a estos mismos atributos nos dará un error de compilación, no dejándonos continuar. En un principio habíamos tomado la decisión temporal de establecer las relaciones del DegenerateFact con sus atributos como referencias, pero no puede quedarse así ya que para que gráficamente se pueda representar como una clase dentro de otra (ver figura de abajo), se exige que haya una relación embebida entre ellas. Para poder representar las clases de esta manera, Clase1 debe embeber a Clase2 Así que debemos de asumir que los atributos de Fact y los de DegenerateFact son distintos a la vista del modelo de dominio. Distintos pero con el mismo comportamiento. Por lo tanto, la solución que hemos buscado es crear dos clases abstractas DegenerateDimension y FactAttribute, de las cuales heredan otro par de clases para cada una de ellas: DF_DegenerateDimension y F_DegenerateDimension para la primera, y DF_FactAttribute y F_FactAttribute para la segunda, de manera que las que tienen nomeclatura DF pertenezcan al DegenerateFact y las de prefijo F sean de la clase Fact. De esta manera cada clase tiene sus propios atributos, por lo que será sintácticamente correcto, y a la vez dichos atributos se comportarán de la misma manera, por heredar de las mismas clases. Resumiendo, haciendo estos cambios el modelo quedaría de la siguiente manera:
  47. 47. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 47
  48. 48. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 48 Las clases dibujadas con puntos suspensivos indican que son clases abstractas. Como se puede ver, ahora si que existe una relación embebida tanto para los atributos de Fact como para los de DegenerateFact, así que se podrán representar gráficamente tal y como buscábamos. Conector del DegenerateFact Una vez teníamos todo lo necesario para poder representar el modelo nos surgió una dificultad, de nuevo con la clase DegenerateFact, y esta vez con respecto a la representación de su conector. Hasta ahora el conector del DegenerateFact se había especificado en el modelo de dominio como se muestra el esquema simplificado de abajo, pero todavía no se había sincronizado con el diseñador, por lo tanto no teníamos ninguna representación física de tal relación. Pero resulta que en el DomainModel sí que se puede especificar la relación entre una clase y la intersección de otras dos, seleccionando Show As Class en la relación, tal y como se ha explicado antes. En nuestro caso, sucede así con la clase DegenerateFact y la agregación entre las clases Fact y Dimension. Pero desgraciadamente no hay forma ninguna de representar gráficamente dicha relación. Lo ideal habría sido un conector que tuviera en un extremo la clase DegenerateFact y en el otro el conector que une a una
  49. 49. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 49 instancia de un Fact con una de una clase Dimension. Pero la herramienta en esta versión no lo permitía, por lo que tuvimos que buscar opciones alternativas. Teníamos dos posibilidades. Una era crear una clase puente (representada con una figura geométrica, como por ejemplo un rombo) y un conector específico que pudiese unir a las tres clases entre sí; o bien crear un conector que fuese exclusivamente desde la clase DegenerateFact hasta una clase Fact y/o a otra clase Dimension (para cada relación, por lo tanto, habría que usar dos conectores). Se escogió esta última opción por simplicidad. Por lo tanto decidimos crear un conector llamado DegenerateFact Association, representado por una línea de puntos, que se comportara de esta manera. El resultado gráfico era el siguiente: Y todo esto trasladado en lenguaje de modelo de dominio daba resultado a una nueva relación que debía tener en cuenta a tres clases: Fact, Dimension y DegenerateFact. Para poder establecer restricciones entre ellas, la relación no podía ser directa entre las clases, sino a partir de la clase de la que todas ellas derivan. De esta manera, al igual que hicimos con el conector bidireccional entre Dimension y Base (ver apartado Conectores), había que establecer una relación entre la clase Clase consigo misma, para luego en el diseñador poder especificar las tres clases implicadas y el sentido del conector. En resumidas cuentas, el resultado después de cambiar este tipo de conector en el modelo de dominio era el siguiente:
  50. 50. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 50 Como se ve en la imagen anterior, la relación en Aggregation ya no existe, y ha sido sustituida por otra relación de Clase a Clase llamada FactDimHaveDegenFact (se puede ver el nombre en la ventana de propiedades del Visual Studio). Ya que el conector se debe relacionar tanto con un Fact como con una Dimension, las cardinalidades tenemos que establecerlas como muchos a muchos, para poder permitirnos más de un conector desde la clase de DegenerateFact. Las restricciones del número de conectores máximo por clase deberemos imponerlas a otros niveles (ver apartado Restricciones y Validaciones). Esquema final del Modelo de Dominio Después de todos estos cambios para conseguir un equilibrio entre el esquema conceptual del modelo de dominio y las posibilidades gráficas que se permiten obtener a partir de él, obtuvimos el esquema de modelo de dominio con el que se ha estado trabajando en el resto del proyecto. Dicho esquema totalmente desplegado es el siguiente (se ha dividido en dos páginas para su mejor visualización):
  51. 51. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 51
  52. 52. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 52 Interfaz de usuario La creación del diseñador gráfico y del aspecto de la interfaz no es una tarea independiente de la de la creación del modelo de dominio. De hecho ya se han visto casos en los que hay que tener en cuenta las posibilidades gráficas de la herramienta antes de tomar una decisión sobre la forma del esquema conceptual. En algunos, incluso, se ha perdido legibilidad en el esquema para poder ganar en recursos gráficos. Por lo tanto son dos procesos que deben desarrollarse de forma paralela, y siempre que se hace un cambio en el modelo de dominio se debe poder sincronizar con el diseñador.
  53. 53. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 53 Para el desarrollo de esta fase ha sido de gran ayuda la herramienta ofrecida por Modelisoft, la “DslDm2Dd Tool”. Gracias a ella, nos hemos podido ahorrar la difícil comprensión del código XML que sirve para definir el fichero Designer.dsldd, base del diseñador gráfico en las DSL Tools. Con unos pocos cuadros de diálogo hemos podido darle una apariencia bastante aceptable a nuestro diseñador, y a la vez comprender de manera general como está esquematizado el fichero principal del Designer. No pretendemos aquí hacer un tutorial sobre la herramienta, ni mucho menos del funcionamiento del fichero Designer.dsldd, ya que nos llevaría hojas y hojas poder explicar ambos con suficiente claridad. Sin embargo, hemos preferido en este apartado describir el resultado gráfico final de nuestro proyecto, una vez conseguido el esquema de modelo de dominio definitivo. Por lo tanto describiremos en los dos primeros apartados todas las herramientas de las que disponemos para dibujar un modelo multidimensional orientado a objetos (con extensión *.oomm), así como su funcionamiento y limitaciones. Y sólo en el último apartado hablaremos un poco sobre algunos problemas encontrados durante el camino, únicamente a modo general, y la mayoría de ellos debido a bugs o errores que posiblemente hayan sido ya subsanados en posteriores versiones de las DSL Tools. Clases y formas Para que una clase pueda ser representada en el diseñador como tal, hay que asociarla a una Shape en el fichero del Designer.dsldd. Existen tres tipos distintos de Shapes: 1. Geometric Shape: forma geométrica predefinida (rectágulo, rectágulo redondeado, elipse, círculo o diamante). 2. Image Shape: imagen de un arcchivo. 3. Compartment Shape: forma geométrica (rectángulo o rectángulo redondeado) que puede tener otras clases embebidas como atributos. Nosotros debemos representar 4 clases distintas: Fact, DegenerateFact, Base y Dimension. Las tres primeras se representan como Compartment Shapes, ya que todas ellas tienen atributos, mientras que la clase Dimension se representa como una Image Shape. Las resumimos en la siguiente tabla:
  54. 54. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 54 Nombre de la clase (DomainModel) Nombre de la Shape (Designer) Icono en la Toolbox Forma en el diseñador Atributos Fact FactShape  DegenerateDimension  FactAttribute Dimension DimensionShape ─ Base BaseShape  OID  Descriptor  DimensionAttribute DegenerateFact DegenerateFactShape  DegenerateDimension  FactAttribute
  55. 55. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 55 Conectores entre clases En el caso de las relaciones entre clases, para que puedan materializarse gráficamente deben ser asociadas a un conector en el Designer.dsldd. Todos los conectores que hemos creado se corresponden a una Reference RelationShip en el DomainModel. Son cinco: Aggregation, Association, BasesAssociation, Inheritance y la DegenerateFact Association. En el caso del Aggregation y del BasesAssociation los conectores contienen cardinalidades en sus extremos (consultar apartado Soft Constraints). Teóricamente el conector de BasesAssociation debería tener una etiqueta que indicara el tipo de conector (RollsUp-To o Completeness), pero esta versión de las DSL Tools no permitía las etiquetas en el centro del conector (bug de esta release, consultar apartado Etiquetas en los conectores). El conector del DegenerateFact relaciona tres clases: Fact, Dimension y DegenerateFact. Por lo tanto, harán falta dos conectores para que estén las tres relacionadas entre ellas. Para utilizarlo siempre habrá que partir del DegenerateFact. Un conector entre dos tipos distintos de clases será unidireccional si sólo se puede establecer dicha relación desde una clase determinada a la otra. Será bidireccional si se puede hacer en ambos sentidos. Podemos ver la representación de los conectores en la siguiente tabla:
  56. 56. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 56 Nombre de la relación (DomainModel) Nombre del Connector (Designer) Icono en la Toolbox Forma en el diseñador Clases que relaciona Aggregation AggregationConnector Fact con Dimension (unidireccional) DimBaseAssociation AssociationConnector Dimension con Base (bidireccional) BaseAssociatesBase BaseAssociatesBaseConnector Base con Base
  57. 57. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 57 BaseInheritsBase BaseInheritsBaseConnector Base con Base FactDimHaveDegenerateFact FactDimHaveDegenerateFactConnector DegenerateFact con Fact (unidireccional) y DegenerateFact con Dimension (unidireccional)
  58. 58. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 58 Problemas encontrados A la hora de intentar sincronizar el DomainModel con el Designer se han encontrado una serie de dificultades, la mayoría de ellas relacionadas con los iconos. Consideramos una buena guía de apoyo para aquellos que quieran seguir los pasos que hicimos nosotros en nuestro momento. Por lo tanto pasaremos a explicar dichas dificultades y limitaciones, y la manera de la cual se han solucionado (en los casos en los que ha sido posible). Cambio de iconos en la Toolbox Algo tan sencillo como cambiar un icono ya definido para una clase en el Toolbox puede acarrear muchos problemas. Al intentar modificar el icono con la aplicación DslDm2Dd, generar plantillas y compilar, todo es aparentemente correcto; pero cuando se ejecuta en modo depuración es probable que el antiguo icono siga estando en la Toolbox. Suponemos que es un error de la herramienta de sincronización, que por alguna razón no actualiza los cambios relacionados con los recursos del proyecto. La cuestión es que después de muchas pruebas, para poder cambiar un icono hemos tenido que seguir los siguientes pasos: 1. Ejecutar el DslDm2Dd, y borrar la clase en la parte del Designer Definition que corresponde a la clase a la que se quiere cambiar el icono. Guardar el Designer.dsldd. 2. Volver al Visual Studio, generar templates y depurar. El icono debe haber desaparecido de la Toolbox. 3. Volver a ejecutar el DslDm2Dd y arrastrar de la parte del Domain Model el concepto del cual hay que cambiar el icono a la raíz del Designer Definition para crearlo de nuevo. 4. Cambiarle el nombre de la clase a otro distinto del antiguo. En nuestro ejemplo, vamos a cambiarle el icono al conector BaseAssociatesBaseConnector, así que le pondremos como nuevo nombre BaseAssociatesBaseConnector2 (ver imagen). 5. Seguir los pasos del asistente hasta que te pida el icono, y seleccionar el fichero correspondiente. 6. Salvar, generar plantillas y depurar. El nuevo icono aparecerá el la Toolbox. Creando un elemento en el Designer con un nuevo nombre hace que se cree un nuevo objeto y que, por lo tanto, se inicialicen todos sus valores a los indicados por primera vez. Siguiendo estos pasos hemos cambiado el nombre al objeto del Designer Definition a otro distinto del que teníamos antes. Si queremos volver al nombre antiguo tan solo hay que hacer un Replace All del nombre que tenemos ahora al nuevo que queremos (que era el que teníamos en un principio).
  59. 59. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 59 Etiquetas en los conectores (Text Decorators) Cuando hablábamos del conector BaseAssociatesBaseConnector, comentamos que debería de tener una etiqueta central donde apareciese el tipo de conector: RollsUp-To o Completeness. Sin embargo, esto no es posible en esta versión de las DSL Tools. En un principio, existen 6 posibles posiciones donde se puede colocar una etiqueta para un conector: CenterBottom, CenterTop, SourceBottom, SourceTop, TargetBottom y TargetTop. Todas ellas corresponden al atributo Position de la etiqueta <connectorText> del Designer.dsldd. Utilizando la herramienta de Modelisoft se puede seleccionar mediante el cuadro de diálogo de la figura de abajo. Pero desgraciadamente existe un bug en esta CTP que no permite poner etiquetas en las posiciones centrales, esto es, la CenterBottom y la CenterTop. Se puede especificar en el fichero XML, pero no produce ningún resultado. Por lo tanto, en el caso del conector BaseAssociatesBaseConnector, como también debe tener etiquetas para las cardinalidades, no es posible mostrar visualmente encima del mismo conector el tipo al que pertenece, ya que las cuatro únicas posibles etiquetas están ya ocupadas. Para saber el valor de dicho atributo habrá que seleccionar el conector y mirar en la ventana de propiedades del Visual Studio.
  60. 60. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 60 Iconos en las Compartment Shapes Como se ha explicado con anterioridad, existen tres tipos de Shapes que podemos darle a una clase (apartado Clases y formas): Geometric Shape, Image Shape y Compartment Shape. El problema es que no podemos representar Compartment Shapes con imágenes sacadas de un archivo (al igual que hacíamos en la Image Shapes, como en el caso de Dimension, pero con atributos). Esto no nos permite representar las clases Fact, DegenerateFact y Base como nos hubiera gustado, con una imagen y con atributos embebidos, pero sin embargo existe una solución intermedia: sí que se puede añadir un pequeño icono en alguna zona del rectángulo que representa la clase. Así podremos identificarlas inequívocamente. Si intentamos añadirle un icono con la herramienta DslDm2Dd, es muy probable que nos salga alguna excepción algo extraña. Tal y como explican en la página de dicha herramienta (ver apartado de enlaces), más concretamente en la parte del Walktrough donde pone More Information, los iconos de las Shapes aún no están implementados. Pero sin embargo podemos conseguir que aparezcan haciendo algunos pequeños cambios. Como el resultado de las Shapes con iconos ya se puede apreciar en el apartado de Clases y formas, lo que vamos a hacer es dar un sencillo ejemplo de cómo conseguirlo partiendo de un proyecto de las DSL Tools con el lenguaje mínimo. Vamos a poner un pequeño icono en la esquina superior izquierda a la shape que representa la clase ExampleClass. Primero de nada ejecutamos el DslDm2Dd y editamos la ExampleShape.
  61. 61. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 61 Vamos siguiendo los pasos del asistente, hasta que llegamos a la parte de los Icon Decorators, le damos al botón señalado con un + en la zona donde queremos poner nuestro icono, y lo seleccionamos en el menú contextual siguiente. Con la parte Always Visible marcada, le damos a aceptar y continuamos hasta que cerramos el asistente. Salvamos el Designer.dsldd y volvemos a la ventana del Visual Studio. Cuando recargamos el fichero y generamos templates parece que todo ha salido bien, pero si intentamos depurar el modelo nos saldrá algo parecido al siguiente mensaje de error:
  62. 62. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 62 Pues bien, tal y como se explica en este mensaje lo único que nos hace falta es agregar el icono en el fichero de recursos (Designer.Resource.resx). Detenemos la depuración y nos vamos a este fichero, y una vez allí seleccionamos la pestaña de images. Allí se encuentran ya los dos iconos que pertenecen a la Toolbox, sólo habrá que añadir nuestra imagen dándole a Add Resource -> Add Existing File. Es importante que el nombre de la imagen sea el mismo que el que nos decían en el diálogo de error. Una vez añadido, ya podemos volver a depurar y veremos como aparece el icono en cada nueva Shape que añadamos.
  63. 63. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 63 Iconos transparentes El último de los errores que encontramos en esta versión de las DSL Tools fue en relación con la apariencia final de los iconos, tanto en las Shapes como en la Toolbox. Puede que si se intenta insertar un icono personalizado nos hayamos encontrado que el icono aparece transparente. Como se ha podido comprobar, todo el tema de los iconos está todavía en fase de pruebas. Bien, en un post del foro de las DSL Tools de Microsoft se explica que si se deja la esquina superior derecha y la esquina inferior izquierda en blanco, todos los iconos blancos aparecen transparentes. Hemos comprobado que esto no solo sucede con el blanco, sino con cualquier color. Es por ejemplo el caso del icono que representa a la clase Fact. Todo su contorno es negro, por lo que al principio sucedía que toda la maya aparecía transparente en la Toolbox. La solución que le dimos fue cambiar el valor de dichos colores de las esquinas por un gris muy ennegrecido (valores RGB(10,10,10), por ejemplo), de manera que no se notara el cambio de color pero que a la vez fuesen distintos para evitar que se volviese transparente. En el dibujo de abajo se puede apreciar el cambio. Restricciones y validaciones Una vez conseguido el esquema final del modelo de dominio y la apariencia que iba a tener el diseñador, tocaba dedicarse a los detalles. El lenguaje utilizado para definir el modelo de dominio no era suficiente para expresar toda la semántica del modelo que se buscaba. Pero las DSL Tools incorporan también un sistema de validaciones y restricciones, en el cual modificando el código generado automáticamente se puede llegar a definir nuestro propio comportamiento para el modelo.
  64. 64. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 64 Una parte importante en este punto son los ficheros de recursos, por eso les dedicaremos un breve apartado para explicar su funcionamiento. Y con respecto a las restricciones, debemos decir que pueden añadirse de dos maneras distintas:  Usando el sistema de validaciones (soft-constraints). El código se añade en el proyecto del DomainModel (e.g. en una carpeta “Validation”). Las validaciones se realizarán cuando se disparen determinados eventos.  Usando el sistema gráfico en tiempo de ejecución (hard-constraints). El código se añade en el proyecto del designer (e.g. en una carpeta “Custom”). Las validaciones se realizan constantemente, en tiempo de ejecución. El elegir una forma de restringir nuestro lenguaje u otra depende de lo que estemos buscando. Las soft-constraints, por lo general, permiten trabajar de una forma más rápida y, al final del todo, pasar a solucionar las restricciones. Esto es posible dado que con este sistema de validaciones se puede seguir trabajando aunque haya partes de nuestro modelo que estén incorrectas. Por otro lado, las hard-constraints no permiten modelos incorrectos (con modelos correctos o incorrectos nos referimos siempre a errores de forma temporal). Las restricciones se solucionan conforme vamos dibujando el diagrama. Estas restricciones deberían ser más sencillas para que se puedan computar de una forma más rápida y no ralentice la ejecución del programa. De la misma manera, un número excesivo de hard- constraints puede llegar a resultar frustrante para el diseñador, al tener que estar parando a cada paso para resolver los problemas. Archivos de recursos Para los que no estén muy familiarizados con el entorno de Visual Studio, o bien los que sí lo están, para organizar un poco la estructura del proyecto dsl, introduciremos este apartado sobre los archivos de recursos. Visual Studio contiene unos archivos especiales de extensión .resx llamados archivos de recursos, utilizados para almacenar todos aquellos elementos necesarios por el programa tales como strings, ficheros, iconos, imágenes, etc. de una forma ordenada. Cada proyecto tiene al menos un archivo de este tipo. Se puede consultar dándole con el botón derecho en el proyecto, en Properties, y luego abriendo la pestaña Resources.
  65. 65. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 65 En el caso de un proyecto de las DSL Tools nos encontramos con más de un archivo de recursos. Nos referiremos a los proyectos principales, el Designer y el DomainModel, para explicar cada una de la función que se le ha dado a dichos archivos:  Designer Project: o En Properties/Resources.resx, este es el archivo principal de recursos, el mismo que se obtiene al darle al botón derecho y Properties. No se le ha dado ninguna utilidad. o En Diagram/Designer.Resources.resx, se refiere a los recursos relacionados con el diagrama, esto es, con el diseñador gráfico resultante. En nuestro caso, al tratarse dicho diagrama de nuestro campo de trabajo, ha sido el más utilizado, sobre todo dos recursos:  Strings: contiene las cadenas de caracteres de las Shapes, los conectores y de los mensajes de error de las hard-constraints.  Images: contiene las imágenes necesarias para representar las Shapes, y los iconos de la Toolbox. o En Shell/CommandSet.Resource.resx, se refiere a los recursos relacionados con los cuadros de diálogo y demás funcionalidades añadidas en el fichero CommandSet.dslddt (consultar apartado Cambios en el CommandSet). Se han utlizado tanto los Strings como los recursos de tipo File.  DomainModel Project: o En Properties/Resources.resx, este es el archivo principal de recursos, el mismo que se obtiene al darle al botón derecho y Properties. Al igual que en el Designer Project, tampoco se le ha dado ninguna utilidad.
  66. 66. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 66 o En DomainModel.Resource.resx, se refiere a todos aquellos recursos relacionados con el modelo de dominio. Tan sólo se han utilizado los Strings para describir las soft-constraints. Soft Constraints Como hemos comentado, en este sistema de validaciones las restricciones se producen cuando se disparan determinados eventos. Dichos eventos son:  Save: al salvar el fichero.  Open: al abrir el fichero.  Menu: al seleccionar la opción Validate All en el menú emergente cuando hacemos click con el botón derecho en el diagrama.  Custom: al hacerlo manualmente desde el código. El resultado cuando se produce una restricción es que aparece un mensaje en la pestaña de errores del Visual Studio, pero el usuario podrá seguir trabajando con el modelo aunque no estén todos los errores solucionados. Antes de nada, para poder trabajar con las soft-constraints es necesario activar el sistema de validaciones. Para ello, hay que abrir el fichero Designer.dsldd y modificar la siguiente etiqueta incluida en el <designerDefinition> (al final del fichero): <validation open="true" save="true" menu="true" custom="true" /> Dependiendo de cuando queramos que se comprueben las validaciones, pondremos a true unos eventos u otros. Una vez modificado, salvar el fichero. Si se ha elegido el evento de Save, es necesario añadir un par de strings al fichero Designer.Resources.resx, para mostrar dos errores que se pueden llegar a producir mientras se salva un fichero: En Value se puede poner el valor que se desee. El segundo error se produce cuando se intenta salvar el fichero habiendo errores de validación, y el primero cuando se decide no salvar el documento. Como las soft-constraints establecen restricciones para un esquema de modelo de dominio determinado, están estrechamente relacionadas con el proyecto del DomainModel. Por lo tanto añadiremos el código referente a las soft-constraints en ficheros contenidos dentro de un directorio al que llamaremos “Validation”, dentro del proyecto del DomainModel.
  67. 67. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 67 Cada restricción deberá estar incluida en un método de validación. Para añadir dicho método, es necesario añadir una partial class para cada clase afectada. El hecho de incluir todas las partial class en el mismo fichero o en ficheros separados es indiferente a efectos de los resultados obtenidos, pero sí se puede tener una mejor organización de los distintos errores si se separa en varios ficheros. En nuestro caso, los tres primeros tratan sobre las restricciones de tres clases distintas (Fact, Base y DegenerateFact, respectivamente), mientras que en el último hemos englobado 5 clases (todos los Attributes), ya que las restricciones a las que nos referimos son las mismas (sobre los atributos derivados). Los ficheros son los siguientes:  AggregationCardinality.cs. Trata sobre las restricciones relacionadas con las cardinalidades de la relación Aggregation, entre una clase Fact y una clase Dimension. Como dicha relación comienza siempre desde un Fact, será dicha clase la que se modifique con una partial class.  Base.cs. En este fichero se especifican todas las restricciones referentes a la clase Base. Al igual que en el anterior, los conectores entre bases también tienen cardinalidades, por lo tanto habrá que añadirle dicho método. Además, incluimos las restricciones sobre los roles +r y +d, la restricción que obliga a tener un DescriptorAttribute y la restricción de tener como mucho un OID Attribute.  DegenerateFact.cs. En este fichero establecemos la restricción de la clase DegenerateFact que especifica que debe estar conectado tanto a un Fact como a una Dimension.  DerivedAttributes.cs. Trata sobre las restricciones relacionadas con los atributos derivados. Se incluyen 5 partial classes en este fichero:
  68. 68. Lenguaje de Especificacion del dominio para un Modelo Multidimensional Orientado a Objetos Proyecto de fin de carrera de Enrique Catala Bañuls y Vicente Soriano Claver Año académico 2005-2006 68 DegenerateDimension, FactAttribute, OID, Descriptor y DimensionAttribute. Pasaremos a explicar en detalle cada una de estas restricciones. Añadir cardinalidades en las relaciones En el primer fichero, el AggregationCardinality.cs, se establen cardinalidades para el conector asociado a la clase Aggregation. Para conseguir esto, hemos tenido que seguir los siguientes pasos: 1. Seleccionar la relación Aggregation, darle al botón derecho y escoger la opción Show As Class. 2. En la clase que representa a la relación, añadir dos nuevos atributos de tipo String: SourceMultiplicity y TargetMultiplicity. 3. De manera opcional, en la ventana de propiedades de dichos atributos ponerles un valor por defecto en el campo Default. 4. Ejecutar el DslDm2Dd, y en la ventana de Text Decorators seleccionar la posición donde queremos que aparezcan nuestras cardinalidades (recordar que las posiciones centrales aún no están implementadas).

×