Despite the strong trend for textual DSLs, graphical diagrams and even editors are still popular. It is just easier to see the connections in a component diagram than trying to figure them out from a textual representation (though it is not necessarily easier to edit them graphically).
DSLs for graphical editors
Although the APIs for graphical editors are becoming more powerful and more easy to use (e.g. with Graphiti), they still require a lot of implementation effort. With the availability of textual DSL tooling, a solution to this problem is to provide a textual DSL for the graphical editors. On Eclipse, two of these projects would be Spray for Graphiti editors and EuGENia for GMF editors.
Lost art of the ancients: StP
It is good to have these projects, since the Eclipse platform is the current tool integration platform of choice. On the other hand, it is also a pity to me to see what we once had and what has to be “redone” again: In the late 90s and earls 2000s, one of the better known UML case tools was “Software Through Pictures”, later rebranded to “Ameos”. But it was more just an UML tool. The entire product was based on a textual DSL to specify graphical diagrams, tabular editors and property sheets.
Since StP supported the later UML 1.x and early 2.x versions, Booch, OMT and other diagrams, it was quite powerful and able to deal with a lot of cases. It is a good inspiration for anyone looking to design DSLs for the specification of graphical editors.
But the company that was responsible for the tool (Aonix at that time), decided not to invest in further development. Luckily, a spin off of that company called ScopeSet managed to get the tool into open source to be able to support users. Although I would consider the tool outdated, its DSLs are worth studying. It can be downloaded at www.openameos.org. If you are interested in the DSL without installing the tool, google for “stp customization manual”. It is from 1998 and not up to date for the latest tool version, but it gives a good impression of the DSLs.
- IMES DSL
In the public funded research project, we defined a DSL for our Graphiti editors (Spray! was not published when we started). Because of my long time background with Ameos, it was built upon my experiences with that tool.
- Line 16 defines a diagram. Much of the information is for generating the Graphiti infrastructure. “Extension” specifies the file name extension for diagrams of that type
- Line 18: Diagrams are attached to model object. In this case, we attach to an Autosar ARPackage. That will result in a “New Diagram” pop up menu to be added to the Eclipse project explorer for Autosar packages. New Diagrams will be initialized with nameFunc, which is a Xtend2 expression that is evaluated.
- Line 23: Our first symbol is for Autosar Composition Type.
- Line 24: The attribute specifies which attribute should be taken for the label of the symbol. This is just a convenience field. More complex operations are possible with Xtend2 (see below).
- Line 26: The shape to be drawn. We did not spend any effort for a Shape DSL – that is often just implemented in Java with similar effort
- Line 29: The context specifies that we can directly place this on the diagram. The objects will then be added to the ctx.elements colleciton of the diagram’s object (again, a Xtend2 expression with full content assist support)
- Line 33: The other symbols, a Component Prototype (in UML, you’d call this a “part”)
- Line 34: The label expression is more complex.
- Line 37: We can use this symbol in different contexts. Depending on the context, it is put / taken from different collection. Note that we do not have any forced relationship between graphical containment and domain model containment. That would not be sufficient for most more complex meta-models (Autosar, UML, EAST-ADL)
- Line 109: We want to be able to drag a software component into another and create a prototype.
- Line 110: The convert function (Xtend2!) specifies how to create the prototype from the dragged object.
- It is not sufficient, to map connections to EReferences. In most sophisticated meta-models, a graphical connection is mapped to complex data structures. In our DSL, we can specify what to do after a connection is created with Xtend2 structures.
DSLs for graphical editors are currently getting a lot of attention. If you want some inspiration, look at the existing projects mentioned above and don’t forget to get inspired by StP.