DSL Tools practico

Cambio de residencia

2008-04-08T13:45:00.002+02:00

Hola amigos, me cambio de residencia aqui al lado, donde voy a comenzar a postear tambien sobre DSL Tools en Visual Studio 2008.

Mi nueva residencia: http://ecatalab.blogspot.com

Nos vemos en el otro lado!

Acceder al modelo desde el CommandSet

2006-04-29T23:51:00.001+02:00

Es posible que se quieran añadir nuevas funcionalidades al proyecto, como por ejemplo una nueva opción de menu contextual cuando clickeamos con el boton derecho en el modelo o en alguno de sus elementos. No voy a explicar como se hace esto, porque está bien descrito en los ejemplos del manual de Noviembre de 2005, pero sí explicaré como acceder a los elementos del modelo.

Es muy sencillo, pero hay que saberlo. En el ejemplo de añadir un nuevo elemento del menu, hay que modificar el archivo CommandSet.dslddt y, por lo tanto, el generado CommandSet.cs. En este archivo podemos encontrar un objeto interno llamado CurrentData. Pues bien, este es el que nos va a permitir acceder a nuestro modelo. Y para ello hay que acceder a través de la propiedad Store.

Por ejemplo, si tenemos una clase en nuestro modelo que se llama Clase1, y queremos obtener todas las instancias de esa clase que hay en el fichero actual, tendremos que escribir lo siguiente:

IList listaClases=this.CurrentData.Store.ElementDirectory.GetElements(Clase1.MetaClassGuid);

Y listo! Te las devolverá en forma de IList.

Hay que recordar que no estamos en el proyecto del DomainModel, por lo que habrá que especificar toda la ruta o bien hacer un using del proyecto del DomainModel para que reconozca la clase Clase1.

Estado actual del proyecto

2006-04-20T23:36:00.001+02:00

Este post es simplemente para que sepais que el proyecto sigue adelante y que no esta muerto el blog. Llevamos muchos dias sin poner ninguna entrada pero no estamos parados ni mucho menos. Estamos con la fase de generacion de código y hemos preferido esperarnos a poner posts relativos a este proceso porque mientras estabamos con ello nos han ido surgiendo multitud de dudas relativas a claridad de código, reusabilidad, buenas prácticas y demás, que hacen que prefiramos esperar a tenerlo todo 100% claro para dar consejos.

El caso es que ya lo tenemos todo claro y tenemos ya 1 generacion completa y otra " a punto de caramelo", por lo que podremos hablar en propiedad y sobre todo desde un prisma muy diferente al que pudieramos haber hablado hace unas semanas cuando empezamos con esta fase y aún no teniamos mas que la ayuda de las dsl tools y ninguna práctica.

Prepararos pues, para recibir en breve una oleada de posts relativos a la generacion de código de forma automática desde nuestro modelo y lo que es mejor, a como abordar de la mejor forma esta tarea. No os asusteis, os llevareis una grata sorpresa al ver la potencia que tiene la herramienta, creedme ;).

Sobre los iconos transparentes

2006-04-10T13:12:00.001+02:00

Puede que si hemos intentado insertar un icono personalizado en el toolbox o en una shape, nos hayamos encontrado con que el icono ha aparecido transparente. El tema de los iconos está todavía en fase de pruebas, y hay bastantes bugs en relación a ellos (ver página de microsoft de bugs de las dsltools).

Por el momento, si nos sucede esto podemos hacer un 'pequeño apaño'... Por lo que he podido comprobar, aparece transparente unicamente cuando pintamos de negro un icono, si en lugar de negro usamos el gris esto no sucede. Por lo tanto basta con repasar el icono con un gris muy ennegrecido, lo suficiente como para que no se note que es gris. Yo lo he intentado dandole valores RGB (10,10,10) y funciona. Basta con salvar los cambios en el archivo de Resources y ¡ahí tendremos nuestro icono!

Iconos en las compartment shapes

2006-04-10T12:17:00.002+02:00

Como ya es sabido, hay tres tipos de Shapes que podemos darle a una clase

Geometric Shape: forma geométrica predefinida (rectángulo, rectágulo redondeado, elipse, círculo o diamante)
Image Shape: imagen de un archivo
Compartment Shape: forma geométrica (rectángulo o rectángulo redondeado) con otras clases embebidas como atributos

La cuestión es que no podemos tener Compartment Shapes representadas como imágenes de un archivo. Sin embargo podemos incluir una pequeña imagen en alguna zona del rectángulo. Podemos intentar hacerlo con la herramienta de Modelisoft, pero es muy probable que nos salga alguna excepción. Tal y como explican en su página, los iconos en las Shapes aun no están implementados (ver en el Walkthrough, la parte de More Information), pero sin embargo podemos hacer que aparezca con unos pequeños cambios.

Partiendo del ejemplo de 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.

Vamos siguiendo los pasos del asistente, hasta que llegamos a la parte de los Icon decorators, le damos al boton señalado con un + en la zona donde queremos poner nuestro icono, y lo seleccionamos del menu contextual que sigue.

Con la parte Always Visible marcada, le damos a aceptar y continuamos hasta que finalizamos el asistente. Salvamos el Designer.dsldd y volvemos al visual.

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:

Bien, pues tal y como nos dicen, lo único que nos falta es agregar el icono en el fichero de Resources, en Designer\Diagram\Designer.Resource.resx. Detenemos la depuración y nos vamos a este fichero, y una vez allí seleccionamos la pestaña de images. Allí están los dos iconos de la toolbox, tenemos 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 decian en el diálogo de error.

Una vez ya está añadido, ya podemos volver a depurar y ver como aparece el icono para cada nueva Shape que añadamos.

Sintaxis de color en plantillas de generacion de código

2006-04-06T00:13:00.001+02:00

Bueno, voy a poner un breve post de como utilizar la .dll de Modelisoft que nos provee de sintaxis de color en nuestras plantillas de generacion de código.
No se si habeis comenzado con la etapa de generacion de código, pero algo que se hace realmente pesado es programar sin la sintaxis de color, sobre todo porque el código esta lleno de tags y debido a que los caracteres de retorno de carro se vuelcan sobre el fichero de salida, hemos de tener especial cuidado y tenerlo todo al mogollon. Por eso nos viene bien conocer la extension que nos propone Modelisoft.

Los pasos son bien sencillos:

1) Descargarnos el .zip con la .dll
2) Modificar si es necesario el archivo install.bat que viene con el, para que apunte a la ruta correcta (en nuestro caso por ser español, lo tendremos en Archivos de programa...
3) Todas aquellas plantillas de generacion de código que queramos tener coloreadas, han de tener la extension .t4 o .ReportTemplate

Tan simple como esto, ahora ya podemos programar de una forma mas "vistosa" y amigable.

Como depurar en la plantilla de generacion de codigo

2006-04-04T21:27:00.002+02:00

Uno de los problemas mas comunes a la hora de ponernos con la generacion de código es la Navegabilidad dentro de la propia plantilla de generacion de código. Es decir, como hacer los bucles foreach, como nos movemos entre clases, qué propiedades tenemos accesibles,...
Todo esto en principio nos puede parecer trivial, puesto que hemos estado mucho tiempo modelando el diseñador, pero cuando tenemos algo puntual y sobre todo cuando nuestro modelo ya se va haciendo grande y dificil de acordarse de esos pequeños detalles, nos viene bien poder hacer breakpoints en la propia generacion de código.

Es muy sencillo, lo único que tenemos que tener presente es que lo que vamos a depurar no es la plantilla en sí, sino el código que mediante Sofware Factories se ha generado en C# a partir de nuestro fichero de template, y que generará nuestro archivo de salida. Parece lioso de entender pero si relees la frase anterior lo entenderas.

La idea general es la siguiente:

nuestroTextTemplate.Template -> codigoIntermedioC#.cs -> nuestroFicheroOutput.sql

Como veis, se hace en 3 pasos y lo que atañe a la depuracion lo tendremos en codigoIntermedioC#.cs que es el que depuraremos.

Lo que tenemos que hacer es bien sencillo:

Activar el flag debug="true" en la directiva "template"

<#@ template inherits="...ModelingTextTransformation" debug="true" #>

Importar el espacio de nombres System.Diagnostics

<#@ import namespace="System.Diagnostics" #>

Utilizar un bloque de expresion donde llamemos a la clase Debugger y hagamos un Breakpoint

<# Debugger.Break(); #>

Ahora, cuando pongamos el bloque "Expression", al guardar o darle al boton "GenerateAllTemplates", podremos pararnos en aquel punto marcado por nosotros. Pero recordad que lo que vereis sera el código C# intermedio generado mediante Sofware Factories.

Voy a poner un ejemplo de una prueba de plantilla de generacion de código simple con un breakpoint y luego parte de lo que veriamos en el Visual Studio con el debugger:

<# Debugger.Break(); #>
<# foreach(Clase clase in this.Esquema.classRole) { #>
<#=clase.Name#>
<# } #>

Aqui podemos ver una captura en plena depuracion:

Soft Constraints. Añadir cardinalidades a las relaciones

2006-04-03T12:52:00.002+02:00

En nuestro proyecto necesitabamos algunas relaciones que indicaran restricciones de cardinalidad (uno a uno, muchos a muchos...). Para hacerlo, hemos seguido estos pasos:

1. Seleccionar la relacion, darle al botón derecho y escoger la opción 'Show As Class'
2. En la clase que representa la relacion añadirle dos nuevos atributos de tipo String, SourceMultiplicity y TargetMultiplicity.

3. (opcional) En la ventana de propiedades de estos atributos, ponerle 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 aun no están implementadas).

5. Para la validacion de estas restricciones, hay que escribir algo de código. Al ser una soft-constraints, vamos a crear una carpeta en el proyecto DomainModel llamada Validation, y dentro de ella un archivo AggregationCardinality.cs, en el que escribiremos lo siguiente:
using System; using System.Collections.Generic; using System.Text; using Microsoft.VisualStudio.Modeling.Validation; using Microsoft.VisualStudio.Modeling; namespace Proyecto.Fincarrera.ObjectOrientedMultidimensionalModel.DomainModel { ///


/// Partial class for staging the validation methods for ModelCardinality
///


[ValidationState(ValidationState.Enabled)]
public partial class Fact
{
// Ensure the cardinality is correct. Only values 0, 0..1, 0..*, 1, 1..

[ValidationMethod(ValidationCategory.Open
ValidationCategory.Save
ValidationCategory.Menu)]
private void ValidateCardinality(ValidationContext context)
{
foreach (ElementLink link in this.GetElementLinks(Aggregation.FactMetaRoleGuid))
{
Aggregation aggregation = link as Aggregation;
//Validar la multiplicidad en el origen
if (aggregation.SourceMultiplicity != "0" && aggregation.SourceMultiplicity != "0..1" &&
aggregation.SourceMultiplicity != "0..*" && aggregation.SourceMultiplicity != "1" &&
aggregation.SourceMultiplicity != "1..*")
{
string warning = string.Format(DomainModel_Resource.IncorrectAggregationCardinality, this.Name);
context.LogError(warning, "Error 01", this);
}
//Validar la multiplicidad en el destino
if (aggregation.TargetMultiplicity != "0" &&amp;amp;amp;amp;amp;amp;amp;amp; aggregation.TargetMultiplicity != "0..1" &&
aggregation.TargetMultiplicity != "0..*" && aggregation.TargetMultiplicity != "1" &&
aggregation.TargetMultiplicity != "1..*")
{
string warning = string.Format(DomainModel_Resource.IncorrectAggregationCardinality, this.Name);
context.LogError(warning, "Error 01", this);
}
}
}
}
}

Como se puede ver, es un código sencillo. Las restricciones siempre son sobre una clase, y para sobreescribirla debemos poner el public partial class. Justo encima de ella, la etiqueta
[ValidationState(ValidationState.Enabled)], para indicar que va a ser una validación, y antes del método, la parte de ValidationMethod indica los casos en los que se va a disparar la validación, en este caso al abrir, al salvar y cuando lo seleccionemos del menu contextual

Sobre el código incluido en el método, lo que hace es extraer primero todas las relaciones de agregación con this.GetElementLinks(Aggregation.FactMetaRoleGuid), donde Aggregation es el nombre de la relación. Casteamos cada link como una agregación, y entonces ya podremos acceder a sus elementos asociados, como SourceMultiplicity y TargetMultiplicity. Para mostrar el error, obtenemos el string del archivo de Resources de DomainModel (el archivo DomainModel.Resource.resx), y con context.LogError podremos mostrarlo en la ventanita de errores cuando se produzca.

Hard-Constraints. Ejemplo: evitar conexiones a uno mismo

2006-03-31T11:04:00.001+02:00

Para añadir hard-constraints, primero de nada hemos creado una carpeta llamada Custom en el proyecto del Designer, donde guardaremos todas las clases con código referente a restricciones en tiempo de ejecución.

En el archivo CustomConnectorRestrictions.cs es donde se escribirán restricciones relacionadas con los conectores entre Shapes. Este quizá en un nombre muy general, dependiendo del número de restricciones podemos tener un fichero por cada conector, o tener un fichero en el que se definan restricciones parecidas para distintos tipos de conectores, como en nuestro caso.

Vamos a ver el ejemplo en el que queremos evitar que un conector que une a Shapes del mismo tipo pueda conectar a una Shape consigo misma. En nuestro caso, esta Shape está definida en el DomainModel con el concepto de "Base", y tiene una asociación consigo misma llamada "BaseAssociatesBase".

Si no hacemos nada, cuando ejecutamos el modelo nos aparece un conector de tipo BasesAssociation en el Toolbox (o el que hayamos definido en el Designer.dsldd), que nos permite conectar una base consigo misma, como se muestra en la figura de la derecha. Para evitar esto, debemos escribir algo de código en el fichero CustomConnectorRestrictions.cs creado antes. El código se muestra más abajo. He señalado en rojo las partes que he considerado más importantes. En primer lugar, el namespace debe ser el de la ruta al que pertenezca nuestro Designer, no el de la carpeta donde tiene que estar contenido el fichero (que en este caso sería la de Custom) . Esto hay que tenerlo en cuenta porque cuando creamos un fichero nuevo dentro de la carpeta pone el namespace de la carpeta por defecto (
Proyecto.Fincarrera.ObjectOrientedMultidimensionalModel.Designer.Custom).
La clase debe ser una public partial class, y el nombre de la clase debe ser el de nuestro conector (BaseAssociatesBaseConnector), que podemos consultar en el fichero Designer.dslss, más la cadena ConnectionType. Si no se pone así no nos la reconocerá. El método para evitar conexiones con uno mismo es el segundo, el llamado CanSelfConnect. Sólo hay que devolver el valor de 'false' en el get para que no permita esto.


using System;
using System.Collections.Generic;
using Microsoft.VisualStudio.Modeling;
using System.Diagnostics;
using Microsoft.VisualStudio.Modeling.Utilities;
using System.Drawing;
using Microsoft.VisualStudio.Modeling.Diagrams;
using Microsoft.VisualStudio.Modeling.Diagrams.GraphObject;

/// Validaciones especificas
namespace Proyecto.Fincarrera.ObjectOrientedMultidimensionalModel.Designer
{
/// 
/// Extra constraints on BaseAssociatesBaseConnectorConnectionType.
/// 


public partial class BaseAssociatesBaseConnectorConnectionType
{
/// 
/// Decide whether two shapes can be created with this type of connector.
/// Called frequently as user moves mouse over candidate targets.
/// 

/// 
/// 
/// Toolip - why these can't be connected.
/// 
public override bool CanCreateConnection(ShapeElement sourceShapeElement, ShapeElement targetShapeElement, ref string connectionWarning)
{
ShapeElement realSource = ConnectorConnectAction.TopLevelShape(sourceShapeElement);
ShapeElement realTarget = ConnectorConnectAction.TopLevelShape(targetShapeElement);

if (realSource is BaseShape && realTarget is BaseShape && sourceShapeElement==targetShapeElement)
{
connectionWarning = String.Format(System.Globalization.CultureInfo.CurrentCulture, Diagram.Designer_Resource.BaseToItself, "BaseShape");
return false; 
}
else
return base.CanCreateConnection(sourceShapeElement, targetShapeElement, ref connectionWarning);
}

/// 
/// Prevent links of this type connecting back to same object.
/// 

protected override bool CanSelfConnect
{
get{ return false; }
}
}
}

Llegados a aquí ya habríamos acabado. Pero si además queremos que muestre un mensajito en forma de Tooltip cuando intentemos crear una conexion de uno a uno mismo, tenemos que añadir otro método, el CanCreateConnection. Recibe tres parámetros, la Shape origen, la Shape destino y un string llamado connectionWarning. Es este string el que nos permite mostrar el mensaje de error. Tan solo tenemos que decirle el caso en el que queremos que nos lo muestre. En el ejemplo, se mostrará cuando ambos extremos sean una BaseShape y además sean el mismo.
Utilizando el método String.Format podemos (y deberíamos) definir el mensaje de error en un fichero de recursos. En el ejemplo lo hemos hecho llamándole al mensaje de error "BaseToItself", y lo podemos encontrar en el fichero Designer.Resource.resx de la carpeta Diagram del proyecto Designer.

Sobre las validaciones y restricciones

2006-03-31T10:22:00.001+02:00

Para añadir restricciones a un modelo, hay dos formas distintas de hacerlo:

- 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 disparan determinados eventos, que seleccionamos para cada una de estas validaciones (al salvar -Save-, al abrirse un documento -Open-, al seleccionarlo en el menu emergente cuando hacemos doble-click en el diagrama -Menu-, o al hacerlo manualmente desde código -Custom-). Un mensaje en la pestaña de errores aparecerá cuando se dé una restricción, pero el usuario podrá seguir trabajando con el modelo aunque no estén todas las restricciones solucionadas

- 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 (por ejemplo, cuando se intenta conectar dos Shapes mediante un Connector). Cuando se da una restricción aparece un icono de prohibición, indicando que esa situación no puede llegar a darse.

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 se puede pasar a solucionar las restricciones, ya que con este sistema de validación podemos seguir trabajando aunque hayan partes de nuestro modelo que estén incorrectas.
Las hard-constraints no permiten modelos incorrectos, y 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 rápida y no ralentice la ejecución del programa. Un excesivo número de hard-constraints también puede llegar a resultar frustante para el diseñador, por tener que estar parando a cada paso para solucionar los problemas.

Conectores bidireccionales en referencias

2006-03-28T11:13:00.001+02:00

Pongamos que tenemos una referencia entre una clase A a otra clase B de tipos distintos. Si queremos definir un conector para esa referencia en el Designer.dsldd tenemos que definir el sentido en el que el conector será dibujado, esto es, desde un rol hasta otro. El problema es que sólo se puede definir un sentido, no ambos.

Esto constituye un problema cuando queremos que nuestro conector pueda dibujarse en ambos sentidos. Al definir un unico sentido entre roles, no nos he posible definir ambas Shapes en la etiqueta <permittedShapes> del Designer.dsldd

Si queremos que se pueda navegar desde la Shape A a la Shape B y viceversa, un posible solución es heredar ambas clases en el domain model desde una superclase ficticia (o no, si es que ya derivaban de una misma clase), llamémosla clase C, y crear un conector desde la clase C a sí misma. Gráficamente,

De esta manera ya nos es posible crear un conector que vaya de la Shape A asociada a la clase A a la Shape B asociada a la clase B, y viceversa. Solo hay que poner las Shapes permitidas en la etiqueta <permittedshapes> de Designer.dsldd

En nuestro modelo, se ha hecho este mismo cambio entre las clases Dimension y Fact:

Hemos de dar gracias a Brian, del foro de las DSL tools de Microsoft, por su ayuda en la solución de este problema. Ver aqui

Cambiar un icono de la toolbox

2006-03-24T10:59:00.001+01:00

Algo tan sencillo como cambiar un icono ya definido para una clase en el toolbox puede acarrear muchos problemas.. al menos eso es lo que me ha pasado a mi.

De alguna manera, si intentas modificar el icono con la aplicacion DslDm2Dd te lo hace, te cambia el icono, te actualiza el fichero Designer.dsldd, y cuando generas plantillas y depuras.. ¡el icono antiguo sigue ahi! Si a continuación vuelves a ejecutar el DslDm2Dd te das cuenta de que no ha cambiado..

Solo he conseguido cambiar el icono de una manera, puede que haya alguna más sencilla pero esta es la que me ha funcionado a mi. Para ello, hay 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 quieres cambiar el icono. Guardar el Designer.dsldd.
2. Volver al Visual, actualizar el fichero si te lo pide, generar templates y depurar. El icono habrá desaparecido de la Toolbox.
3. Volver a ejecutar el DslDm2Dd, y arrastrar de la parte del Domain Model el concepto del que hay que cambiar el icono a la raiz 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 a un conector llamado BaseAssociatesBaseConnector, asi que le ponemos como nuevo nombre BaseAssociatesBaseConnector2 (ver figura).

5. Seguir los pasos del asistente hasta que te pida el icono, y seleccionar el nuevo del fichero que sea.
6. Salvar, generar plantillas y depurar. El nuevo icono aparecera en la toolbox.

Siguiendo estos pasos, hemos cambiado el nombre al objeto del Designer Definition a otro distinto del que teniamos 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 teniamos en un principio)

Creando un elemento en el Designer con un nuevo nombre hace que cree un nuevo objeto y, por lo tanto, inicialice todos sus valores a los indicados por primera vez. Si intentamos actualizar debe alguno que siempre se mantiene, y no podemos cambiarle el icono. Esperemos que en las versiones posteriores se solucione este problema. Hasta entonces, y si no encontramos ninguna solución mejor, tendremos que seguir usando este metodo...

Sobre las compartment shapes y las embedding relationships

2006-03-21T10:06:00.001+01:00

Este articulo debería haber llegado antes que el de Quique de los Problemas derivados de usar palabras reservadas, ya que me hizo posible solucionar otros problemas que se dieron antes, problemas relacionados con el DomainModel y su semántica.

Antes de nada quiero destacar que es muy difícil averiguar cada una de las cosas permitidas o no en el DomainModel, no hay ninguna documentación clara al respecto, y lograr averiguar el por qué de los errores a veces se convierte en una tarea más que difícil.

Primero de nada, sobre los compartmentShapes. Para que en el Designer una clase pueda ser tratada como compartmentShape de otra, y esto gráficamente es que los elementos de una clase se representen como los atributos de otra (ver figura de la derecha-abajo), la primera debe estar embebida en la segunda (cosa bastante lógica). Por lo tanto tiene que haber una relación embebida entre ellas en el DomainModel. Además, esta relación debe cumplir otra condición, y es que la propiedad Accepts del rol de la izquierda (el triángulo) debe ser 'All', mientras que la otra (la del rectángulo) debe estar a 'None'. El sentido de esto no lo tengo nada claro todavía y no he logrado encontrar nada en la documentación, así que agradecería cualquier ayuda al respecto. Pero la cuestion es que debe ser así, de otra manera no funciona.

Después, con respecto a las relaciones embebidas. Encontré una frase en uno de los walktroughs que es de gran ayuda: it is impossible for A to embed B, when a class C already embeds B. Gráficamente es lo representado en la figura de la izquierda. En nuestro caso particular esto pasaba con el DegenerateDimension y el FactAttribute, ya que ambos estaban embebidos tanto por el Fact como por el DegenerateFact. Asi que simplemente cambié las relaciones en el DegenerateFact por referencias. Esto es solo una solución provisional, hasta que encontremos otro modelo equivalente y válido en el que podamos obtener los resultados que queremos.

Y por último, algo también importante, 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 en 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'.

Primera compilacion de nuestro proyecto!

2006-03-21T01:20:00.001+01:00

Ya compila (gracias vicen por la currada de ver y corregir las petadas de las plantillas)!!! Si sigues el post anterior, veras que es lo que he hecho para compilar a partir de la version que modificaste.

Dicho esto, voy a poner un pantallazo de la primera version compilada del ObjectOrientedMultidimensionalModel (vaya nombrecito, eh? ;).

De momento no podemos hacer conexiones entre Facts, dimensions y base clases, pero poco a poco.

Problemas derivados de usar palabras reservadas

2006-03-20T23:31:00.001+01:00

Una vez tenemos el DomainModel.dsldm completo y hemos sincronizado el Designer.dsldd (utilizando la herramienta de Modelisoft por ejemplo), llega la hora de pulsar el botoncito de "Transform all templates" , que nos generara el código C# que compilaremos para que se nos cree la libreria de nuestro Lenguaje de Dominio con la que podremos ya empezar a generar nuestro código y nuestras cosas.

Voy a exponer algunos problemas derivados de nuestro modelo de dominio en concreto.

Nuestro proyecto consiste en un Modelo Multidimensional Orientado a Objetos. Se trata de un lenguaje de modelado multidimensional para almacenes de datos. El problema que hemos tenido ha sido por la nomenclatura de nuestras clases. Aqui podeis ver la estructura de nuestro DomainModel.dsldm en la que podemos destacar cosas como la clase "Class" o "Base", cuyas relaciones llamadas "class" y "base" nos van a dar alguna que otra sorpresita desagradable.

Las palabras reservadas, no se pueden usar y eso es algo que todavia al estar en fase beta, las DSL Tools no impiden. Puesto que no se nos ha impedido, hemos podido utilizar nombres de clase como "class", "base", utilizar tipos de datos no definidos,...

Problemas de las palabras reservadas "class" y "base":

El primer problema que hemos tenido que solventar ha sido el de compilacion producido por utilizar la palabra reservada "class" en nuestro DomainModel. Esta palabra reservada la hemos utilizado en la relacion entre "Esquema" y "Class". La solucion es tan sencilla como cambiarle el nombre a por ejemplo "classRole".

Identico problema hemos tenido entre las clases "Dimension" y "Base", cuyo rol se llamaba "base" y ha sido reemplazado por baseRole.

Una vez hecho esto , tendremos que sincronizar los cambios del DomainModel, con el Designer y aplicar mas tarde el botoncito de "Transform all templates" para que nos vuelva a generar las plantillas de código y veremos otros errores distintos al compilar la solucion.

Error de tipo de datos mal definido:

Ahora veremos que los errores de antes han desaparecido y nos aparecen otros errores. Nos centraremos primero en uno un tanto extraño en el cual podemos ver que la generacion de código ha producido una línea c# no válida. Simplemente hace falta saber dónde ha sido declarada esa propiedad en el DomainModel, para darse cuenta que el error viene dado por no haber declarado correctamente sus tipos.

La propiedad en cuestion que da error al compilar es la siguiente:

private Proyecto.Fincarrera.ObjectOrientedMultidimensionalModel.DomainModel.AssociationType typePropertyStorage = Proyecto.Fincarrera.ObjectOrientedMultidimensionalModel.DomainModel.AssociationType.0;

En ella podemos ver claramente como le intenta poner a la propiedad , como nombre el número "0", lo cual es sintacticamente incorrecto y nos avisa el compilador con un estupendo error. Para arreglarlo, nos vamos a la declaracion en el DomainModel y nos damos cuenta que el error es porque tiene como tipo de datos "AssociationType" y valor por defecto 0. Si sabemos que va a ser un desplegable, pues le ponemos como tipo de datos entero y valor por defecto 0 y arreglado.

Una vez corregido esto, volvemos a transformar todos los templates y a recompilar.

Problema del caracter no válido dentro de una enumeracion:

Debido a nuestro Modelo de dominio en concreto, donde uno de los conectores tiene por nombre Rolls-upTo, al generarse los ficheros de código a partir de nuestras plantillas, ha vuelto a surgirnos un error de sintaxis.

public enum AssociationType
{
Rolls-upTo=0,
Completeness=1,
}

Como vemos, ese signo "-" es sintacticamente incorrecto y va a hacer que el compilador nos diga que esperaba un ";". Pues bien ahora hay que ir a detectar donde se ha declarado y cambiarlo. Veremos pues que en este caso se ha generado a partir de uno de los miembros de la enumeracion "AssociationType" de la que antes hablábamos porque tenia otro error y que su solucion vuelve a ser tan simple como eliminar ese signo "-".

Una vez conseguido esto, ya compila nuestro DSL y podemos hechar un primer vistazo al modelo. Claro esta, tendremos que retocarlo mas adelante pero ya tenemos un primer paso conseguido.

Sincronizar DomainModel.dsldm y Designer.dsldd

2006-03-15T22:47:00.001+01:00

Cuando escribo estas lineas, estoy utilizando el Visual Studio 2005 SDK CTP Febrero 2006, que trae las DSLTools integradas dentro de el. En esta revision de las DSL Tools existe un gran problema para el desarrollador de lenguajes de dominio, la sincronizacion del Modelo de dominio y del Diseñador grafico.

El modelo de dominio lo definimos graficamente ayudados por la interfaz gráfica que nos proporciona Visual Studio 2005. En el, desarrollamos restricciones de cardinalidad, herencias entre clases, agregaciones, conectores,...para definir nuestro Modelo de Dominio. Esta definicion gráfica, se nos genera un fichero denominado DomainModel.dsldm dentro del proyecto DomainModel. Hasta aqui todo correcto, el problema viene luego a la hora de sincronizarnos con el diseñador gráfico, que es el que van a usar los "modeladores" o personas que usaran el Lenguaje de Dominio específico que hemos creado para ellos. En esta version de Febrero de las DSL Tools no se incluye ningun tipo de diseñador gráfico para el fichero Designer.dsldd por lo que te toca editar cientos de lineas XML formateado para especificar las dependencias, formas de figuras,...es decir un lio tremendo.

Para esta tarea, de forma no oficial, la empresa ModeliSoft ha creado un programa externo que se encarga de procesar el fichero DomainModel.dsldm y permitirnos en funcion de el, que sincronicemos nuestro diseñador gráfico. Es de muy agradecer esta herramienta porque como veremos, aunque no es facil utilizar las DSL Tools en esta etapa temprana, con esta herramienta, una de las mayores pegas con las que nos podemos encontrar ahora se disipan, la sincronizacion dsldm y dsldd.

Mi intencion en este post no es hacer un tutorial de uso de la herramienta , puesto que se encuentra en la misma web antes mencionada, sino exponer los problemas con los que nos estamos encontrando al utilizarla.

El primer problema que nos encontramos es que si hacemos el DomainModel.dsldm directamente y una vez hecho abrimos la aplicacion Dsldm2Dd.exe y cargamos el archivo Designer.dsldd de nuestro proyecto, vamos a ver un terrorifico error que nos va a hacer creer que no podemos utilizar la herramienta teniendo que programar a mano el XML. Nada mas lejos de la realidad puesto que veremos como con unos sencillos cambios arreglaremos esta situacion.

Si al abrir la herramienta Dsldm2Dd.exe y cargar la configuracion de nuestro Designer.dsldd nos da un error del JIT de .NET o que no es posible realizar la carga porque parece que el archivo que intenta cargar no es un archivo dsldd válido, es porque la clase raiz, es decir, la que le dice la superficie en la que pintar (el esquema propiamente dicho donde vamos a dibujar nuestro modelo) ha cambiado y no hay relacion ninguna entre el DomainModel.dsldm y el Designer.dsldd. Para saltarnos este error y poder comenzar a trabajar con la herramienta, lo que debemos hacer es abrir el fichero Designer.dsldd y reemplazar la cadena "ExampleModel" por la cadena que identifique la clase raiz de nuestro modelo; en nuestro caso "Esquema". Una vez hecho eso y guardado veremos como ahora si que nos funcionará la herramienta y ya podremos continuar usándola.

Por ejemplo, una ocurrencia que tendriamos que cambiar seria esta:
<>
<>
<>
<>
....DomainModel.ObjectOrientedMultidimensionalModel/ExampleModel
< /class>
< /childCollections>
...
Cambiaríamos "ExampleModel" por "Esquema".

Esto es debido a que cuando comenzamos la creacion de nuestro modelo de dominio, lo que hacemos es comenzar desde un "lenguaje mínimo", y este lenguaje mínimo si que viene ya sincronizado en las plantillas dsldm y dsldd pero cuando editamos el dsldm, el dsldd no se modifica y por eso tenemos que darle una ayudita a la herramienta de Modelisoft, para que empiece sabiendo por lo menos el punto de partida o nombre del esquema.

Aqui podemos ver los dos archivos mencionados: DomainModel.dsldm y Designer.dsldd

Crear funciones para el parser

2006-03-15T01:01:00.001+01:00

Tambien llamados "ClassFeatures", con su sintaxis <#+ ClassFeature #>, nos permiten definirnos funciones para que se ejecuten en el parser antes de generar el código y podamos hacer cambios en el mismo.

Un tipico ejemplo es el de el nombre de una tabla de sql. Obviando características especiales de SQL Server como poner los nombres entre corchetes; si hacemos "create table Tabla 3", nos dara un error porque no sabe que el nombre de la tabla tiene un espacio. Pues bien, podemos hacer para que o bien nos genere los corchetes ( quedando "create table [Tabla 3]") o que nos quite el/los espacio/s en blanco (quedando "create Table Tabla3").

Optando por la segunda forma porque de paso veremos como utilizar la directiva import y el uso de clases externas, lo que habria que hacer es lo siguiente:

1) Importar el namespace System.Text.RegularExpressions

Esto se hace añadiendo al principio del template la siguiente directiva:

<#@ import namespace = "System.Text.RegularExpressions" #>

2) Definirnos en cualquier parte la ClassFeature siguiente:

<#+
private string FixWhiteSpaces(string typeName)
{
//Usa el namespace System.Text.RegularExpressions importado antes
string checkName = Regex.Replace(typeName," ","");
return(checkName.ToString());
}
#>

3) Ahora solo falta usarlo, y se usa como cualquier funcion, pero desde dentro de un bloque de sentencias <#...#>. Por ejemplo, este código es válido.

<# foreach(Table table in this.Schema.tables) { //Como vemos, cojemos el nombre de la tabla del diagrama
string nombreTabla = table.Name;
// Si el nombre de la columna contiene espacios en blanco, se los quito
nombreTabla = FixWhiteSpaces(nombreTabla);
#>

Create Table <#=nombreTabla#>
(
)

<# //Cierro el bucle foreach } #>

Esto creara ficheros como el siguiente:


Create Table Tabla1
(
)
Create Table NiNombreTabla
(
)

Para ello, los nombres de las tablas podian haberse puesto en el diagrama como " Ni NombreTa b l a", puesto que con la funcion de antes , se eliminan los espacios en blanco.

Comentarios en los Templates

2006-03-15T00:33:00.001+01:00

Para poner comentarios dentro de las plantillas de generacion de código, es tan simple como recordar que las Sentencias <#...#> son para delimitar código compilado en .net y por tanto si creamos una directiva en la cual lo unico que tenemos es un comentario, esta no se vera representada en el fichero generado.

Aqui tenemos un ejemplo de comentario.

<# // Soy un comentario y no voy a verme reflejado en el fichero de salida
#>

El problema viene porque al estar en un estado temprano, el parser de DSLTools tiene problemas con los comentarios y cree que hay Sentencias donde no las hay.

Por ejemplo:
<# /* Esto lo he comentado porque no consigo depurarlo
<#@ template debug="true" #>
<#@ import namespace="System.Diagnostics" #>
*/
#>
Aunque es sintacticamente correcto, nos da error el compilador porque el parser del template se lia con los #> y cree que hemos cerrado la Sentencia cuando realmente tendria que pasar de largo porque esta dentro de un comentario. Esto hace que lo que le de al compilador de .net sea un código no valido y por eso nos saca warnings y errores.

La solucion es obvia, para salir del paso le podemos decir que son caracteres especiales; al estar dentro de un comentario no hara nada.

<# /* Esto lo he comentado porque no consigo depurarlo
<\#@ template debug="true" \#>
<\#@ import namespace="System.Diagnostics" \#>
*/
#>

Caracteres especiales en generacion de codigo

2006-03-15T00:04:00.001+01:00

Bueno a partir de ahora voy a hablar de Templates de generacion de código y para abreviar mas aun, de Templates. De esta forma vamos a ver que para que en nuestros templates de generacion de código se nos generen caracteres especiales como las comillas " o el signo menor que "<" (por ejemplo), hemos de hacer tal y como haciamos al programar en C/C++. Es decir con el caracter especial "\". De esta forma, podremos hacer lo siguiente: <# string texto = "\"Texto entre comillas"\" #>
<#= texto #>

Con lo que se nos generara: "Texto entre comillas" (con comillas incluidas)

Problemas al depurar nuestro modelo

2006-03-14T20:42:00.001+01:00

En la version DSL Tools CTP Febrero 2006 , hay veces que al intentar depurar nuestro modelo, nos da un error bastante feo y no podemos seguir trabajando, porque en ocasiones nisiquiera nos sale el toolbox de nuestro modelo en el VS activo.

El error es como el siguiente:

"Package Enrique.Catala.Designer.DSLmodel, Catala.DSLModel.Designer, Version=1.0.0.0, Culture=neutral, PublickeyToken='b03f5f7f11d50a3a' has failed to load properly ( GUID ={8F583BC9-4E70-4888-A667-4C461AC6D3A5})."

La forma de repararlo en un 90% es haciendo uso del enlace "Reset the Visual Studio 2005 Experimental hive" que nos aparece en "inicio->todos los programas->Visual Studio 2005 SDK->2006.2".
Por si no os sale, el comando es el siguiente:

"C:\Archivos de programa\Visual Studio 2005 SDK\2006.02\VisualStudioIntegration\Tools\Bin\VsRegEx.exe" GetOrig 8.0 Exp

Esto tarda un poquito y aunque no he mirado detenidamente lo que hace en realidad, elimina de la cache de ensamblados , las .dll de nuestro modelo, nos resetea el toolbox y borra nuestras preferencias y configuraciones (recordemos que del Visual Studio Experimental, no el normal que usamos para nuestros proyectos C# por ejemplo) y asi la proxima vez que entramos, ya tenemos la posibilidad de volver a compilar el modelo y trabajar normalmente.

Estre problema aunque no he encontrado informacion exacta de porqué se produce, si que me he dado cuenta que pasa por ejemplo cuando compilamos el modelo en una máquina y luego queremos hacer lo mismo en otra máquina distinta. Esto es lo que nos esta pasando a Vicente y a mi puesto que tenemos nuestro proyecto en un servidor SubVersioN y alguno de los ficheros que tenemos sincronizado no deberia estarlo porque se ve que guarda como un GID único que identifica a la máquina y hay que resetearlo.

Espero que te sirva. Por si acaso aqui tienes algunos links con problemas y soluciones de gente a la que le pasaba lo mismo:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=100744&SiteID=1

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=260596&SiteID=1

Primeros pasos con la generacion de código

2006-03-14T00:19:00.001+01:00

Voy a poner una breve introduccion de lo que mas nos puede servir para meternos de lleno con la generacion de código utilizando DSL Tools.

Primeramente, lo que tenemos que hacer es añadir un nuevo item en el proyecto: Proyect-> Add new Item -> Template -> Text File. Una vez tengamos la plantilla, lo renombramos como queramos, por ejemplo "sqlPlantilla.sql"

En la ventana de propiedades, hemos de poner en la celda de "Custom tool" la palabra: "TextTemplatingFileGenerator", para que el generador de plantillas, utilice esta plantilla para generar código. Podemos tener tantas plantillas como queramos.

TAGS PARA LAS PLANTILLAS

Directivas interesantes:

<#@ output extension=".sql" #>

Con esto nos aseguramos que la plantilla, va a generar un archivo nombrePlantilla.sql con el código generado.
Cabeceras e inclusion de copyright y demas:
Mediante la directiva include, podemos incluir en la generacion de código, una serie de informacion externa como copyright, encabezados, pies de pagina...

<#@ include file="c:\test.txt" #>

<#@ template debug="true" #>
<#@ import namespace="System.Diagnostics" #>

Con estas dos directivas, se supone que podemos hacer depuracion en la generacion del código, justo mientras se encuentra el TextTemplatingFileGenerator en ejecucion, pero por desgracia no he podido probarlo porque me ha dado un error. Tengo que mirarlo mas en profundidad porque me interesa muchisimo.
Para poner breakpoints, basta con poner esto donde queramos pararnos:

<# Debugger.Break(); #>

Sentencias de Código:

Las sentencias de código tienen la siguiente sintaxis: <# SentenciaCodigo #>. Estas sentencias se tienen que escribir en el lenguaje que hayamos decidido utilizar para programarlas (por defecto C#) y han de compilarse correctamente, por lo que no podemos cometer errores de sintaxis, como es de suponer.

Bloques Expression

Los bloques Expression tienen la sintaxis <#= Expression #> y siren para añadir Strings al código generado en funcion de variables y/o propiedades calculadas.

Por ejemplo, esto seria un trozo de código con una sentencia de código que no se verá y un bloque Expression que si que se verá reflejado en el fichero de código que generemos.

<#
int result = 2*9
#>
<#= result #>

Lo que hara esto sera ejecutar el 2*9 mientras se encuentra el parser analizando, compilando y ejecutando nuestro template y escribir el valor de result al fichero de generacion de código. Es decir que en el fichero generado obtendriamos "18" solamente.

Sobre las cardinalidades

2006-03-13T14:30:00.001+01:00

Pienso que esto es importante a nivel conceptual:

Las cardinalidades se leen, para el caso del triangulo, según la dirección que indica (normalmente de izquierda a derecha), y en el caso del cuadrado en sentido contrario. Este es un ejemplo sacado del Walkthrough: Domain Model Designer.

Poniendo como ejemplo las distintas cardinalidades que le podriamos asignar al role 'Pages', representado como el triangulo en la imagen, vamos a explicar el significado de cada cardinalidad, y como obtenerla (valores de 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 una 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, máx y min expresan sus correspondientes valores máximos y mínimos. Para el caso de + y * es igual si pensamos que max=0 tiene el sentido de muchos.