In the majority of graphical model editors, nodes are used to represent different types and edges to denote relations between them. Some editors also allow the use of containments to group elements that conceptually belong to the same container while others allow the replacement of geometrical shapes with icons.
The importance of visual notation in diagrams and the impact on understanding them has been confirmed by different empirical studies [1], [2], [3]. Visual characteristics of the notation can help to better understand the modelled concepts while changes to them affect the final understanding, even if the semantics of the concepts have not changed. However, research on the design of graphical concrete syntaxes for modelling languages and Domain-Specific Languages (DSLs) in general suggests that diagram-based information related to the colour, size, location of model elements is ignored by the metamodel tools as the majority of effort is put on the semantics of the notation rather that the visual representation. [3] In the emerging community of bottom-up and flexible modelling, where domain experts are invited to create example models of the envisioned DSL, the traditional graphical MDE conventions are not always easy to follow. For instance, in a DSL that will be used to graphically design the seating plan for an event, a domain expert will likely place each guest close to the table he/she belongs to. A person not familiar with the traditional MDE conventions is not likely to use edges to connect guests to the tables or place the guests on the tables to express the notion of containment nor would they create an attribute for each guest to hold the ID of the table she belongs to. The former notation arguably looks more natural than the latter.
Even in cases where bottom-up modelling is not used or where users are familiar with the traditional MDE conventions, the use of such physical characteristics could be beneficial. In the same example above, it would be more natural to change the table of a guest by just moving her around different tables, rather than changing the value of the appropriate attribute, or by deleting an existing node and drawing another node to the new table.
In this paper we argue that some of the physical characteristics of diagram elements can be used to extract useful information about their underlying model elements. We present examples where such information is useful. In the examples we use a flexible modelling technique, called Muddles [4], to represent our models benefiting from its model querying capabilities to evaluate our claims.
The rest of this paper is structured as follows. In Section 2 related work in the field of notation design is discussed and bottom-up flexible modelling techniques are presented. Section 3 includes a brief presentation of the Muddles approach. In Section 4 we present an number of physical attributes and illustrate via running-examples how can assist in extracting useful information like the types of elements and relations between them. In Section 5 we conclude the paper and outline plans for future work.
In [3], Moody proposes a set of rules that should be followed when creating graphical notation for a modelling language. He highlights the importance of the physics of notations in the development of DSLs and the fact that this is a neglected issue so far. The theory of communication by Shannon and Weaver [5], is adapted by Moody for the domain of graphical notations: the effectiveness of the communication of a diagram can be increased by choosing the most appropriate notation conventions of these that the human mind can process. In [6], Bertin identified a set of 8 visual variables that can encode and reveal information about the elements they represent or their relations in a graphical way. These variables are: the horizontal position, the vertical position, the shape, the size, the colour, the value (referred as "brightness" [3]), the orientation and the texture.
In [7], [8] the authors propose a set of metamodels that can be used in the classification of visual languages taking into account spatial information. In [9] the authors present a parsing technique that can incorporated into freehand editors and turn them into syntax-aware, using different criteria such as spatial relationships. Finally, Baar [10], proposes the formal definition of the concrete syntax of modelling languages.
In the field of bottom-up metamodelling, [11] proposes the use of example models to semi-automatically infer the metamodel. In [12], the example models created by domain experts using drawing tools can be used to construct the metamodel. In [13], models that do not conform to their metamodel because the latter evolved, can be used to recover the metamodel they are instances of. Finally, in [4], users, using a simple drawing tool, define example models which are then amenable to programmatic model management (validation, transformation, etc.).
In this work we implement the examples using an extended version of the flexible modelling technique in [4]. The same process could be followed using any other editor for flexible or traditional metamodel-based modelling.
In this section, we present the basic details that will help the reader understand how the Muddles approach [4] works. In addition, we present the work carried out to extend the Muddles to keep information about the visual properties of the models.
The Muddles approach [4] proposes the use of general drawing tools, for the construction of diagrams that are amenable to programmatic model management. More specifically, domain experts use a GraphML-compliant drawing tool (the yEd Editor1 in their work) to express the example models, which conform to their envisioned metamodel. Engineers annotate these drawings to specify types and attributes for each element. The annotated diagram is then automatically transformed to an intermediate Muddle model (the Muddle metamodel is shown in Figure 1a). The Epsilon platform [14] provides an abstraction layer (the Epsilon Model Connectivity -EMC2 ) that allows access to models that conform to a range of technologies. A driver that implements EMC's interfaces and allows Epsilon to consume muddles was developed. Using the driver, model management programs (M2T transformations, Validation, etc.) can be written and executed on the muddles.
For a better understanding of the above process the authors in [4] provided an example which is presented here. In their example, the goal is to create a new flowchart-like language.
The process starts with the creation of a drawing of an example flowchart (see Figure 2). The next step is the annotation of the diagram elements with information to allow programmatic management. For instance, in this case one needs to declare that the type of the rectangles as an Action and the type of the directed edges as a Transition. The types are not bound with the shape but with each element (in another example one rectangle can be of type Action while another one can be of type Process). Types and type-related information like properties (attributes of the type), roles and multiplicity of edges can be provided using the fields in the yEd's custom properties dialog (see Figure 3). More details about these properties are presented in [4].
The current Muddles metamodel and the implementation of the EMC driver for muddles discard information regarding graphical and spatial properties of each element. These properties are the: x and y coordinates, the width and height, the shape and the colour of each Muddle Element.
Firstly, we extended the muddles metamodel to allow Muddle Elements hold the above information. The changes are shown in Figure 1b. The graphical and spatial properties of each element are now stored as attributes in the MuddleElement class.
Secondly, we implemented the required functionality in the EMC Muddles driver to be able to parse the GraphML file (the drawing), retrieve the information from it and store them in the muddle model instance. Further technical details about the new features of the EMC driver will not be discussed as they are beyond the scope of this paper.
In our running examples we demonstrate how 5 physical characteristics of the elements of graphical models can be used to extract relations and attributes. These are:
-Proximity: the distance between two or more elements.
-Colour: the colour of the element.
-Shape: the shape of the node.
-Size: the area of the node.
-Overlap: the intersection between two or more elements.
For each example, we implemented a set of functions to calculate the desired characteristic and executed it on the diagram using the querying capabilities of the Epsilon platform.
The fact that an element is closer to another than a third one may infer that it is related to the former rather than the latter. In our scenario, we designed an example model of an envisioned DSL where the organiser of an event needs to assign guests to the tables and later perform model management actions on them (e.g. M2T transformations to generate invitation letters).
A possible example model could be the one shown in Figure 4 where 24 nodes of type Guest are assigned to 3 different nodes of type Table . Naturally, each guest belongs to the table that he is closest to. In a traditional graphical modelling editor, this relationship could be specified by creating an edge from each guest to the table it belongs, or by placing guests inside "table containments", or by assigning an attribute for each guest that declares his/her table. In our approach, this assignment is done by placing them closest to the table they belong to.
To achieve this, an EOL function to calculate the proximity between two elements was implemented. Using this re-usable function (calculateProximity) we can query the models and get the relation of interest. The code for calculating and returning the closest table is illustrated in Listing 1.2. Indeed, if we query the model using the EOL statement of Listing 1.3 the correct table is returned.
We should note that the proximity characteristic may be error prone, as there might be cases that the user believes that a node is closer to the desired node while in reality it is closer to another.
In some cases, the colour of nodes or edges can declare that they belong to the same group or that they are of the same type.
In this scenario, we create an example model of an DSL that can be used to described football line-ups (see Figure 5). Each player belongs to a team illustrated by the colour of the node that represents each player. In a traditional MDE manner, this property could be defined in many different ways. Among others, one could use a string attribute for the name of the player's team or connect players of the same team with edges declaring a "team-mates" relation.
For this category, the function that returns the colour of the node is already implemented as part of our extended Muddles metamodel and driver (the extended Muddle metamodel stores the colour of the Element as an attribute -see . We can create a mapping of colour with team and then query a Player using EOL to get his team. This is shown in Listing 1.4.
var teamsMap = new Map ; teamsMap . p u t ("#FF6600 " , " N e t h e r l a n d s " ) ; teamsMap . p u t ( " # 3 3 3 3 3 3 " , " Germany " ) ; var v a n P e r s i e = P l a y e r . a l l . s e l e c t O n e ( f | f . name = "Van P e r s i e " ) ; ( " Van P e r s i e p l a y s f o r " + v a n P e r s i e . getTeam ( ) ) . p r i n t l n ( ) ; In some DSLs, the shape or the size of a node may encode information about its type or its attributes. We demonstrate that with an example DSL that can be used to design liquid tank configurations. In this scenario, the shape that is used to describe a tank, declares the subtype of the tank (Water, Uranium, etc.) By creating a mapping as in the previous example, we can query the model and identify the subtype of each tank.
In addition, the size (and the area) that each tank has can give us information about two other attributes of each tank like the "Size Category" and "Capacity". We can calculate the area of the tank to find its capacity and assign it to a predefined size category (small, medium, large). The querying code to get the type, the size category and the capacity is given in Listing 6.
. . . f o r ( t i n t a n k s ) { ( t . name + " i s a " + t . g e t S i z e C a t e g o r y ( ) + " ( " + t . g e t A r e a ( ) + " l i t r e s ) " + t . getTankType ( ) ) . p r i n t l n ( ) ; } f u n c t i o n Tank getTankType ( ) { return s h a p e s M a p p i n g . g e t ( s e l f . g e t S h a p e ( ) ) ; } f u n c t i o n Tank g e t S i z e C a t e g o r y ( ) { i f ( s e l f . g e t A r e a ( ) < 5 0 0 0 . 0 ) { return " S m a l l " ; } e l s e i f ( s e l f . g e t A r e a ( ) < 2 0 0 0 0 . 0 ) { return "Medium " ; } e l s e { return " L a r g e " ; } } Output : Tank 4 i s a L a r g e ( 2 2 5 0 0 . 0 l i t r e s ) Water Tank Tank 5 i s a S m a l l ( 2 5 0 0 . 0 l i t r e s ) Water Tank Tank 1 i s a Medium ( 1 1 2 5 0 . 0 l i t r e s ) Steam Tank . . . The size characteristic can be error-prone. Mistakes can be made if the shape's area is close to the thresholds that defines different size categories. For instance, one tank may look like a small tank, but in reality it is medium.
An overlap between two or more elements can provide us with information regarding their types and attributes. In a DSL that allows the creation of Venn diagrams this can be very useful. For instance, the Venn diagram of Figure 7 is an example of a model that would be an instance of a Venn DSL. In this case, the overlap between a node of type "Person" (yellow rectangles) with a circle denotes that the Person belongs to that set.
For this category, we can define a function to calculate whether two elements overlap or not. We can then re-use this function to query the model and receive, for instance the signatures of all the members of the department as seen in Listing 1.6. p . g e t S i g n a t u r e ( ) . p r i n t l n ( ) ; } f u n c t i o n P e r s o n g e t S i g n a t u r e ( ) { i f ( ( s e l f . o v e r l a p s ( raBox ) ) and ( not ( s e l f . o v e r l a p s ( esBox ) ) ) ) { return s e l f . name + " i s a RA i n t h e CS Department . " ; } e l s e i f ( ( s e l f . o v e r l a p s ( raBox ) ) and ( s e l f . o v e r l a p s ( esBox ) ) ) { return s e l f . name + " i s a RA i n t h e CS Department and member o f t h e ES g r o u p . " ; } e l s e i f ( ( s e l f . o v e r l a p s ( r s B o x ) ) and ( s e l f . o v e r l a p s ( esBox ) ) ) { return s e l f . name + " i s a RS i n t h e CS Department and member o f t h e ES g r o u p . " ; } e l s e i f ( ( s e l f . o v e r l a p s ( r s B o x ) ) and ( not ( s e l f . o v e r l a p s ( esBox ) ) ) ) { return s e l f . name + " i s a RS i n t h e CS Department . " ; } e l s e i f ( ( not ( s e l f . o v e r l a p s ( r s B o x ) ) ) and ( not ( s e l f . o v e r l a p s ( esBox ) ) ) and ( not ( s e l f . o v e r l a p s ( raBox ) ) ) ) { return s e l f . name + " i s member o f t h e CS Department . " ; } e l s e i f ( ( not ( s e l f . o v e r l a p s ( r s B o x ) ) ) and ( s e l f . o v e r l a p s ( esBox ) ) and ( not ( s e l f . o v e r l a p s ( raBox ) ) ) ) { return s e l f . name + " i s member o f t h e CS Department and member o f t h e ES g r o u p . " ; } } Output : James i s a RA i n t h e CS Department and member o f t h e ES g r o u p . Andy i s member o f t h e CS Department . C h r i s i s a RS i n t h e CS Department . . . . Listing 1.6. Get person's signature implementation and output
Physical characteristics included in graphical models can be used to extract meaningful information about the models and their elements. In this work, we presented examples demonstrating how they can be utilised to extend the current conventions for representing relations and attributes of model elements.
We believe that such an approach can be useful especially in the flexible modelling area were the involvement of stakeholders who are unfamiliar with the traditional conventions is common.
In the future, we plan to investigate how other physical attributes (like texture or orientation) that can, according to the literature, encode information about the diagram be used in MDE to help us represent better relations and attributes of elements.
This work was carried out in cooperation with Digital Lightspeed Solutions Ltd, and was part supported by the Engineering and Physical Sciences Research Council (EPSRC) through the Large Scale Complex IT Systems (LSCITS) initiative, and by the EU, through the MONDO FP7 STREP project (#611125).