Concepts for the model-driven generation of graphical editors in Eclipse by using the Graphiti framework

Fabio Filippelli1 , Steen Kollosche1 , Michael Bauer1 , Markus Gerhart1 , Marko Boger1 , Karsten Thoms2 and Jos Warmer3
1

University of Applied Sciences Konstanz (HTWG Konstanz), Department of Computer Science, Brauneggerstrasse 55, 78462 Konstanz, Germany 2 itemis AG, Am Brambusch 15-24, 44536 L unen, Germany, 3 Independent, Chalonhof 153, 3762CT Soest, Netherlands

Abstract. Domain-Specic modeling is increasingly adopted in the software development industry. While textual domain specic languages (DSLs) already have a wide impact, graphical DSLs still need to live up to their full potential. In this paper we describe an approach that reduces the time to create a graphical DSL to hours instead of months. The paper describes a generative approach to the creation of graphical editors for the Eclipse platform. A set of carefully designed textual DSLs together with an EMF meta-model are the input for the generator. The output is an Eclipse plugin for a graphical editor for the intended graphical language. The entire project is made available as open source under the name Spray. This paper focuses on the description of the textual DSLs used to describe graphical modeling languages. Keywords: Domain-Specic-Language (DSL), Model-Driven-Development (MDD), Code Generation, EMF, Xtext, Xtend, Graphiti, Spray, Eclipse IDE, Graphical Editors, Eclipse Plugin

Introduction

Eclipse has become the focus point of tooling for model driven approaches. Projects like EMF[10], CDO[8] and Xtext[4] have become very popular in the modeling community. But most of the current success in Eclipse modeling has been centered around textual modeling environments. While Eclipse can play out its textual nature very nicely for this approach, it has long been a dicult environment to build graphical modeling tools. The fundamental APIs provided by the Eclipse ecosystem, GEF[11] and Draw2D[9], are quite low level and provide no connection to the semantic level of a model. EMF has often been used for the semantic part, but oers no specic support for graphical modeling. A project that attempted to bridge the gap between GEF and EMF is GMF[12].

Concepts for the model-driven generation of visual editors in Eclipse

It suggests a model driven approach to the development of graphical modeling tools on the basis of GEF and EMF. But the models to describe the editor proved to be so complex that projects evolved to generate these models from yet higher level models. The generated code was very complex and extremely dicult to extend. The development environment was brittle and cumbersome. In this paper we present a new generative approach to graphical modeling tools in Eclipse. Instead of using GEF and Draw2D directly, we make use of a relatively new Java framework called Graphiti[13]. Graphiti provides a clean and powerful API to build graphical editors in Eclipse. It uses GEF and Draw2D but hides them completely. However, while it is perfectly possible to develop a graphical modeling tool using Graphiti, we found that the API is very adapt to generate against it from a higher level of abstraction. We have developed a set of textual modeling languages to use as input for a generator. The output is Java code for the Graphiti API as well as all other text les needed for the Eclipse plugin mechanism. The result is a graphical modeling tool in Eclipse. The paper rst describes our general approach for the model driven creation of the modeling editors and the general architecture of our framework in chapter 2. In chapter 3 we explain the denition of our own graphical elements with the corresponding DSL, followed by chapter 4 which shows our approach for the exible styling of these. In chapter 5 we review related work in the eld, mostly other tools and techniques for the generation of modeling tools. Finally we summarize the limitations and the results of our research and draw conclusions.

A Model-Driven approach for Graphical Editors

The Spray project consists of several DSLs, a generator and a runtime environment. The development environment is Eclipse with a set of plugins. All needed downloads can be found on the home page of the project, together with installation instructions. For the generator we use a Java-like language that was specically developed for the purpose of generating code text, called Xtend[4]. The runtime consists of Graphiti and a few extensions that we want to integrate into Graphiti over time. The focus of this paper is on the textual DSLs needed to develop a graphical editor, not on the generated code or the runtime libraries. The DSLs are developed using Xtext. Spray[1] currently provides three dierent DSLs - Spray Core, Shape, and Style as shown in Fig. 1. The central DSL is the Spray Core language. For simple graphical editors, this DSL alone is sucient. It denes the mapping of metamodel elements to shapes, styles and behavior. For shapes that go beyond the default rectangle shape, the Shape DSL is used. The Shape DSL allows to construct complex shapes from primitive gures like rectangles and ellipses, congures their placing, resizing policy and nesting. The style of shapes, like color and font, can be dened inline in the Shape language. But in order to reuse and centralize the denition of styles, the Style DSL allows to dene Style Classes. The role of the Styles DSL is similar to how CSS relates to HTML. Styles can be referenced from all other DSLs. Every time any of these models

Concepts for the model-driven generation of visual editors in Eclipse

Fig. 1. A Model-Driven approach for Graphical Editors

is saved, the Model-Driven Generation is executed and generates all necessary code and congurations - Java, XML and Properties - for the Eclipse Plugin. The Graphical Editor within Eclipse is than ready to use as plugin in Eclipse. These three languages are now described in detail. The Spray Core language. The most fundamental properties of a graphical editor are dened in the Spray Core language. This is a simple text le with the ending .spray. The Spray project wizard creates such a le initially with some example code. Due to the le ending the Xtext environment provides syntax highlighting, code completion and other conveniences, which makes all presented languages very easy to learn and fast to develop. At the top of the Spray model the diagram keyword initializes the declaration of the diagram type, followed by an identier for an EMF EClass. This class forms the root class for all following classes. The diagram type is used in the generated code as the name of the Graphiti diagram. Afterwards the classes (EClass) and references (EReference) from the EMF metamodel are mapped to the appearance and behavior on the diagram. The mapping starts with the keyword class followed by the fully qualied EClass or EReference name. This is mapped to a shape, which can be done in one of two ways. For simple cases an internal language to the Spray Core DSL allows to dene a shape consisting of rectangles, text and lines. For more elaborate shapes

Concepts for the model-driven generation of visual editors in Eclipse

the mapping can reference a shape dened in the Shape DSL. These can be referenced by their name as described later in this document. After the denition of shapes, the behaviors have to be dened. For this there are many types of behaviors like the creation behavior of the elements in the right containment attribute in the meta model and the inclusion in the tools palette. Also custom behaviors can be dened. For this, the necessary structure is generated, the code dening the behavior is written in Java manually. This paper does not go into details of this language as we regard it as volatile at this point in time.

Denition of Shapes

The main Spray DSL allows the creation of simple shapes, but if more complex gures are desired there is a DSL for the creation of shapes. It is similar to SVG to some degree, but it has dierent design goals. Similar to SVG, the Shape DSL allows primitive shapes like rectangles, ellipses, polygons, polylines and lines to be combined to complex shapes. But while SVG is based on XML, this DSL is based on a context-free grammar, giving us more freedom in its design. The main goal is readability and fast learning for human users, not machine readability or fast transfer. We also had requirements SVG cannot fulll, like the denition of resizing policies and the passing of parameters for text slots or the programmatic evaluation of properties. Shapes can make use of nesting. The curly brackets ({ and }) are used to signal nesting consistently throughout the DSL. All forms except from lines, polylines and text can be arbitrarily nested. The Shape DSL is consistently used for node elements as well as for connections. Its details are explained in the following section. Multiple and Nested Shapes. The denition of a shape begins with the keyword shape that is followed by a unique shape name (in Fig. 2 the Shape is called BPMN Event Mail ). This name is reected as name of the generated Java class. This class implements a marker interface ISprayShape and extends the DefaultSprayShape class. The interface provides two getShape() methods: one of them returns the ContainerShape and the other the PictogramElement. The ContainerShape is a container which is added to the diagram. It saves a PictogramElement and all its nested elements. It is also able to save more conguration as anchor denitions for the connection anchorage. The method which provides the PictogramElement always starts with an invisible rectangle as the root because the ContainerShape doesnt allow to save more than one child element on the rst layer. So the rst layer always corresponds to an invisible rectangle which is able to save multiple childs on it. The size of this invisible rectangle calculated from its contained shapes on the same layer. The example in Fig. 2 describes how to create an envelope for the mail event of BPMN[7] with the Shape DSL. The hole gure is inside a circle, an ellipse where width and height have the same value. Nested into this ellipse there is a rectangle, which forms the edge of the envelope. The position of the rectangle

Concepts for the model-driven generation of visual editors in Eclipse

Fig. 2. Creation of a Shape as mail event (BPMN)

is expressed relative to the surrounding ellipse. Finally a polygon completes the envelope; also its coordinates are relative to its container, the rectangle. Anchorage on Shapes. Anchor points is another important aspect for designing shapes. At these anchor points connections can be attached to a shape. In the Shape DSL there are four ways for the denition of anchor points. There are two predened anchor types which are called center and corners (see Fig. 3). The center denition is comparable with the Chopbox anchor in [16]. In this case the anchor attaches the connection end point to the center of the gure/shape, but the connection line and its adornments ends on the shapes edge. The second predened anchor type - corners - creates anchors on all corner points of the gure as well as on the center of the four sides of the shape. An example is shown on the right side of Fig. 3. After the keyword anchor the predened anchor types center or corners can be declared or a curly bracket is used to dene specic positions for the anchor points. One or many anchor points can be set to coordinates (using x and y ) or to relative position (using xoset and yoset ). Fix point anchors are placed at the dened position within the drawn shape. The relative anchors are positioned in relation to the size of the shape with values between 0.0 (xoset - left or yoset - top) and 1.0 (xoset - right or yoset - bottom). The lower part of Fig. 3 shows the creation of anchors on the edges of the rhombus for the XOR-Gateway in BPMN. As shown in the gure the same anchor points can be dened as xed or relative anchors. Connections and Placings. A connection always consists of a line, that connects two shapes with each other. Any connection has always a source and a target anchor, on which the attachment of the connection is done. But connections can have decorations, such as arrowheads or a shape. In the example of BPMN there is a conditional connection, shown in Fig. 5. This connection has two decorations, the arrowhead at the one end and the rhombus at the other.

Concepts for the model-driven generation of visual editors in Eclipse

Fig. 3. Anchorage on Shapes

Text such as the connection name or the cardinality can be positioned on the connection as well.

Fig. 4. Placing on Connections

In Shape DSL connections are dened using the keyword connection. It can be followed by a routing type. Two dierent routing types are dened so far, the free form routing and the manhatten routing. The manhatten routing is autolayouted in vertical and horizontal lines and uses rounded corners. The free form connection is initially just a straight line, that can be adjusted by the user by adding bend points while modeling.

Concepts for the model-driven generation of visual editors in Eclipse

Placings can be dened. A placing is a denition for a decoration on the connection. A placing is positioned on the connections with three required attributes the oset, the angle and the radius. The oset is the position on the line where the decoration element should be docked. It is a relative value between 0.0 and 1.0, the rst denoting the start of the line, the later its end. Additionally the elements can be positioned using an angle (0-360 degrees) and a radius. For graphical adornments, these values are typically zero, but for the positioning of text o the line, this proves to be very useful. Angle and radius dene a vector starting at the oset on the line that points to where the required element is drawn. The Fig. 4 shows such a vector.

Fig. 5. Connection-Shapes and their Placings

The example in Fig. 5 shows the denition of the conditional sequence connection of BPMN without text elements. There are two placings on the connection. The rst is located at the end (oset=1.0) and is an arrowhead, drawn as a lled polygon. The other is a rhombus placed at the beginning (oset=0.0).

Denition of Styles

The style DSL allows to dene a set of representational attributes for shapes and makes such a style reusable via a name. Attributes like background color and line style can be set. It can be referenced and used for the whole Spray project or can be set on individual shapes or single shape elements such as ellipse, rectangle or polygon. If no style is referenced at all a default style for Spray is used. For each level of nesting the style is inherited from the next level above. Individual style attributes can be overridden on each nesting level. This gives very ne grained

Concepts for the model-driven generation of visual editors in Eclipse

control on the look and feel for the designer of the shape and at the same time makes it easy to change or extend the general appearance of the diagram very quickly. Example for a Style style BlackAndWhiteStyle { description = "White background and black foreground." transparency = 0.95 background-color = white line-color = black line-style = solid line-width = 1 font-color = black font-name = "Tahoma" font-size = 10 font-italic = yes font-bold = no } A style denition is described in a le with the sux .style. The description of a style begins with the keyword style and a unique style name (in the example BlackAndWhiteStyle ). This style is generated to a Java class with the same unique style name. This class implements the interface ISprayStyle. This interface forces the generated class to implement the method getStyle() which returns an instantiation of the Graphiti style class. In this way all dened attributes of the style denition are set on the Graphiti Style class. For styles there are many attributes that could be set. Line attributes like the line color, line width (e.g. for borders) and line style can be set. The line style is a line appearance method and there are dierent predened line style types as solid, dot, dash, dash-dot, dash-dot-dot. The font section allows to dene attributes like the font-name, font-size, font-color and additionally the style of the font (bold and italic ) can be dened as well. With the values yes and no the styles bold and italic can be activated or not. The underlining of font is not supported from Graphiti at this early stage, so this structure is not been reected in the DSL as well, but would be an important enhancement for the future. In the case of colors there is an annotation to the Graphiti Style, because this doesnt allow to dierentiate between an font-color and a line-color. In Graphiti there is just one color denition - the foreground-color. The foreground-color is everything drawn as the line border and the fonts. In Spray this case is been resolved in another way, by generating a second method for every style called getFontColor() that may provide a dierent foreground-color as the line-color for the font. Summarizing the foreground-color from the getStyle() -method is mapped to the line-color and for the dierentiation to the font-color a second method (getFontColor() ) is provided. The usage of colors is pretty simple, because there are just two dierent ways to do this. The rst way is by using the predened colors as white, black, gray, yellow and many more. The second way is to use the

Concepts for the model-driven generation of visual editors in Eclipse

RGB -structure. Here the strength of the red, green and the blue color can be dened personally with a value between 0 and 255, so the user is able to create nearly all colors. Next to the color attribute for lines and for the background there is an attribute for transparency. A value for the transparency of 1.00 means that the object is fully visible and 0.00 means the object is invisible. If no backgroundcolor intended the color can be set to transparent. In this case the lled attribute in the Graphiti Style is set to false and no background-color is passed. For the line-visibility the same approach as for the background-color is used. Styles can inherit from each other. The root of the styles inheritance hierarchy is the interface ISprayStyle followed by an default implementation called DefaultSprayStyle, which denes all default style attributes. But this approach can be used in the DSL as well. A style can inherit from another style and change just a few attributes. In the example below the style BlackAndYellowStyle inherits from the BlackAndWhiteStyle and just the background-color is changed to yellow. Example for Style Inheritance style BlackAndYellowStyle extends BlackAndWhiteStyle { description = "Yellow background and black foreground." background-color = yellow } Through this inheritance mechanism all attributes of the style DSL are optional. A style can also be programmed manually in Java. It just needs to implement the interface the ISprayStyle and the style is available for referencing in Spray or Shapes and for inheritance. Some nice enhancements as color gradients and element shadows will be added in the near future and will share the same properties. Integration of Styles onto Shapes/Connections. The appearance of shapes can be dened in an external style or can be changed internally in the shape denition. For this the style keyword is used and the style attributes are dened in round brackets. In this case one or more attributes of the possible style attributes can be overridden. This takes eect on the corresponding element, but not for the nested elements or other forms on the same layer. This is shown in the top part of Fig. 6. There the background-color is set to the blue color for the rectangle. Respectively this changes just the rectangle in the picture to gain the blue color. The second method makes it possible to inherit style classes for the whole shape. Here the style class is referenced by its name after the keyword style. The second part of the Fig. 6 uses the style class BlackAndYellowStyle for the whole shape. The complete shape will become a yellow background. If the same approach is used at the beginning of the rectangle, then the entire envelope would become yellow, but not the circle.

10

Concepts for the model-driven generation of visual editors in Eclipse

As shown in the lower part of the Fig. 6 these two methods can be mixed. The attributes dened inline for a shape will always overwrite the attributes on the style class. In the example the whole shape becomes yellow apart from the rectangle, which overrides its color to blue. In our experience, this mixing is useful. Often the line-style attributes are used inline to change the line appearance (e.g. dotted instead of solid) where as color, background and text attributes are inherited.

Fig. 6. Types of Style Integration within Shapes

Concepts for the model-driven generation of visual editors in Eclipse

11

State of the Art

Projects that have identied a need for domain specic graphical modeling as part of an Eclipse based tool chain, today typically have the following choices. Either they drop the integration of the graphical modeling tool into Eclipse. Then a few commercial oerings including MetaEdit+[14] and Poseidon for DSL[2] allow the creation of domain specic modeling languages and an integration on the basis of the resulting model in serialized form, usually as XMI. Or they can drop the requirement to base their modeling language on their own metamodel and instead extend UML to mimic a DSL. UML 2.0 has a mechanism to extend the metamodel through stereotypes and proles. Such extensions have to be built on the basis of the predened UML metamodel elements. This makes it dicult to generate code from it. Also, most UML tools that oer good adaptation through proles are not based on Eclipse, so this case combines with the previous. The tools most used for this approach are Enterprise Architect[17] and Magic Draw[15]. A third approach is to drop the use of a graphical modeling environment and instead use a textual language to express the DSL models. This approach seems to be very successful in practice. Most known tools are Xtext[4], Spoofax[6] and EMFtext[5]. Finally it is possible to build a modeling tool in Eclipse. This paper advocates this approach but it is our observation from experience that this can lead to high and hard to predict development costs. Building such tools directly on GEF and Draw2D provides very little infrastructure support and is accordingly very work intensive. The afore mentioned GMF improves this through a generative approach. However, the DSLs, the generator and the generated code of GMF have themselves high complexities. Extending GMF beyond the default generated behavior can become particularly painful. A very good alternative to build their own modeling tool in Eclipse is the mentioned framework Graphiti. But it is relatively young and we have no indication on how intensively it is used outside of SAP, who developed the framework. From our experience in this project we can strongly recommend it. The framework hides the complexity of GEF and Draw2D and provides a clearly structured API. However, while the API is well structured and powerful, it naturally lends itself to a generative approach. This is what our project proposes. Parallel to our development, a similar project called IMES[3] is being developed, which pursues a similar approach. The aim of the publicly funded project is to build graphical editors based on Graphiti for functional nets and other systems. The project also uses DSLs and MDD for the generative creation of the graphic editors. Currently the project is not open source and wasnt presented to the public, so its dicult to compare our approach with the IMES project.

Limitations of the Approach

The described project is by no means nished and still lacks a number of important features before its use could be recommended in the context of mission critical development. But this will improve over time. Examples of such features

12

Concepts for the model-driven generation of visual editors in Eclipse

are improved support for text, the inclusion of shadows and gradients, support for context menu and the use of rapid buttons. More important is the question of the limitations of the approach. In terms of the graphical editor itself, the API oered by Graphiti as well as exploiting its capabilities through a model driven approach, we see no serous constraints. In this regard, Graphiti provided a lot of features we had expected. Nonetheless we analyzed a few limitations while developing the editor. For example, Graphiti currently does not support the underlining of text, a feature we would need i.e. for static members in a UML class diagram. Another limitation is the standard zooming function within Graphiti diagrams. The framework zooms by resizing all sizes of the elements, including the border-size. This leads to unproportional borders. Zooming currently only works well between 75 and 150 %. Finally the Graphiti API allows a few things that surprisingly have no eect on the diagram. This lead to the workaround that we use an invisible rectangle at the root level of every shape. The generative approach is somewhat limited to cases that are needed often enough to justify the development of a generator and the according input models. Corner cases could be covered with additional parameters in the input to the generator, however, the generated code is well prepared for manual extensions, so that this could turn out simpler. The DSLs presented by us are targeted towards graphical languages based on the notion of nodes and edges. In UML most diagram types t into that category, however it includes a few exceptions. The sequence and the timing diagram show time as one dimension and dier in that sense. They cannot be described with the presented DSLs without considerable extensions. We see more limitations in the platform of Eclipse itself. Eclipse was developed as a text-centric software development tool, and this heritage remains visible to the day. An example for this is that Eclipse ends a transaction of a le change upon saving this le. However, models on a scale larger than just one diagram need a dierent semantic for changes. Model elements can be represented in several diagram views. Modeling users have come to expect a change in one such representation to be reected in the others immediately, as this is the case in repository based modeling tools. However, this is hard to achieve in Eclipse. Other topics, like multi-user support in collaborative modeling environments, evolution of metamodels, or ding and merging changes in versions of graphical models remain topics of research and are independent of Eclipse or a model driven approach.

Summary

In this paper we have shown that developing graphical DSLs with the usage of the open source framework Spray can be very ecient. We presented concepts for the model driven development of graphical modeling tools in the context of Eclipse. The modeling tools can be congured to the needs of a specic domain, resulting in an Eclipse plugin that supports a graphical domain specic language. It is not necessary to be an IT expert to develop such modeling tools, because

Concepts for the model-driven generation of visual editors in Eclipse

13

the DSLs are quite easy to learn, read and write. The meta model and the DSLs can be tailored to the specic needs, thus the models can be very concise. In this paper we showed some elements of the BPMN, but the same approach could be used for various domain specic modeling languages. The generative approach reduces the needed eort to develop a graphical modeling tool for Eclipse considerably compared to coding it manually in Java against the Graphiti API. For the underlying Graphiti framework, every domain object needs to be described by a set of so called features. For each domain object the generator creates an Add-, a Create-, a Layout- and an UpdateFeature (a lot more planned), which altogether consist of about 400 lines of code per domain object. These can be generated from Spray from about 20 lines of code. The factor in terms of code between the Spray DSLs (20 lines) and the generated Graphiti Code (400 lines) is approximately 20. For several implemented examples we consistently observe this factor. A small DSL developed in Spray with 20 domain objects was described in about 400 lines of code. This generates about 80 Java Classes with altogether 8000 lines of code. Thus we argue that our approach reduce the project cost for developing a graphical DSL in Eclipse from weeks and months (manually written) to hours and days (generative approach). This should make the development of graphical modeling tools in Eclipse much more attractive than in the past.

References
1. Boger, M., Thoms, K., Warmer, J.: Spray - A quick way of creating Graphiti, http: //code.google.com/a/eclipselabs.org/p/spray 2. Gentleware AG, Poseidon for DSLs, http://www.gentleware.com/fileadmin/ media/pdfs/tutorials/Poseidon_for_DSLs_Documentation.pdf 3. Graf, A.: A DSL for Graphiti Editors (IMES), Research Project, http://5ise. quanxinquanyi.de/2011/08/18/a-dsl-for-graphiti-editors/ 4. itemis AG: Xtext 2.0, http://www.eclipse.org/Xtext 5. Johannes, J., Amann, U.: Concern-based (de)composition of Model-Driven Software Development Processes. In Proc. of ACM/IEEE 13th International Conference on Model Driven Engineering Languages and Systems (MoDELS 10), volume 6395 of LNCS. Springer, 2010. 6. Kalleberg, K. T., Visser, E.: Spoofax - An Interactive Development Environment for Program Transformation with Stratego/XT. In T. Sloane and A. Johnstone, editors, Seventh Workshop on Language Descriptions, Tools, and Applications (LDTA 2007), ENTCS, pages 4750, Braga, Portugal, March 2007. Elsevier. 7. Object Management Group: Business Process Model and Notation, Specication V2.0, January 2011, http://www.omg.org/spec/BPMN/2.0/PDF 8. The Eclipse Foundation: CDO Model Repository, http://www.eclipse.org/cdo/ 9. The Eclipse Foundation: Draw2d, http://www.eclipse.org/gef/draw2d/ 10. The Eclipse Foundation: Eclipse Modeling Framework Project (EMF), http:// www.eclipse.org/modeling/emf/ 11. The Eclipse Foundation: GEF (Graphical Editing Framework), http://www. eclipse.org/gef/ 12. The Eclipse Foundation: Graphical Modeling Project (GMP), http://www. eclipse.org/modeling/gmp/

14

Concepts for the model-driven generation of visual editors in Eclipse

13. The Eclipse Foundation: Graphiti: A Graphical Tooling Infrastructure, http:// www.eclipse.org/graphiti/ 14. MetaCase: MetaEdit+, http://www.metacase.com/mep/ 15. No Magic Inc.: MagicDraw, https://www.magicdraw.com/ 16. Rubel, D., Wren, J., Clayberg, E.: The Eclipse Graphical Editing Framework (GEF), Eclipse Series, pp. 69-76, 17. Sparx Systems: Enterprise Architect, http://www.sparxsystems.com/ AddisonWesley Professional (2011)