Máster MNTI Desarrollo Dirigido por Modelos. Seminario 2 - Sintaxis concretas gráficas

Transcripción

1 Máster MNTI Desarrollo Dirigido por Modelos Seminario 2 - Sintaxis concretas gráficas Grupo Modelum Universidad de Murcia 16 de noviembre de 2010 Resumen En el transcurso de esta sesión aprenderemos a utilizar GMF, un framework sobre Eclipse que nos servirá para crear DSL gráficos. No pretendemos enseñar la herramienta de forma exhaustiva, pues esto involucraría varias sesiones, sino simplemente que se conozca el modo de trabajar con GMF, así como adquirir las nociones necesarias para crear DSL gráficos sencillos. Explicaremos el proceso de creación de un DSL gráfico con GMF, basándonos en el ejemplo del DSL de menús que se ha trabajado en sesiones previas. 1

2 1. Introducción Graphical Modeling Framework (GMF) es una herramienta que proporciona un puente generativo entre Eclipse Modeling Framework (EMF) y Graphical Editing Framework (GEF), que puede ser utilizado para construir DSL gráficos sobre la plataforma Eclipse. Se trata de una herramienta en proceso de evolución, cuya versión actual es la 2.3. Construir un DSL con GMF a partir de un metamodelo o modelo de dominio significa definir una serie de modelos que representan la información de diversos aspectos de la interfaz y del código Java del DSL. Dado que crear un DSL gráfico desde cero como el DSL del ejemplo de menús puede ser en cierto modo complicado para el usuario inexperto, partiremos de un DSL ya construido que completaremos a lo largo de la sesión. Por lo tanto, en las siguientes secciones guiaremos al lector en el desarrollo con GMF basándonos en el ejemplo de los menús. 2. Creación de un nuevo proyecto Para crear un nuevo proyecto de GMF, seleccionaremos F ile N ew Graphical Modeling F ramework New GMF P roject o de un modo más rápido Ctrl + N Graphical Modeling F ramework New GMF P roject. Asignaremos al proyecto un nombre y marcaremos la casilla para mostrar la vista Dashboard. Se creará un proyecto Java de plugin para Eclipse. En la carpeta model del proyecto creado, será donde albergaremos los modelos que GMF necesita. Figura 1: Vista Dashboard Al crear un nuevo proyecto GMF, habitualmente se abrirá la vista Dashboard que se muestra en la Figura 1. Esta vista nos guiará en el proceso de desarrollo. Si no se abre dicha vista, podremos hacerlo manualmente con W indow Show V iew Other General GM F Dashboard. Los seis modelos implicados en el proceso son: el modelo de dominio (Domain Model) o metamodelo, que constituye la sintaxis abstracta del DSL expresada en Ecore; el modelo de definición gráfica (Graphical Def Model) que define la sintaxis concreta o notación del DSL gráfico; el modelo de herramientas (Tooling Def Model) que se utiliza para indicar los elementos de la paleta de herramientas del editor visual; el modelo de correspondencias (Mapping Model) permite relacionar los elementos de los tres modelos anteriores; el modelo de generación del dominio (Domain Gen Model) se utiliza para modificar aspectos relativos a la generación de los plugins del editor de modelos en árbol generado a partir del metamodelo; y el modelo de generación del editor de diagramas (Diagram Editor Gen Model) que se genera a partir de los anteriores e incluye información 2

3 relativa a la generación del plugin del editor del diagrama. De los seis modelos indicados, los dos modelos relativos a la generación de los plugin se obtienen automáticamente a partir de otros modelos y habitualmente nos servirán sin necesidad de modificarlos o tras la realización de pequeños cambios. El modelo de dominio suele haber sido creado paso previo a la construcción del DSL, por lo que el mayor esfuerzo de desarrollo con GMF se invierte en la definición de la sintaxis concreta en el modelo de definición gráfica, y en las relaciones entre sintaxis abstracta y concreta definidas en el modelo de correspondencias. En el caso de disponer de alguno de los modelos ya creados, seleccionaremos en la vista Dashboard los modelos de que dispongamos, para lo cuál utilizaremos la opción Select correspondiente Tareas 1. Crear un nuevo proyecto GMF con nombre MenuDSL. 2. Copiar los modelos del DSL ya construido en la carpeta model. 3. Seleccionar cada uno de estos modelos en la vista Dashboard Resumen de comandos File New Graphical Modeling Framework New GMF Project Crear un nuevo proyecto GMF 3. Probando el DSL inicial Una vez se han construido los modelos que requiere GMF, ya estamos en disposición de generar el código del DSL. Para ello, seleccionaremos la raíz del modelo de generación del dominio y mediante las opciones Generate Model Code, Generate Edit Code, y Generate Editor Code del menú contextual obtendremos el código (generado por EMF) indicado en la Cuadro 1. El código del modelo se almacena en el directorio src del plugin que contiene los modelos. Qué genera Código del modelo Plugin edit Plugin editor Qué contiene el código generado Interfaces e implementación de los elementos del metamodelo Código del editor de modelos independiente de la interfaz de usuario Código del editor de modelos totalmente funcional en Eclipse Cuadro 1: Plugins generados a partir del modelo de generación del dominio (EMF) También es necesario obtener el plugin que genera el editor visual, para lo cuál seleccionaremos la opción Generate Diagram Editor del modelo de generación del diagrama en la vista Dashboard. De este modo, tendremos los cuatro plugins necesarios para el DSL. Para probarlo, arrancamos una nueva instancia de Eclipse que incluya esos plugins, lo cuál se hace seleccionando la opción Run Run As Eclipse Application. En la instancia de Eclipse que se abre, crearemos un modelo mediante el DSL. Para ello, creamos un nuevo diagrama mediante F ile New Example. En la Figura 2 se puede observar un ejemplo de modelo creado con este DSL. Si la hoja de propiedades no se mostrase, seleccionar W indow Show V iew Other General P roperties. Para probar las restricciones implementadas, seleccionar la opción Edit V alidate. En la vista Problems aparecerán las restricciones violadas. 3

4 Figura 2: Modelo de ejemplo creado con el DSL gráfico de menús 3.1. Tareas 1. Generar las clases del modelo en el plugin MenuDSL y los plugins MenuDSL.edit y MenuDSL.editor. 2. Generar el plugin MenuDSL.diagram. 3. Copiar la carpeta icons al proyecto MenuDSL. 4. Reemplazar los iconos de los directorios MenuDSL.edit/icons/full/obj16/ por los nuestros. 5. Probar el DSL creando un modelo Resumen de comandos Run Run As Eclipse Application Abrir una nueva instancia de Eclipse con los plugins creados File New Example Crear un nuevo modelo usando un DSL (ruta por defecto) Window Show View Other General Properties Mostrar la hoja de propiedades 4

5 Window Show View Other General Problems Mostrar la vista de errores Edit Validate Validar un diagrama 3.3. Modificación del DSL construido En las siguientes secciones veremos cómo modificar el DSL existente para incorporar un nuevo nodo que representará los pares de traducción (para la internacionalización) y un nuevo tipo de relación para representar la asociación entre pares de traducción y menús. También incorporaremos restricciones sobre estos elementos. El fragmento del metamodelo implicado se muestra en la Figura 3. Figura 3: Fragmento del metamodelo que incluye los pares de traducción 4. Definición de la sintaxis concreta El modelo de definición gráfica (Graphical Def Model) se utiliza para definir la sintaxis concreta del DSL. Los ficheros de los modelos de definición gráfica tienen la extensión gmfgraph. GMF incorpora un sencillo asistente que nos crea un modelo de definición gráfica por defecto a partir del metamodelo. Mediante la opción Derive de la vista Dashboard se abre dicho asistente que nos solicitará un nombre y localización para el modelo, y nos pedirá que indiquemos cuál es el elemento raíz del metamodelo. Como se muestra en la Figura 4, el asistente finalmente nos requerirá que indiquemos qué elementos del metamodelo deseamos que sean tratados como nodos del diagrama, como relaciones o como atributos. Al finalizar se creará el fichero menuprofile.gmfgraph que tendrá un aspecto similar al de la Figura 5. En este modelo identificamos dos partes fundamentales: por una parte las declaracion de los elementos de la notación gráfica tales como nodos (Node), compartimentos (Compartment), conectores (Connection) y etiquetas (Diagram Label), y por otra la galería de figuras. En la declaración de los elementos se definen aquellos elementos que posteriormente se enlazarán a los elementos de la sintaxis abstracta en el modelo de correspondencias. La galería de figuras permite la definición de éstas de un modo independiente a los elementos de la notación, de modo que es posible asignar una misma figura a diferentes elementos de la notación gráfica. El concepto principal de la galería son las figuras, que aparecen representadas en los elementos Figure Descriptor. Además de las figuras, en la galería se pueden encontrar otros elementos, como por ejemplo los decoradores de líneas (Polyline Decoration), que pueden ser reutilizados por las figuras. 5

6 Figura 4: Asistente de creación del modelo de definición gráfica Entre los diferentes elementos que podemos crear en los Figure Descriptor del modelo, tales como la forma de la figura o el color de fondo la figura, destacamos el elemento de tipo Child Access. Cuando deseemos crear una figura que contenga etiquetas, tendremos que crear un elemento de este tipo para cada una. Esto es necesario para poder modificar las etiquetas que se encuentran contenidas en dicha figura. Los elementos del modelo se pueden modificar mediante la vista de propiedades. Si esta vista no está abierta, se puede abrir con W indow Show V iew Other General P roperties. Para crear un nuevo elemento en el modelo, se selecciona el nodo padre del nuevo elemento y mediante la opción New Child del menú contextual se selecciona el nuevo nodo a crear. La opción New Sibling permite crear un nodo hermano en el árbol que representa el modelo. Para borrar un nodo, basta con seleccionar la opción Delete del menú contextual sobre el elemento. Una vez modificado el modelo de definición gráfica, es necesario seleccionar la opción Validate del menú contextual sobre el elemento Canvas para comprobar que el modelo es válido Tareas 1. Analizar el modelo de definición gráfica propuesto, con el fin de conocer los diferentes elementos que se pueden crear en el árbol, así como los distintos tipos de figuras disponibles y sus posibles atributos. 2. Tomando como ejemplos los nodos creados en el modelo, modificar el modelo para dotar de notación gráfica a las instancias de la metaclase TranslationPair que podrían ser representadas, por ejemplo, mediante una elipse amarilla. 3. Definir una notación gráfica para una etiqueta asociada a los nodos de tipo TranslationPair, que denominaremos TranslationString. 4. Asignar una notación gráfica a la referencia menu de TranslationPair, como por ejemplo una línea gris discontinua. 5. Asegurarse de que el modelo es válido. 6

7 Figura 5: Modelo de definición gráfica del DSL de menús 4.2. Resumen de comandos Window Show View Other General Properties Mostrar la hoja de propiedades GMFGraph Editor Validate Validar un modelo 5. Definición de la paleta de herramientas del editor El modelo de herramientas (Tooling Def Model) es el modelo empleado para definir las herramientas que nos permiten crear elementos en el diagrama, tales como las paletas de herramientas, barras de herramientas o las acciones de menú. Los ficheros de los modelos tienen la extensión gmftool. La definición de este modelo es bastante sencilla, y es posible que no sea necesario modificarlo manualmente, dado que el asistente de creación del modelo que permite especificar para qué herramientas se desea crear una entrada en la paleta, crea un modelo por defecto que es posible utilizar sin cambios, como el mostrado en la Figura 6. Para crear un nuevo modelo de herramientas mediante el asistente, es necesario seleccionar la opción Derive de la vista Dashboard entre Domain Model y Tooling Def Model. Este modelo 7

8 Figura 6: Modelo de herramientas del DSL de menús se edita de un modo similar al indicado para el modelo de definición gráfica. La validación del modelo se realiza mediante la opción Validate del menú contextual aplicada sobre el elemento raíz del modelo Tareas 1. Crear un nuevo grupo de herramientas que denominaremos i18n y que se podrá enrollar y desenrollar. 2. Crear una herramienta en el nuevo grupo para TranslationPair que tendrá los iconos por defecto. 3. Crear una herramienta en el nuevo grupo para las relaciones entre TranslationPair y Menu, que usará el icono que posteriormente copiaremos en MenuDSL.edit /icons/full/obj16/menutran 4. Asegurarse de que el modelo es válido. 6. Enlazando la sintaxis abstracta y la concreta El modelo de correspondencias (Mapping Model) permite relacionar el modelo de dominio (sintaxis abstracta), con el modelo de definición gráfica (sintaxis concreta) y el modelo de herramientas. Los ficheros de los modelos tienen extensión gmfmap. Al igual que con los modelos anteriores, existe un sencillo asistente que permite especificar qué elementos son nodos y qué elementos son relaciones, y en base a esta clasificación genera un modelo por defecto. El modo de edición y de validación de este modelo es similar al de los modelos anteriores. Como se puede observar en la Figura 7, en este modelo encontramos principalmente tres tipos de elementos: las correspondencias de nodos contenedores (Top Node Reference), las correspondencias de enlaces (Link Mapping) y los contenedores de reglas (Audit Container). Los nodos contenedores (Top Node Reference) son aquellos nodos que pueden ser creados directamente en el diagrama y que no estan contenidos en otros nodos. Estos elementos se identifican en el metamodelo porque están contenidos en la metaclase raíz mediante una agregación. Un nodo contenedor contiene una correspondencia de nodo (Node Mapping), que puede a su vez contener otras correspondencias de nodos y que podrían estar asociadas a correspondencias de compartimentos(compartment Mapping). Las correspondencias de nodos (Node Mapping) enlazan una metaclase del modelo de dominio, con un elemento Node del modelo de definición gráfica, y con una herramienta del modelo 8

9 Figura 7: Modelo de correspondencias del DSL de menús de herramientas. Estas correspondencias también pueden incluir correspondencias entre etiquetas (Feature Label Mapping). Las correspondencias entre enlaces (Link Mapping) se utilizan para ligar una metaclase o una referencia del modelo de dominio, con un conector (Connection) del modelo gráfico y con una herramienta del modelo de herramientas Tareas 1. Establecer las correspondencias entre modelos para la metaclase TranslationPair. 2. Establecer las correspondencias entre modelos para la referencia menu de la metaclase TranslationPair. 3. Estableceremos las correspondencias entre modelos para la etiqueta TranslationString, de modo que dicha etiqueta mostrará el valor de los atributos language y translatedstring de la metaclase TranslationPair. Para realizar utilizaremos los valores de las propiedades mostradas en la Figura Asegurarse de que el modelo es válido. 7. Incorporación de restricciones Cuando se elabora un metamodelo, existen restricciones que no es posible especificar en el mismo. Como se puede observar en la Figura 7, en GMF estas restricciones se expresan en el modelo de correspondencias de varios modos: 9

10 Figura 8: Propiedades de la etiqueta TranslationString El elemento LinkContraints nos permite especificar restricciones de conectividad entre nodos. El elemento Audit Container nos sirve como contenedor de restricciones (Audit Rule) que se pueden aplicar a cualquier tipo de elemento. Las restricciones pueden ser expresadas mediante OCL, código Java o expresiones regulares. Para las restricciones Audit Rule, que son las que contiene un Audit Container, es necesario expresar a qué elemento se aplica la restricción, mientras que en el caso de Link Contraint, la restricción va asociada a un Link Mapping. En el Anexo A se incluye una referencia rápida de OCL para escribir restricciones en GMF Tareas 1. Definir una restricción semántica que asegure que todos los menús están internacionalizados. La restricción se expresará en OCL. 2. Definir una restricción semántica que asegure que no existe más de una traducción en el mismo lenguaje para un mismo menú. La restricción se expresará en OCL. 3. Asegurarse de que el modelo es válido. 8. Ajustando la generación del plugin del diagrama El modelo de generación (Diagram Editor Gen Model) se obtiene a partir del resto de modelos y permite modificar información relativa a la generación del plugin que implementa el editor gráfico del DSL. Es un modelo con una estructura menos legible que los anteriores, al que habitualmente sólamente tendremos que realizar cambios puntuales. En este apartado mencionaremos los cambios que es necesario aplicar en este modelo para que el diagrama tenga el aspecto y funcionalidad deseados. Es posible cambiar la extensión de los diagramas modificando el atributo Diagram File Extension del elemento Gen Editor Generator. Cuando se utilizan compartimentos, es posible indicar que los elementos que se crean dentro del compartimento se muestren apilados uno encima de otro. Para esto modificaremos los elementos Gen Compartment que son hijos del elemento Gen Diagram. Es necesario modificar el atributo List Layout y ponerlo a true. Para que funcione la validación de restricciones, es necesario activarla. Para ello seleccionaremos el elemento Gen Diagram y modificaremos los siguientes atributos: Validation Decorators debe estar a true. Validation Enabled debe estar a true. Validation Decorator Provider Priority debe estar a medium o high. 10

11 8.1. Tareas 1. Modificar el modelo para que los elementos en los compartimentos aparezcan apilados. 2. Cambiar la extensión del fichero del diagrama a menudgr. 3. Activar la validación en el diagrama. 4. Asegurarse de que el modelo es válido. 9. Personalizando el código generado El editor del DSL gráfico puede ser personalizado mediante la edición del modelo de generación y mediante la modificación del código de los plugins. Como ejemplo, proponemos la modificación de los iconos de los elementos gráficos y la modificación de la categoría del asistente. El aspecto del editor creado con GMF puede mejorar considerablemente si se sustituyen los iconos por defecto por los nuestros propios. Esto se puede realizar sustituyendo estos en el directorio /icons/full/obj16/ del plugin edit. También es necesario incluir en el directorio /icons/obj16 del plugin diagram los iconos que se especificaron en la paleta de herramientas. Para cambiar la categoría del asistente, analizaremos el contenido del fichero plugin.xml del plugin diagram. En este fichero se declaran las extensiones que se incorporan al entorno Eclipse para el plugin, como los menús, los editores o las hojas de preferencias. En este fichero, el fragmento relativo al asistente de creación del diagrama se muestra a continuación. <extension point="org.eclipse.ui.newwizards"> <?gmfgen generated="true"?> <wizard name=" %newwizardname" icon="icons/obj16/menuprofilediagramfile.gif" category="org.eclipse.ui.examples" class="menuprofile.diagram.part.menuprofilecreationwizard" id="menuprofile.diagram.part.menuprofilecreationwizardid"> <description> %newwizarddesc</description> </wizard> </extension> Para crear una nueva categoría sería necesario añadir un fragmento como el siguiente anidado bajo el elemento extension: <category id="es.modelum.dsl" name=" %dslwizardcategory"/> dslwizardcategory es un mensaje que tendremos que definir en el fichero plugin.properties y que será el nombre de nuestra categoría. Después de definir la categoría, modificaremos el atributo category en el código anterior para que corresponda con el identificador de nuestra categoría Tareas 1. Generar el código del modelo, y los plugin edit, editor y diagram como se indicó en la sección Sustituir los iconos por los que hemos copiado en la carpeta /icons. 3. Crear una nueva categoría de asistentes de creación denominada DSDM Course. 4. Incluir el asistente de creación de diagramas de menús en la nueva categoría y asignarle el nombre Menu DSL. 11

12 10. El resultado final Si se han seguido los pasos anteriores correctamente, nuestro DSL ya está listo para ser desplegado en el entorno Eclipse. Para ello, seleccionaremos los cuatro plugins del DSL y seleccionaremos la opción F ile Export Deployable plug ins and fragments. Crearemos los plugins y los copiaremos en el directorio /plugins de nuestro Eclipse. Reiniciamos el entorno para probarlo Tareas 1. Desplegar los plugins generados en Eclipse 2. Probar el asistente de creación del DSL 3. Crear un modelo que utilice los nuevos elementos añadidos. 4. Comprobar la sincronización entre el diagrama y el modelo en árbol. 5. Probar las restricciones implementadas sobre los nuevos elementos. 12

13 A. Referencia rápida de OCL para GMF Utilizaremos OCL como modo de expresar restricciones en GMF. Concretamente definiremos invariantes con OCL, con la peculiaridad de que no es necesario expresar el contexto dado que el elemento Domain Element Target de Audit Rule nos permite especificar a qué elemento se aplica la restricción, como puede verse en la Figura 9. Figura 9: Restricciones OCL en GMF A continuación mostramos una serie de ejemplos en los que se muestran invariantes de OCL. Téngase en cuenta que a la hora de utilizarlo para GMF, sólamente es necesario especificar la restricción en sí misma, sin el contexto y sin la palabra clave inv. context Person inv : self.wife -> notempty implies self. wife.age >=18 and self. husband -> notempty implies self. husband.age >=18 Esto significa que si la instancia Person tiene la referencia wife no vacía, entonces debe cumplirse que el atributo age de la metaclase a que referencia wife desde la clase Person es mayor que 18. También debe cumplirse que si la instancia Person tiene la referencia husband no vacía, entonces debe cumplirse que el atributo age de la metaclase a que referencia husband desde la clase Person es mayor que 18. Dicho de otro modo, la restricción asegura que si una persona tiene marido o esposa, éste/a será mayor de 18 años. context Company inv : self. employee -> forall ( e1, e2 : Person e1 <> e2 implies e1. forename <> e2. forename ) Este invariante asegura que para cada par de elementos (de tipo Person) de la referencia employee de la clase Company se cumplirá que si las clases son distintas, entonces ambos atributos forename serán diferentes. Dicho de otro modo, nos estamos asegurando de que el nombre del empleado es único. context Company inv : self. employee -> exists ( p: Person p. forename = Jack ) De este modo nos aseguramos que existe un elemento de tipo Person de la referencia employee de Company cuyo atributo forename toma el valor Jack, esto es, que existe al menos un empleado que se llama Jack. 13