Graphical editors that are used in the domain of ModelDriven Engineering (MDE) follow speci c conventions to denote relations between elements such as edges and containments. However, existing research suggests that there are other visual aspects that can better encode these relations such as the shape, the position and colour of the elements. In this paper, we propose the use of these physical variables to denote information regarding attributes and relations between elements. Running examples of DSLs in which such paradigms can be of bene t are presented.
In the majority of graphical model editors, nodes are used to represent di erent 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 con rmed by di erent empirical studies [
In the emerging community of bottom-up and exible 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 bene cial. In the same example above, it would be more natural to change the table of a guest by just moving her around di erent 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 exible modelling technique, called Muddles [
The rest of this paper is structured as follows. In Section 2 related work in the eld of notation design is discussed and bottom-up exible 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. 2
In [
In [
In the eld of bottom-up metamodelling, [
In this work we implement the examples using an extended version of the
exible modelling technique in [
In this section, we present the basic details that will help the reader understand
how the Muddles approach [
The Muddles approach [
For a better understanding of the above process the authors in [
The process starts with the creation of a drawing of an example owchart
(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 elds in the yEd's custom properties dialog (see Figure 3).
More details about these properties are presented in [
This type-related information are keywords that will be used by the model
management programs to elements of the diagram. For example, writing the
following Epsilon Object Language (EOL) [
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 le (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. 4
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. 4.1
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 di erent 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 speci ed 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.
Indeed, if we query the model using the EOL statement of Listing 1.3 the correct table is returned. var james = Guest . a l l . selectOne ( p j p . name = "James ") ; O("uJtapmutes: belongs to t a b l e " + james . getTable ( ) . number + " . " ) . p r i n t l n ( ) ; James belongs to t a b l e 1 .
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. 4.2
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 de ned in many di erent 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 Player using EOL to get his team. This is shown in Listing 1.4. var teamsMap = new Map; teamsMap . put("#FF6600 " , " Netherlands ") ; teamsMap . put ("#333333" , "Germany ") ; var vanPersie = Player . a l l . selectOne ( f j f . name = "Van P e r s i e ") ; ("Van P e r s i e plays for " + vanPersie . getTeam ( ) ) . p r i n t l n ( ) ; f u n c t i o n Player getTeam ( ) f var c o l o r = s e l f . getColor ( ) ; return tMap . get ( c o l o r ) ; g Output : Van P e r s i e plays for Netherlands
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 con gurations. 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 nd its capacity and assign it to a prede ned size category (small, medium, large). The querying code to get the type, the size category and the capacity is given in Listing 6. . . . for ( t in tanksi s) fa " + t . getSizeCategory ( ) + " (" + t . getArea ( ) + " l i t r e s ) " + t . ( t . name + "
getTankType ( ) ) . p r i n t l n ( ) ; g f u n c t i o n Tank
return shapesgMetaTpapniknTg y.pgeet( )( sfe l f . getShape ( ) ) ; g f u n c t i o n Tank getSizeCategory ( ) f i f ( s e l f . getArea ( ) <5000.0)f
returni f " S(mseallfl ". g;etArea ( ) <20000.0) f g reeltsuern "Medium " ; g reeltsuernf " Large " ; g gOutput : Tank 4 i s a Large (22500.0 l i t r e s ) Water Tank TTaannkk 51 ii ss aa MSmedaiullm (2(151020 5.00.0l i tlri et rs e)s W)aStteeramTaTnkank . . .
The size characteristic can be error-prone. Mistakes can be made if the shape's area is close to the thresholds that de nes di erent size categories. For instance, one tank may look like a small tank, but in reality it is medium. 4.4
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 de ne 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. var persons = Person . a l l ; var raBox = RA. a l l . f i r s t ( ) ; var rsBox = RS . a l l . f i r s t ( ) ; var esBox = ES . a l l . f i r s t ( ) ; for (p in persons ) f
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 exible 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).