Role Composition for Tool Interaction

After the specification of all role models, which is performed by tool designers, a proce- dure is required to integrate separate role models in order to obtain a coherent system, where tools can operate on the same data and thus all views are synchronized w.r.t. the underlying data. We achieve this integration by creating a role composition model. This model entails the relationship between role types of several role models. Role types of one role model are connected to the role types they play in another role model. There- fore, we also denote the composition model as binding model. To express such binding

8.4 Integrating Tools using Role Models

Figure 8.6: Composition language for role-based metamodeling.

models, we designed the Role Composition Language (RoCoLa). This language is based on previous work on language composition that was performed by Wende et al. [209]. The metamodel of RoCoLa is depicted in Fig. 8.6.

The conceptRoleCompositionis used to model the integration of multiple role models. It consists of RoleBindings andRoleGroundings. The former entail FeatureBindings, while the latter aggregateFeatureGroundings. First, we will look atRoleBindings.

RoleBindings connect two role types. One of the two role types is referenced to as being the player of this binding. As such, the player is entailed to provide all the features that are defined by the role types it plays. To specify how the player provides these features, that is, how their values are obtained, a set of FeatureBindings is required. These bindings specify how a particular feature of a played role is provided. In the most basic case, a mapping to one of the features of the player is sufficient here.

Also, RoCoLa provides a concept to ground features of role types. Grounding a feature means, that the value of this feature is stored physically. That is, it is not derived from another role type. If one grounds all features of the involved role models, a system with isolated physical data repositories is obtained. We will explain the grounding of features in greater detail later on, but focus on role bindings first.

Examples for role feature bindings are shown in Fig. 8.7, where a graphical notation of RoCoLa is used. The two-headed arrows connect players with their played role types. Thus, these are instances of metaclass RoleBinding. To integrate the shape renderer and the state machine editor, both Transition and State must play the role Shape. Playing the roleShaperequires respective players to provide all features defined for this role type. For example, every player must provide a label. Since both Transition and Statedo not directly provide a label, one must specify how the labels of transitions and states are obtained. This is not depicted in Fig. 8.7, but we will discuss this later on.

8 Role-based Round-Trip Engineering

Graph Analysis Tool

source target Node invalid : bool Edge 2D Shape Renderer WHITE BLACK RED Color CIRCLE RECTANGLE LINE Kind Shape x,y,size : Integer label : String Grounding Notation Name Grounded Role Type

Binding Notation

name : type Grounded Attribute

name Grounded Reference

Textual State Machine Editor

from to PLAIN INITIAL FINAL StateType type State name : String Transition condition : String player role

8.4 Integrating Tools using Role Models

The binding of the role types Transition and State shows that role types can be bound by several players. Likewise role players can be bound to several role types. To integrate the metamodels of the state machine editor and the graph analysis tool, Transitions are bound toEdgeandStates are bound to Node. BindingTransition to Edge requires transitions to provide a reference to a source and a target node.

We can say that the role composition depicted in Fig. 8.7 specifies a coarse grained binding of role types to other role types, but some details are missing. Most prominently, no information is available about how to obtain the bound features. To express this, RoCoLa provides further concepts. In addition to the concepts depicted in Fig. 8.6, the role composition shown in Listing 8.1 employs special feature binding types.

For example, RoCoLa provides a concept to map a feature of the player role to a feature of the played role. For example, the role typeStateplaying the role typeShape, binds featurelabelto its own featurename(Line 3). In addition, Listing 8.1 employs a conditional operator to provide different feature values depending on the value of other features. For example, the value of feature kind is determined depending on the value of the type feature in role State(Line 4 and 5).

1 integrate statemachine, 2dShapes, graph {

2 State plays Shape {

3 label: name

4 kind: if (player.type == PLAIN) return RECTANGLE

5 else return CIRCLE

6 color: if (player.type == INITIAL) return WHITE

7 else return BLACK

8 }

9

10 Transition plays Shape {

11 label: condition

12 kind: return LINE

13 color: return BLACK

14 }

15

16 State plays Node {}

17 Transition plays Edge {

18 source: from

19 target: to

20 }

21

22 ground State { name, type }

23 ground Transition { condition, from, to }

24 }

Listing 8.1: Example role composition specification.

The language used here to specify these bindings is rather declarative, but one could also employ an imperative language (e.g., Java). Depending on the implementation of the role bindings (cf. Sect. 8.4.3), they must be translated to the target platform of the integration or interpret at runtime. In any case, the properties and expressiveness of the role binding language requires special attention in the context of RTE (cf. Sect. 8.5.2).

8 Role-based Round-Trip Engineering

Graph Analysis Tool 2D Shape Renderer

Textual State Machine Editor

from to type Kind CIRCLE RECTANGLE LINE Color WHITE BLACK RED Role StateType PLAIN INITIAL FINAL Shape x,y,size : Integer get/setLabel() Node invalid : bool Edge get/setSource() get/setTarget() Player Transition condition : String State name : String p la yer ro les 1 *

Figure 8.8: Simplified result of role composition.

To specify the physical representation of shared data we introduced the concept of RoleGrounding (cf. Fig. 8.6) to role composition. Grounding is used to identify role features that physically materialize data. Every feature that is tagged as being grounded by the role composition specification, must be realized as physical data store. This can be either a piece of memory or disk space.

The selection of grounded features, determines which data is physically shared across tools. Grounding features closes the delegation chains defined by the feature bindings. The latter specify how to obtain feature values from other roles. The former determines features that actually hold values and that are not derived. When tools access data, these requests will finally end up in reading or writing a grounded feature. However, tools do not know which grounded feature this will be. The physical representation of data is entirely decoupled from the interfaces used by tools to access data.

Given the role binding specification that was depicted in Fig. 8.7 and refined in List- ing 8.1, one can derive a composed version of the three domain models. In Fig. 8.8 a simplified diagram showing the composed models can be found. The depicted class diagram is not sufficient to obtain an actual implementation of the composed role model. We will explain details on this in Sect. 8.4.3. But, to give an idea how the composition of role models is performed, this first simplified diagram should be sufficient.

Here, all role types are replaced by classes. Role types that were bound to one or more players (i.e.,Shape,Nodeand Edge) do inherit from a new class Role, which represents the common superclass for all role types. Role types that are not played by other role

8.4 Integrating Tools using Role Models

types (e.g.,StateandTransition) do inherit from classPlayer. In principle, all derived classes could inherit both fromRoleandPlayer, but to keep the example simplistic, we only added inheritance relations that are actually required.

The two additionally introduced classes—Player and Role—are connected by two references—player and roles. Through navigating these references, one can obtain all played roles and the player of each role. These two references are essential to implement the role binding, because they are used to obtain feature values by delegating requests to the role player. For example, if a client (e.g., the shape rendering tool) wants to retrieve the label of a given state, this request is forwarded to the player of the role type Shape—an object of type State. The same procedure applies to all other feature bindings. Requests that are issued to a role are forwarded to its player.

For grounded features, the situation is different. Instead of forwarding requests via delegation, these features are actually present in the respective classes. For example, the x and y features of class Shapeare modeled as properties in the composed role model. Their values are stored in Shapeobjects.

One must always keep in mind that the composition of the role models is performed at tool integration time. This allows to postpone the decision on data materialization. In contrast, a priori integration requires new tools to adapt to existing and fixed data materialization. In our approach, tools are decoupled from the concrete materialization of data. Rather, the role composition model is adjusted to integrate new tools.

Figure 8.7 and Listing 8.1 depict theRoleGroundings andFeatureGroudings used to specify data materialization for our example. The example shows that grounding com- plements the flexibility of role binding as it allows for an integration-specific adjustment of data materialization. Data that shall be used by both the graph analysis tool and the shape renderer is materialized and shared using the roles in the state machine role model. Data which is only required within a specific tool (e.g., thex-,y, and sizeattributes of a Shape) is materialized in the respective role model.

Such flexible means to specify data sharing and materialization redeems tool developers from the challenge of anticipating extensibility required for future tool integration and avoid problems of data replication and synchronization.