Powered by GitBook

Desarrollo de DSL visuales con Sirius

Para acceder al tutorial completo, en formato PowerPoint, puede pulsar en el siguiente enlace:

Tutorial

Ficheros de ejemplo

Los siguientes ficheros son workspaces de Obeo Designer 7.0 en su versión Community

Workspace Metamodelo

Workspace DSL CBML Test

CREACIÓN DE EDITORES GRÁFICOS CON SIRIUS

“The easiest way to get your own Modeling Tool” – Sirius Team

¿Qué aporta esta tutorial?

  • Un tutorial paso a paso donde se utiliza Sirius como usuario y como especificador.
  • Con mucho texto para que pueda ser seguido sin intervención de un locutor.
  • Se puede seguir en paralelo al visto en la clase, acerca de GMF, haciendo una comparativa de prestaciones de ambas tecnologías.
  • No hay tutorial completo de SIRIUS 2 y ACCELEO 3 en la Web que funcione.

Principales dificultades

Sirius:

  • Documentación limitada. Aunque existe, no está actualizada a la última versión de la herramienta. No se actualiza las dependencias de uso de proyectos asociados. Por ejemplo los cambios en las expresiones Acceleo.
  • Muy nuevo, ningún ejemplo funcional completo actualizado a la última versión.
  • Las dudas relevantes te llevan a consultores comerciales.

Personales:

  • No tener experiencia previa con GMF.
  • Encontrar un DSL que ilustre el tutorial de manera adecuada.
  • Es una herramienta extensa con muchas opciones, complicadas de recoger en este trabajo.

Instalación SIRIUS

Alternativa 1

  • En Eclipse, pulsamos en 'Help', 'Installing Modeling Components'. Buscamos y marcamos 'Sirius' y le damos a 'Finish'.

Alternativa 2

Alternativa 3 (recomendada)

Introducción

DESARROLLO DE EDITORES VISUALES CON SIRIUS

Desarrollo de un DSL. (enfoque MDE)

Lenguaje de dominio específico

  • Centrado en un tipo de problema particular

Con notación concreta: gráfica y textual.

Con herramientas de soporte: editores y representaciones gráficas, editores textuales y validadores

  • Pretenden ser la manera más eficiente de resolver problemas específicos dentro de un dominio concreto

SIRIUS

  • La creación de editores gráficos (editores UML, rendimiento de los procesos, conceptos de negocios editoriales, etc.) son difíciles de integrar en un corto ciclo iterativo con el cliente como mucho tiempo ya menudo requieren el aprendizaje de tecnologías y marcos complejos.
  • El objetivo del proyecto Eclipse Sirius es facilitar la creación de editores basados en la representación de un DSL en un modelo de EMF (Eclipse Modeling Framework). DSL, dominio de idioma específico, es un lenguaje dedicado a un dominio de negocio con palabras clave y el formalismo. Por lo tanto, una receta con ingredientes y una serie de acciones es una conexión DSL.
  • En Sirius, a partir de un modelo de EMF, el desarrollador podrá especificar un editor, de manera completamente declarativa, para el modelo y observar los resultados en tiempo real, sin generación de código.
  • En este tutorial, vamos a detallar los diferentes pasos de la creación del modelo para el editor de la especificación con Sirius, explicando los conceptos clave asociados. Actualmente en su versión 2.0 con muchas mejoras en la gestión de los elementos gráficos.

Arquitectura

Ofrece dos entornos

Entorno de Especificación

  • Definición de espacios de trabajo creando editores gráficos como diagramas, tablas y árboles.
  • Posibilita integrar y liberar el editor creado dentro de
  • Eclipse o como una aplicación RCP.
  • Permite mejorar entornos existentes mediante especialización y extensión.
  • Proporciona feedback inmediato y es altamente personalizable.

Usuario Final – Runtime

  • Ofrece un editor de modelos, especializado y con múltiples opciones, para que puedan crear sus propios modelo, sin tener que escribir código, adaptado a las necesidades del usuario.
  • Sincronización entre los diferentes editores proporcionados.

Viewpoint (Diagramas, Tablas, Árboles, Secuencia)

  • Cada uno de los tipos de representaciones que crea el especificador sobre un DSL para que sea utilizado por el usuario final.

Proceso de Desarrollo

DESARROLLO DE EDITORES GRÁFICOS CON SIRIUS

Proceso generativo de desarrollo

Metamodelo

  • Vocabulario del negocio: conceptos, relaciones y propiedades. Sirius Spectification Workbench
  • Representaciones / Viewpoints
  • Elementos a mostrar: figuras, colores y fuentes
  • Herramientas
  • Reglas de Validación

Sirius Runtime Workbench

  • Editores de dominio específico
  • Permiten la gestión del ciclo de vida
  • Herramienta de modelado basado en: árboles, tablas y diagramas.

Modelos implicados

  • .ecore – Metamodelo EMF
  • .genmodel – Generación del código asociado al modelo
  • .odesign – Diseño de la representación gráfica y herramientas del metamodelo de Sirius
  • .aird – Representación de la instancia del modelo Sirius
  • .cbml - Fichero de ejemplo de nuestro tutorial

Un editor de diagramas CBML

DESARROLLO DE EDITORES VISUALES CON SIRIUS

Presentación de CBML

  • Vamos a crear un DSL, simple, que nos permitirá poner en práctica algunos mecanismos clave de Sirius.
  • CBML
  • Es un ejemplo real. Se trata de modelar una versión resumida de CBML, un lenguaje para dar órdenes dentro de la simulación que sirve para adiestrar tropas.
  • El modelo contiene diferentes tipos de tareas que serán asignadas a objetos según la acción a realizar. Las tareas tendrán que resolver las preguntas de las 5 W. Una tarea de petición puede requerir una tarea de información. Esta relación representa una asociación en nuestro DSL.

CBML Simplificado

Este tutorial se basa en conceptos simplificados de CBML:

  • Un comandante (actor) puede mandar una orden militar (intent).
  • Una orden militar puede ser un informe (report) o una orden (order).
  • La orden es ejecutada por un avión, buque o tanque (Object).
  • El comandante puede hacer las labores de CO, TAO…
  • La orden puede ser de ataque, apoyo o seguimiento.
  • Los informes pueden ser de identidad o de estado.

Guía de construcción

  • Diseño del metamodelo
  • Prueba del metamodelo
  • Representación gráfica de los datos
  • Creación de herramientas de edición

Diseño del metamodelo. Motivación

Presentamos el diseño del metamodelado para:

  • Usar SIRIUS como usuario.
  • Comparar las bondades de SIRIUS como creador de editores gráficos con respecto a GMF.
  • Destacar características de SIRIUS que implementaremos durante el tutorial.

Vamos a usar Obeo Designer

  • Basado en Eclipse RCP.
  • Viene preparado con todos los componentes necesarios instalados (SIRIUS, ACCELEO 3).
  • Vamos a ser usuarios de SIRIUS para definir nuestro metamodelo. Cubrimos la necesidad de utilizar SIRIUS como usuarios finales.

Creamos un nuevo proyecto Ecore Modeling

File -> New -> Other

Ecore Modeling Project

Rellenamos el nombre del proyecto

  • com.aga.iia.cbml

Establecemos el nombre del modelo de dominio (Main package name - Epackage)

La URI XML del espacio de nombres (Ns URI)

El espacio de nombres del XML del Epackage (Ns Prefix)

Usaremos la vista de diseño gráfico para crear nuestro metamodelo.

Seleccionamos el viewpoint Design

  • Un especificador ha creado la vista Design para que, como usuarios finales, podamos usar Sirius para crear nuestro metamodelo.

SIRIUS crea un modelo de dominio vacío y una serie de ficheros que gestionan la representación gráfica del modelo asociado.

Al contrario que GMF, se preocupa de tener inicializadas las variables del modelo del dominio.

La validación del proyecto es correcta desde su creación.

Se recomienda crear una clase principal que sea la principal de las clases del dominio.

  • Hacemos click en el icono Class de la paleta.
  • Hacemos click donde queramos poner la clase en el diagrama.
  • Para añadir más clases podemos basta con mantener pulsado Ctrl al insertar la clase.

Simplemente haciendo click en la clase podemos editar el nombre de la misma de manera amigable.

  • Con GMF había que ‘acertar’ para conseguir editar el nombre de la clase mediante este método.

Añadimos un nuevo atributo.

Si no lo inicializamos la ‘caja’ se vuelve de color rojo:

  • El editor creado con SIRIUS tiene implementada la validación online de los elementos del diagrama.

Para inicializar el atributo podemos escribir:

  • [Nombre_variable]: = ‘default_value’

El editor se encarga de interpretarlo y rellenar los datos en las pestaña de propiedades.

  • El especificador del editor de SIRIUS ha usado la herramienta Direct Edit Label para interpretar la etiqueta que escribimos para la clase en el diagrama.

Podemos completar los atributos de la clase en la ventana de propiedades.

  • Sirius nos ofrece una pestaña de propiedades más amigable que la ofrecido por defecto con GMF.

Si hacemos doble click en la clase para inicializarla, el editor nos proporciona una ventana de propiedades para modificar los datos amigablemente.

  • Una nueva ventaja de crear el metamodelo con Sirius.
  • Este editor es ofrecido para las clases pero no para las relaciones.

Las clases con alguna propiedad particular (como ser abstractas), las enumeraciones, los tipos de datos… se diferencia en el diagrama porque tienen un estilo de presentación diferente.

  • El especificador de este editor en Sirius ha usado los estilos condicionales para aplicar un fondo gris y otro tipo de letra al diagrama que hemos marcado como clase abstracta.
  • También ha creado un estilo condicional para los enumerados.

Para los tipos enumerados hay que rellenar cada uno de los Value de cada elemento.

  • De no inicializarlos se crean todos con el valor 0. Este es un aspecto a mejorar por el especificador ya que puede ser resuelto con una expresión Acceleo.

Como con las clases, el nombre de las relaciones se puede escribir directamente en el editor de diagramas.

Podemos escribir directamente la cardinalidad en la cadena del nombre con el formato:

[n…m] Se puede usar * ó -1 para la cardinalidad múltiple.

Una vez completado el metamodelo validamos el resultado.

En el siguiente paso, vamos a probar el metamodelo que hemos creado con datos de test.

Con este fin vamos a generar el código asociado al modelo para que sea usado por las herramientas que vamos a invocar.

Lanzamos, en este orden, sobre el .genmodel

  • Generate Model Code
  • Generate Edit Code
  • Generate Editor Code

Prueba del metamodelo

Para probar el metamodelo necesitamos crear instancias de nuestras clases y establecer relaciones entre ellas.

  • El objetivo de crear los datos de prueba es crear una representación gráfica de los datos con Sirius y estudiar alguna de las capacidades que ofrece.

Necesitamos lanzar un nuevo Eclipse para que reconozca nuestro proyecto como candidato a crear nuevo proyecto.

Accedemos al menú Run->Run Configurations.

Creamos nueva Eclipse Application llamada CBMLTest con los argumentos:

  • -Xms256m -Xmx1024m -XX:MaxPermSize=256m

Aplicamos los cambios pulsando en Apply y ejecutamos con Run.

Con esto conseguimos abrir una nueva instancia de Eclipse sobre la que vamos a trabajar.

¡ATENCIÓN! Tener siempre muy presente el metamodelo.

  • La mayoría de los errores y dudas a la hora de definir la representación gráfica del modelo se basan en no conocer el modelo creado con detalle.

Creamos un nuevo proyecto de modelado.

* File->New->Modeling Project

Elegimos el nombre com.aga.iia.cbml.demo y pulsamos en Finish consiguiendo un proyecto vacío.

Creamos el ejemplo basado en nuestro modelo pulsando con el botón derecho sobre nuestro proyecto seleccionando:

  • New->Other

Dentro de la carpeta Example EMF Model Creation Wizard seleccionamos Cbml Model.

Usamos el nombre demo.cbml y pulsamos Next.

El elemento raíz de nuestro metamodelo es el Scenario. Lo seleccionamos en la siguiente ventana del asistente y pulsamos Finish.

EMF crea un modelo que contiene una instancia de Scenario y abre un editor en forma de árbol.

Añadimos nodos que cubran todas las relaciones de nuestro metamodelo.

Validamos los datos de prueba.

Tenemos una representación en árbol que es la que ofrece por defecto el editor.

No es la más adecuada para nuestro modelo.

Vamos a crear una Viewpoint de SIRIUS en forma de diagrama para representar nuestros datos.

Representación gráfica

Vamos a crear un diagrama que permita a los usuarios visualizar y, posteriormente, editar el escenario, sus componentes y las relaciones entre ellos.

Usaremos de punto de partida los datos de prueba creados en el apartado anterior.

Creamos un Viewpoint Specification Project desde

  • File->New->Other: Viewpoint Specification Project.

Llamamos al proyecto cbml.design y pulsamos Finish.

Definimos un Viewpoint

  • Los ficheros .odesign contiene la descripción del viewpoint.
  • Los ficheros .aird guardan la representación del diagrama. Podemos crear diagramas, árboles, tablas y diagramas de secuencia. Por defecto nos ofrece la vista de tipo árbol.
  • Como queremos una vista en diagrama crearemos un nuevo viewpoint.

Sobre la carpeta cbml pulsamos con el botón derecho

  • New -> Viewpoint

Rellenamos, en las propiedades, los campos

  • Id: Obligatorio y debe ser único.
  • Label: El usuario final no verá el Id si no el Label.
  • Model File Extensión: Nombramos a nuestro fichero de ejemplo como *.cbml.
  • El icono lo dejaremos vacío.

Pulsando con el botón derecho sobre CBML Design -> New Representation -> Diagram Description creamos un nuevo Viewpoint de tipo Diagrama

Rellenamos las propiedades generales del diagrama.

  • Id: Obligatorio y debe ser único. (Scenario Diagram)
  • Label: El usuario final no verá el Id si no el Label.
  • Domain Class: El tipo del elemento raíz del diagrama. En nuestro caso, Scenario dentro de cbml (cbml.Scenario). El escenario será la pieza clave de nuestro diagrama.

¡IMPORTANTE! Estar atento a la consola de log del Eclipse principal para comprobar que no hayamos metido alguna expresión de manera errónea.

Creamos el layer por defecto sobre el que se dibujará nuestro diagrama. Un diagrama debe de contener, al menos, un layer para mostrar su contenido.

El layer por defecto representa el scenario como contenedor. Lo creamos pulsando sobre el Scenario Diagram con el botón derecho New Diagram Element-> Default Layer.

Vamos a representar los elementos relevantes del modelo en el diagrama.

Un diagrama puede representar los nodos que son instancias del modelo.

Para crear un nodo, pulsamos con el botón derecho sobre el layer creado y seleccionamos

  • New Diagram Element -> Node

Rellenamos las propiedades del elemento Node:

  • Id: Obligatorio y debe ser único. Usaremos el prefijo CD_ como nomenclátor para el ejemplo.
  • Label: El usuario final no verá el Id si no el Label.
  • Domain Class: Estamos creando el nodo para el elemento Actor.
  • Dentro de nuestro metamodelo está definido como cbml.Actor

Tenemos que mapear el nodo con los elementos de nuestra instancia. Para ello rellenamos el campo Semantic Candidate Expression con un comando Acceleo para especificar como recuperar los nodos para mostrarlos en el diagrama.

Los actores son parte del escenario por el atributo cast definido en la relación.

Usamos la sintaxis [/] y el autocompletado (Ctrl + Space) para ayudarnos en esta tarea.

La expresión es evaluada en el objeto asociado al diagrama (en nuestro caso una instancia de un escenario cbml).

  • Necesitamos definir un Style para nuestro nodo para especificar la manera en que se va a representar gráficamente el nodo en el diagrama.
  • En el caso de no crearlo la validación se encargará de mostrar un mensaje de error.
  • El estilo puede ser una figura, una imagen del sistema de archivos, un punto… En las nuevas versiones de Sirius se van mejorando y ampliando el número de posibles

  • Para el caso del actor, como ejemplo, usaremos un icono.
  • Para ello necesitamos una imagen: creamos una carpeta icons dentro del proyecto e incorporamos el fichero Actor.png.

  • Pulsamos con el botón derecho sobre el nodo Actor y mediante New Style -> Workspace Image incluimos la imagen Actor.png como representación del nodo.
  • Con este fin rellenamos el Workspace Path como /cbml.design/icons/Actor.png

  • Para terminar personalizamos la etiqueta a mostrar junto al nodo.
  • En la pestaña Label usaremos una expresión Acceleo que nos va a permitir extraer información del nodo al que está mapeado [self.name.toUpper()/]

Para poder testear esta primera versión del diagrama necesitamos crear una Representación del escenario Ataque a Melilla.

Primero validamos el diagrama, pulsando en el icono de la esquina superior derecha Validar.

Seguidamente seleccionamos en el proyecto demo el viewpoint CBML Design. Pulsamos con el botón derecho sobre el proyecto demo, seleccionamos en el menú Viewpoint Selection

Para crear la Representación, con el botón derecho sobre el proyecto demo, seleccionamos Create a New Representation del Scenario Diagram.

El resultado es un nuevo fichero en el proyecto demo (“new Scenario Diagram”) con el siguiente aspecto:

Seleccionando la imagen podemos ver sus propiedades que fueron definidas en la instanciación del ejemplo.

Completamos la representación gráfica de todos los nodos de manera análoga.

Para el nodo de tipo Objects necesitaremos una representación condicional. Los objetos pueden ser tanques, aviones o barcos. Para ello incluiremos un elemento Conditional Style y una expresión Acceleo nos permitirá evaluar que representación tomar.

Las expresiones Acceleo son:

  • [self.object =ObjectType::Aircraft/]
  • [self.object =ObjectType::Tank/]
  • self.object =ObjectType::Ship/]

En el caso de las representaciones gráficas condicionales, si queremos que nuestro .odesign valide, es necesario tener una representación del nodo por defecto.

Dentro de cada condición añadiremos un Workspace Image para cargar la imagen correspondiente según el tipo de objeto.

Aplicando las mismas técnicas añadimos la representación gráfica de los Report.

Para las órdenes (Order) vamos a usar diferentes figuras según sean órdenes de ataque (círculo rojo) o cualquier otra orden (rectángulo verde).

Una vez representados todos los nodos interesantes vamos a reflejar la relación entre ellos.

Con este fin crearemos en el layout Default, a través de pulsar en el botón derecho -> New Diagram Element -> Relation Based Edge para representar las relaciones.

Rellenamos las propiedades de la representación de la relación.

  • Id: Obligatorio y debe ser único. Usaremos el prefijo CD_ para evitar duplicidades.
  • Label: El usuario final no verá el Id si no el Label.

  • Source Mapping: El origen de la relación.
  • Target Mapping: El destino de la relación.
  • Target Finder Expression: Expresión Acceleo que soporta para la extracción de datos de la relación. Dentro de scenario el nombre de la relación es command.

Cambiamos las propiedades de la representación de la relación.

  • Lineas punteadas
  • Color azul oscuro

De la misma manera completamos la representación gráfica relacionando los Reports y las Orders con los objetos que las ejecutan.

Creación de herramientas de edición

Hasta este momento hemos creado una representación gráfica de nuestro modelo.

Actualmente la única acción que podemos llevar a cabo es la de reposicionar los elementos en el diagrama.

Para completar el tutorial vamos a crear una paleta de herramientas que permitan al usuario insertar nuevos elementos en el diagrama y se reflejen en el modelo.

Creamos una nueva sección en la capa por defecto pulsando con el botón derecho sobre ella y selecionando New Tool -> Section.

Rellenamos las propiedades de la sección:

  • Id: Obligatorio y debe ser único. Usaremos el prefijo CD_ para evitar duplicidades.
  • Label: El usuario final no verá el Id si no el Label.

Dentro de la sección creada, creamos una sección nueva Tools, de la misma manera para organizar las herramientas.

La primera herramienta que vamos a crear es la que nos permite insertar un nuevo elemento Object.

Para ello pulsamos con el botón derecho New Element Creation -> Node Creation.

Rellenamos las propiedades del Node Creation.

  • Id y Label (igual que en todos los elementos anteriores).
  • Node Mappings: Para definir qué tipo de nodo será creado debemos asociarlo a un nodo existente en el modelo. En este caso el nodo Object.
  • Como para todos los demás elementos, existe la opción de incluir un icono a su representación. En este caso en la pestaña Advanced.

Aparece en la paleta la nueva herramienta aún sin funcionalidad.

Vamos a definir las acciones que se deben llevar a cabo cuando el usuario use la herramienta de creación del nodo.

El primer paso consiste en incluir un cambio de contexto.

  • Nos permite definir en qué contexto se realizarán las acciones.

Para ello pulsamos con el botón derecho sobre Begin dentro del elemento de creación del nodo, New Operation -> Change Context.

En este caso el contexto viene definido por una sentencia Acceleo que permite a Sirius saber donde debe insertar el nodo en el elemento que sirve de base al diagrama actual (el layer representa el escenario).

Para ello usamos la variable container.

Incluimos la semántica de nuestra acción pulsando con el botón derecho sobre el cambio de contexto New Operation -> Create Instance.

Rellenamos las propiedades de Create Instance.

  • Reference Name: En nuestro metamodelo la relación entre el Object y el Scenario se llama actuators y situa al nodo en el contexto.
  • Type Name: El nombre de tipo de la instancia a crear del metamodelo.

Para completar la acción incluimos operaciones de tipo Set que nos permiten inicializar valores del elemento creado.

  • Botón derecho sobre Create Instance, New Operation -> Set y especificamos: Feature Name: El nombre de la propiedad a inicializar y Value Expression: Expresión Acceleo que refleje el valor a dar a la propiedad.

RECORDATORIO

  • Validamos la creación de la herramientas con la opción validate.

Probamos nuestra nueva herramienta.

  • Pulsamos en Object dentro de Palette.
  • Pulsamos en una posición cualquiera del diagrama.
  • Se crea un nuevo elemento Object.
  • Rellenamos las propiedades del elemento.

Necesitamos poder relacionar nuestro nuevo elemento con los demás componentes del diagrama.

Para ello vamos a crear un nuevo elemento de creación llamado Edge Creation.

  • Botón derecho sobre Section Tools -> New Element Creation -> Edge Creation.

Rellenamos las propiedades del Edge Creation:

  • Id y Label como el de todos los elementos anteriores.
  • Edge Mappings: En este campo definimos con qué elemento del diagrama vamos a relacionar nuestra herramienta.
  • Como en los demás elementos podemos añadirle un icono personalizado en la pestaña Advanced.

En los elementos que definen el Edge se definen las variables source y target. Usaremos estas variables para saber qué nodos ha seleccionado el usuario.

En nuestro caso la variable source tendrá que ser un Report o un Order. La variable target será una instancia de Object.

Vamos a definir el comportamiento que tendrá la herramienta al ser usada. Tenemos creada Performer en nuestra paleta de herramientas. Ahora necesitamos situarnos en el contexto de ejecución de la herramienta.:

  • Creamos un nuevo Change Context. En este caso el contexto será el origen: source.

  • Creamos una nueva operación Set y rellenamos sus propiedades: Feature Name: El nombre de la relación que queremos satisfacer (performedBy). ValueExpression: Expresión de Acceleo que soporta la inclusión de nuestro Objeto como realizador de la Orden.

Para llegar a este punto hemos tenido que ampliar la relación Performer para que tenga en cuenta los nodos Intent.

Los nodos Intent son los que mantienen la relación performerBy y el incluirlos en el .odesign nos va a ayudar en el proceso de depuración.

Los nodos Intent (generalización de Order y Report) no los representamos en el layer principal por no tener interés en nuestro caso.

Creamos un nuevo Layer adicional y creamos el nodo Intent dentro del mismo.

A su vez editamos la acción Performer para que, como origen, pueda tener los nodos Intent.

Para probar nuestra relación tenemos que ampliar el ejemplo de herramientas de creación.

Un Intent (Order o Report) sólo puede ser ejecutado por un Object según nuestro modelo del dominio. De la misma manera que incluimos el objeto Object incluimos el elemento Report.

Una vez incluido el elemento report probamos la herramienta Performer.

Para completar la creación del informe “Sobre volar Ceuta” nos falta que algún Actor la ordene. Creamos la relación Command para completar el ejercicio.

Llegados a este punto tenemos una herramienta que nos permite añadir elementos y relacionarlos entre ellos.

Tenemos una herramienta de usuario final, relativamente completa.

Necesitamos que la herramienta sea más versátil. Para ello, como ejemplo, implementaremos una herramientaa de usabilidad que vimos durante la definición del metamodelo con Sirius:

  • Poder editar etiquetas directamente sobre el diagrama.

Para poder editar las etiquetas directamente sobre el diagrama creamos, dentro de una nueva sección de usabilidad, un New Element Edition -> Direct Edit Label.

Rellenamos las propiedades de la edición directa de etiquetas:

  • Id y Label (como en las herramientas anteriores).
  • Mapping: Tenemos que indicar sobre qué nodo va a actuar la edición de etiqueta. Como ejemplo usamos Actor.
  • Edit Mask Variables {0}: Nos permite capturar el valor escrito por el usuario. Se puede modificar según nuestras necesidades y puede ser usado en clases más complejas. Como vimos creando el modelo con Sirius aceptaba la cardinalidad en la edición del nombre de las relaciones.

Creamos un nuevo cambio de contexto. En este caso el Browse Expression es[self/]. Vamos a cambiar la etiqueta del mismo elemento.

Creamos una operación de Set para establecer el nombre con el argumento capturado (la entrada del usuario).

Ya podemos cambiar la etiqueta, sobre el diagrama, de nuestros nodos de tipo Actor.

Como ejemplo cambiamos Felipe VI por JC I.

Existen otras muchas herramientas de ayuda a la edición:

  • Reconexión de relaciones.
  • Borrados con condiciones complejas.
  • Comportamiento en la acción de pegar.
  • Arrastrar un elemento dentro de otro. Puede ser la forma de crear una relación.

Resultado Final

Conclusiones

Sirius es una alternativa real – No es vaporware.

Es muy sencillo crear herramientas personalizadas con Sirius. Tiene una gran potencia y muchas capacidades.

El haber liberado el producto está permitiendo mejorar rápidamente.