Desarrollo de DSL visuales con Graphiti

Tecnologías relacionadas

1. Herramientas relacionadas

Existen algunas herramientas que proporcionan una infraestructura para el desarrollo de editores gráficos, facilitando el proceso y eliminado de la alta complejidad de implementaciones de este tipo.

Spray

Spray tiene como objetivo proporcionar DSLs implementados con Xtext para modificar editores gráficos en tiempo de ejecución de la herramienta Graphiti. Así se nos permite crear el código estándar para la creación de un nuevo editor que al contrario que Graphiti no lo hace, si queremos configurar nuestro propio diagrama tenemos que crear nuestras propias clases.

El código está estructurado de tal manera que siempre se puede extender/sobrescribir el código generado con manuscrito Java para agregar características Graphiti avanzadas que no son soportadas directamente por el DSL Spray. Por lo tanto en Spray se hace uso del "Generation Gap Pattern ".

Con la ayuda de las herramientas creadas con Spray, los editores basados en Graphiti se pueden crear mucho más rápido y fiable a través de los siguientes ficheros:

  • '.style'. Está centrando el comportamiento del color y formato.
  • '.shape'. Se utiliza para definir formas complejas y decorador de conexión. Todos ellos se generará a partir de unas formas ya definidas. También se configuran otros aspectos como el tamaño y la superposición de figuras más complejas.
  • '.spray'. Es el responsable de la asignación entre metamodelo de formas, estilos y comportamientos.

Graphical Modeling Framework

Proporciona infraestructura evolucionando a partir de Eclipse Modeling Framework (EMF) para la generación de editores gráficos en eclipse. Sigue un enfoque dirigido por modelos para la creación de diagramas. Ofrece un conjunto de componentes e infraestructura para el desarrollo de editores gráficos basados en EMF, como plug-ins de eclipse.

Para crear un editor gráfico, GMF necesita crear seis modelos diferentes:

  1. Domain model. El metamodelo en que se basa para crear el editor gráfico.

  2. Domain Gen Model (.genmodel). Se utiliza para generar el código del modelo de dominio con EMF.

  3. Graphical Def Model (.gmfgraph). Se utiliza para definir los elementos gráficos para el modelo de dominio.

  4. Tooling Def Model (.gmftool). Se utiliza para definir la paleta de herramientas que se pueden utilizar en el editor gráfico.

  5. Mapping Model (.gmfmap): vincula el modelo de dominio, el modelo gráfico (.gmfgraph) Y el modelo de herramientas (.gmftool).

6.Diagram Editor Gen Model (.gmfgen): se utiliza para generar el editor GMF gráfico además de el código EMF generado por el archivo genmodel.

2. Comparativa de los plugins

Para comparar los plugins vamos a tener el cuenta cuál de ellos tiene mayor funcionalidad, la documentación disponible, le experiencia necesaria para el desarrollo, la capacidad de mantenimiento y el grado de personalización para el desarrollo de editores.

Comparativa de Graphiti y Spray:

  • Spray esta basado en Graphiti, con la diferencia principal que el plugin facilita la programación en la API de Graphiti.
  • Spray a diferencia de Graphiti crea 3 DSLs distintos para crear un editor. Mientras que en Graphiti se tiene que programar los distintos ficheros basándonos en el concepto Feature.

Comparativa de Graphiti y GMF:

  • Graphitti tiene un API en Java, haciendo uso de GEF lo que agiliza el desarrollo.
  • Graphiti esconde la complejidad a expensas de la flexibilidad, mientras que GMF es más complejo de utilizar y por tanto para el primero es menor el tiempo necesario para aprender como se utiliza.
  • Graphiti dispone de ejemplos en forma de tutorial mientras que en GMF existen ejemplos y documentación disponibles pero no hay tutoriales simples.
  • GMF es más complejo pero también dispone de más funcionalidad.

2. Alternativas

Eugenia

Eugenia automatiza la generación de los modelos gmfgraph, gmftool y gmfmap de GMF, a partir de metamodelos Ecore. De esta forma, es posible generar editores basados en GMF de una manera más rápida y sencilla. Este otro plugin es muy parecido a Graphiti y también se usa en el entorno de Eclipse también. Un ejemplo de Eugenia que podemos ver en su documentación es el siguiente:

@namespace(uri="filesystem", prefix="filesystem")
package filesystem;

@gmf.diagram
class Filesystem {
    val Drive[*] drives;
    val Sync[*] syncs; }

class Drive extends Folder {}

class Folder extends File {
    @gmf.compartment
    val File[*] contents;
}

class Shortcut extends File {
    @gmf.link(target.decoration="arrow", style="dash")
    ref File target;
}

 @gmf.link(source="source", target="target", style="dot",
 width="2")
class Sync {
    ref File source;
    ref File target;
}

@gmf.node(label = "name")
class File {
    attr String name;
}

Su resultado sería el siguiente:

Sirius

Sirius, utiliza "modeladores" para crear, visualizar y editar modelos usando editores interactivos. Esta herramienta se basa en EMF para el modelado de los editores.

Según la función de las representaciones visuales, esta herramienta soporta más tipos de representaciones: diagramas (modelos), tablas y árboles (representación jerárquicas).

La principal diferencia con Graphiti es que no requiere ninguna línea de código al contrario que Graphiti para definir nuestro editor gráfico. Y además soporta mayor número de representaciones gráficas que nuestra herramienta.

Aquí, hemos encontrado un tutorial de como se crea un editor gráfico de Sirius.