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

Transcription

1 Concepts for the model-driven generation of graphical editors in Eclipse by using the Graphiti framework Fabio Filippelli 1, Steffen Kollosche 1, Michael Bauer 1, Markus Gerhart 1, Marko Boger 1, Karsten Thoms 2 and Jos Warmer 3 1 University of Applied Sciences Konstanz (HTWG Konstanz), Department of Computer Science, Brauneggerstrasse 55, Konstanz, Germany 2 itemis AG, Am Brambusch 15-24, Lünen, Germany, 3 Independent, Chalonhof 153, 3762CT Soest, Netherlands Abstract. Domain-Specific modeling is increasingly adopted in the software development industry. While textual domain specific 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-Specific-Language (DSL), Model-Driven-Development (MDD), Code Generation, EMF, Xtext, Xtend, Graphiti, Spray, Eclipse IDE, Graphical Editors, Eclipse Plugin 1 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 difficult 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 offers no specific support for graphical modeling. A project that attempted to bridge the gap between GEF and EMF is GMF[12].

2 2 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 difficult 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 files needed for the Eclipse plugin mechanism. The result is a graphical modeling tool in Eclipse. The paper first 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 definition of our own graphical elements with the corresponding DSL, followed by chapter 4 which shows our approach for the flexible styling of these. In chapter 5 we review related work in the field, 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. 2 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 specifically 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 different 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 sufficient. It defines 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 figures like rectangles and ellipses, configures their placing, resizing policy and nesting. The style of shapes, like color and font, can be defined inline in the Shape language. But in order to reuse and centralize the definition of styles, the Style DSL allows to define 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

3 Concepts for the model-driven generation of visual editors in Eclipse 3 Fig. 1. A Model-Driven approach for Graphical Editors is saved, the Model-Driven Generation is executed and generates all necessary code and configurations - 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 defined in the Spray Core language. This is a simple text file with the ending.spray. The Spray project wizard creates such a file initially with some example code. Due to the file 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 identifier 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 qualified 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 define a shape consisting of rectangles, text and lines. For more elaborate shapes

4 4 Concepts for the model-driven generation of visual editors in Eclipse the mapping can reference a shape defined in the Shape DSL. These can be referenced by their name as described later in this document. After the definition of shapes, the behaviors have to be defined. 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 defined. For this, the necessary structure is generated, the code defining 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. 3 Definition of Shapes The main Spray DSL allows the creation of simple shapes, but if more complex figures are desired there is a DSL for the creation of shapes. It is similar to SVG to some degree, but it has different 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 fulfill, like the definition 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 definition 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 reflected 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 configuration as anchor definitions for the connection anchorage. The method which provides the PictogramElement always starts with an invisible rectangle as the root because the ContainerShape doesn t allow to save more than one child element on the first layer. So the first 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 figure 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

5 Concepts for the model-driven generation of visual editors in Eclipse 5 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 definition of anchor points. There are two predefined anchor types which are called center and corners (see Fig. 3). The center definition is comparable with the Chopbox anchor in [16]. In this case the anchor attaches the connection end point to the center of the figure/shape, but the connection line and its adornments ends on the shapes edge. The second predefined anchor type - corners - creates anchors on all corner points of the figure 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 predefined anchor types center or corners can be declared or a curly bracket is used to define specific positions for the anchor points. One or many anchor points can be set to coordinates (using x and y) or to relative position (using xoffset and yoffset). Fix point anchors are placed at the defined position within the drawn shape. The relative anchors are positioned in relation to the size of the shape with values between 0.0 (xoffset - left or yoffset - top) and 1.0 (xoffset - right or yoffset - 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 figure the same anchor points can be defined as fixed 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.

6 6 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 defined using the keyword connection. It can be followed by a routing type. Two different routing types are defined 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.

7 Concepts for the model-driven generation of visual editors in Eclipse 7 Placings can be defined. A placing is a definition for a decoration on the connection. A placing is positioned on the connections with three required attributes the offset, the angle and the radius. The offset 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 first 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 off the line, this proves to be very useful. Angle and radius define a vector starting at the offset 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 definition of the conditional sequence connection of BPMN without text elements. There are two placings on the connection. The first is located at the end (offset=1.0) and is an arrowhead, drawn as a filled polygon. The other is a rhombus placed at the beginning (offset=0.0). 4 Definition of Styles The style DSL allows to define 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 fine grained

8 8 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 definition is described in a file with the suffix.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 defined attributes of the style definition 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 different predefined line style types as solid, dot, dash, dash-dot, dash-dot-dot. The font section allows to define attributes like the font-name, font-size, font-color and additionally the style of the font (bold and italic) can be defined 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 reflected 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 doesn t allow to differentiate between an font-color and a line-color. In Graphiti there is just one color definition - 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 getfont- Color() that may provide a different 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 differentiation to the font-color a second method (getfontcolor()) is provided. The usage of colors is pretty simple, because there are just two different ways to do this. The first way is by using the predefined colors as white, black, gray, yellow and many more. The second way is to use the

9 Concepts for the model-driven generation of visual editors in Eclipse 9 RGB-structure. Here the strength of the red, green and the blue color can be defined 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 filled 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 defines 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 defined in an external style or can be changed internally in the shape definition. For this the style keyword is used and the style attributes are defined in round brackets. In this case one or more attributes of the possible style attributes can be overridden. This takes effect 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 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 defined 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

11 Concepts for the model-driven generation of visual editors in Eclipse 11 5 State of the Art Projects that have identified a need for domain specific 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 offerings including MetaEdit+[14] and Poseidon for DSL[2] allow the creation of domain specific 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 profiles. Such extensions have to be built on the basis of the predefined UML metamodel elements. This makes it difficult to generate code from it. Also, most UML tools that offer good adaptation through profiles 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 wasn t presented to the public, so it s difficult to compare our approach with the IMES project. 6 Limitations of the Approach The described project is by no means finished 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 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 offered 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 effect 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 fit into that category, however it includes a few exceptions. The sequence and the timing diagram show time as one dimension and differ 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 file change upon saving this file. However, models on a scale larger than just one diagram need a different 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 reflected 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 diffing and merging changes in versions of graphical models remain topics of research and are independent of Eclipse or a model driven approach. 7 Summary In this paper we have shown that developing graphical DSLs with the usage of the open source framework Spray can be very efficient. We presented concepts for the model driven development of graphical modeling tools in the context of Eclipse. The modeling tools can be configured to the needs of a specific domain, resulting in an Eclipse plugin that supports a graphical domain specific language. It is not necessary to be an IT expert to develop such modeling tools, because

13 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 specific 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 specific modeling languages. The generative approach reduces the needed effort 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, media/pdfs/tutorials/poseidon_for_dsls_documentation.pdf 3. Graf, A.: A DSL for Graphiti Editors (IMES), Research Project, quanxinquanyi.de/2011/08/18/a-dsl-for-graphiti-editors/ 4. itemis AG: Xtext 2.0, 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, 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 47 50, Braga, Portugal, March Elsevier. 7. Object Management Group: Business Process Model and Notation, Specification V2.0, January 2011, 8. The Eclipse Foundation: CDO Model Repository, 9. The Eclipse Foundation: Draw2d, The Eclipse Foundation: Eclipse Modeling Framework Project (EMF), The Eclipse Foundation: GEF (Graphical Editing Framework), eclipse.org/gef/ 12. The Eclipse Foundation: Graphical Modeling Project (GMP), eclipse.org/modeling/gmp/

14 14 Concepts for the model-driven generation of visual editors in Eclipse 13. The Eclipse Foundation: Graphiti: A Graphical Tooling Infrastructure, MetaCase: MetaEdit+, No Magic Inc.: MagicDraw, Rubel, D., Wren, J., Clayberg, E.: The Eclipse Graphical Editing Framework (GEF), Eclipse Series, pp , 17. Sparx Systems: Enterprise Architect, Addison- Wesley Professional (2011)