Towards Non-intrusive Composition of Executable Models

Henning Berg and Birger Møller-Pedersen

Department of Informatics, University of Oslo, Oslo, Norway

Keywords:

Model Composition, Languages, Domain-speciﬁc Modelling, Runtime.

Abstract:

An essential operation in model-driven engineering is composition of models and their metamodels. There

exist several mechanisms for model composition. However, most of these only consider composition of either

models or metamodels and not both kinds of models simultaneously, and do not address how the composition

impacts modelling artefacts like editors, transformations and semantics. Moreover, model composition mech-

anisms typically deal with model structure and do not consider operational semantics. In this paper, we discuss

a novel approach for the composition of both models and metamodels in a virtually non-intrusive manner. We

achieve this by utilising a placeholder mechanism where classes in one metamodel may represent classes of

another. The ideas presented have been validated by the construction of a framework. We will illustrate how

non-intrusive composition allows linking the operational semantics of different languages without rendering

existing modelling artefacts inconsistent. This increases the ﬂexibility in how languages can be combined, and

reduces the amount of necessary changes of tools and other modelling utilities.

1 INTRODUCTION

Metamodel composition is an important operation in

metamodelling. In the course of the last decade,

several mechanisms for composition of models and

metamodels have been devised, e.g. (Morin et al.,

2009)(Fleurey et al., 2008)(Kolovos et al., 2006)(Gro-

her and Voelter, 2007). However, most of the mecha-

nisms work either on the model or on the metamodel

level, and do not consider composition of both kinds

of models simultaneously. Speciﬁcally, metamodel

composition mechanisms do not address how exist-

ing models can be combined as their metamodels are

composed. A consequence of this is that the mod-

els are rendered invalid as they are not valid instances

of the composite metamodel resulting from the com-

position process. Other artefacts in the metamod-

elling ecosystem like editors (concrete syntax), se-

mantics (including constraints), transformations and

code generators are also impacted when metamodels

are composed. The reason is that these artefacts are

deﬁned relatively to a metamodel. Typically, each of

these artefacts needs to be refactored to comply with a

composed metamodel. Ideally, artefacts in the ecosys-

tem should be aligned with new metamodel variants

automatically by utilising information from the com-

position process. Similar considerations are discussed

in (Di Ruscio et al., 2012)(Garca et al., 2013)(Demuth

et al., 2013).

A natural evolution of composition mechanisms

is the ability to consider model composition both at

the metamodel and model levels. Put differently, a

composition mechanism should govern the composi-

tion of metamodels and their models. This requires

the composition mechanism to work explicitly on two

abstraction levels where composition-speciﬁc direc-

tives, as required to compose (meta)models, are prop-

agated and utilised for composition of models.

Meta Object Facility (MOF) (OMG, 2014) is the

most prominent architecture for classiﬁcation of mod-

els according to abstraction levels. In this architec-

ture, metamodels reside on the M

level, whereas the

models reside on the M

level. A model contains ob-

jects which are instances of classes in its metamodel.

Thus, a model is classiﬁed by its metamodel. In the

literature, this is typically referred to as the conform-

sTo relationship. A mechanism that supports com-

position of metamodels and the conforming models

would work on both the M

and M

levels, respec-

tively.

In this paper, we discuss how metamodels and

models may be composed virtually non-intrusively.

What this means is that metamodels and models are

kept separate, yet they are composed through a set of

implicitly deﬁned mappings which allow specifying

proxy classes. A proxy class in one metamodel rep-

resents a class in another metamodel. The approach

only requires a minimal refactoring of existing arte-

111

Berg H. and Møller-Pedersen B..

Towards Non-intrusive Composition of Executable Models.

DOI: 10.5220/0005242401110121

In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2015), pages 111-121

ISBN: 978-989-758-083-3

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

facts which may be perfomed automatically or semi-

automatically. The essence of our approach is the

ability to link the operational semantics of languages,

so that models/programs of different languages can

interact at runtime. The ideas presented are applicable

to metamodelling environments that allow express-

ing the operational semantics of a metamodel/lan-

guage using an object-oriented action language, e.g.

the Eclipse Modeling Framework (EMF) (EMF, 2014)

and Kermeta (Muller et al., 2005). The approach has

been validated by the construction of a prototypical

framework on top of EMF. We will use this frame-

work and show how the behaviour of classes/objects

in a General-Purpose Language (GPL) can be deﬁned

by models expressed in a domain-speciﬁc State Ma-

chine Language (SML).

The paper is organised as follows. In Section 2

we deﬁne our non-intrusive composition mechanism.

We then introduce an example in Section 3 and use it

to illustrate the ideas and the mechanics of the frame-

work in Section 4. An evaluation of the composition

mechanism follows in Section 5, and in Section 6 we

discuss our approach in relation to existing work in

the ﬁeld. Finally, in Section 7 we summarise and con-

clude the paper.

2 DEFINITIONS

Traditional (meta)model compositon mechanisms are

explicit in the sense that structural elements from dif-

ferent constituent models are interwoven, e.g. two

classes from different metamodels may be merged

or a class may be made a subtype of another class.

As motivated, this has consequences with respect to

other entities in the metamodelling ecosystem. The

mechanism presented in this paper works by estab-

lishing mappings between metamodels and models in

a practically non-intrusive manner. This means that

the composition is lifted away from the modelling

space and established using a separate speciﬁcation.

There are two types of mappings: M

-mappings and

-mappings. The names reﬂect the MOF level on

which the mappings occur. That is, M

-mappings are

created between metamodel structures, whereas M

mappings are created between model structures (ob-

jects of the classes in the metamodels). Both types

of mappings can be expressed by non-injective partial

functions. M

-mappings are described in a Uniﬁca-

tion Model (UM), while M

-mappings are described

in a Linking Model (LM).

Deﬁnition 1. An M

-mapping is a uni-directional

or bi-directional binding between two structural el-

ements, τ

and π

, in two different metamodels. A

structural element is a package, class, attribute, op-

eration or parameter. A bi-directional binding may

be decomposed into two uni-directional bindings. For

uni-directional bindings, τ

is the source element and

is the target element. For bi-directional bindings,

and π

are both source and target elements corre-

sponding to decomposition of the bi-directional bind-

ing into two uni-directional bindings.

: hτ

7→ π

i(uni − directional)

: hτ

↔ π

i (bi −directional)

where τ

and π

are on either of the forms (N being a

name):

: hN

package

, N

class

: hN

package

, N

class

, N

attribute

: hN

package

, N

class

, N

operation

: hN

package

, N

class

, N

operation

, N

parameter

Deﬁnition 2. A uniﬁcation point is a collection of M

mappings between two classes in two different meta-

models. A uniﬁcation point is either asymmetric or

symmetric. The source class of an asymmetric uniﬁ-

cation point is referred to as a proxy as it represents

a placeholder for the target class. The two classes

of a symmetric uniﬁcation point represent compatible

types. A uniﬁcation point is only valid if both classes

share a common equivalent structure. A class may be

part of an arbitrary number of uniﬁcation points. A

uniﬁcation point χ can be modelled as a set of map-

pings:

: hτ

7→ π

, τ

7→ π

, ..., τ

7→ π

i (asymmetric)

: hτ

↔ π

, τ

↔ π

, ..., τ

↔ π

i (symmetric)

Deﬁnition 3. The (partial) equivalent structure of a

uniﬁcation point is a set of attributes, operations and

operation parameters that both related classes of the

uniﬁcation point need to have. Two classes C

(proxy)

and C

(classes are considered as sets of attributes,

references and operations) of two metamodels may be

uniﬁed if:

∀s

∈ C

· ∃s

∈ C

→ s

∼ s

where ∼ : S × S → Bool is a recursive partial func-

tion that is true if its two arguments have an iden-

tical structure. For symmetric uniﬁcation points,

and C

have to be equipotent, that is: | C

|=|

|. S is a set of structural elements: S =

{Class, Attribute, Re f erence, Operation, Parameter}.

Deﬁnition 4. A Uniﬁcation Model (UM) uniﬁes an

arbitrary number of metamodels. It consists of one

or more uniﬁcation points. Two given metamodels

may be uniﬁed with one or more uniﬁcation points.

The Uniﬁcation Model comprises a set of uniﬁcation

points:

UM : hχ

, χ

, ..., χ

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

112

Deﬁnition 5. An M

-mapping ϕ is a bi-directional

binding between two model elements (objects), with

identiﬁers i and j, in two models x and y. An identiﬁer

encompasses both the class name for which the object

is an instance and a unique integer designator.

ϕ : O

↔ O

, i, j ∈ I

where I is a set of tuples on the form:

hClassName, NaturalNumberi. Inheritance of

attributes and operations (including overriding) is

supported (e.g. binding to an operation speciﬁed in a

superclass to ClassName).

Deﬁnition 6. The Linking Model comprises a set of

-mappings between an arbitrary number of mod-

els:

LM : hϕ

, ϕ

, ..., ϕ

Figure 1 illustrates non-intrusive composition.

The ﬁgure has three metamodels and models of these.

The C

(proxy) class in MM

is uniﬁed asymmetri-

cally with the D

class in MM

, whereas the (proxy)

class D

in MM

is uniﬁed asymmetrically with the

class E

in MM

. The classes C

and D

are uni-

ﬁed symmetrically. That is, C

and D

represent a

structure-wise identical type

. A key feature of the

mechanism is the ability to specify the exact models

(and objects) that should be linked, e.g. the M

model

of MM

is linked with the M

model of MM

: C

-D

: D

-E

: C

-D

(a)

: D

-E

(a)

: C

-D

(s)

: O

-O

: O

-O

: O

-O

: O

-O

: C

-D

1 2

2 3

1 2

2 3

Unification Model:

Linking Model:

Figure 1: Conceptual overview of non-intrusive composi-

tion (class names are omitted for object identiﬁers).

The χ

and χ

uniﬁcation points are illustrated in Fig-

ure 2.

More precisely, D

has the required structure of C

: C

: D

«unification point»

name

String

«unification point»

Figure 2: The χ

(asymmetric) and χ

(symmetric) uniﬁca-

tion points.

For the sake of the illustration, we assume that

the C

class contains an operation O

with a param-

eter P

. The operation and its parameter are uniﬁed

with equivalent structure in D

. M

-mappings bind

instance names of metamodel structure, e.g. the pa-

rameter named P

is bound to the parameter named

. However, for structural equivalence, attribute and

parameter names are irrelevant. What is relevant is the

types of attributes or parameters (and their sequence).

Hence, the types of P

and P

need to be structural

equivalent for the two classes to form a valid uniﬁca-

tion point.

By looking at the χ

uniﬁcation point in the Uni-

ﬁcation Model it is clear that the types C

and D

are

structural equivalent, as both only contain a String at-

tribute, as can be seen by the rightmost uniﬁcation

point. (The two classes represent an identical concept

as seen from an ontological perspective.) At runtime

this implies that an object of C

may be converted to

an object of D

and used in a type-safe invocation

of the O

operation. By construction, all uniﬁcation

points can be represented as tree structures as seen in

the ﬁgure.

The idea of non-intrusive composition is based on

the principle of partial representation. Structural com-

monalities allow for a proxy class to represent another

class, as long as both classes have a set of common

structure (as dictated by the proxy class). Hence, the

proxy class mimics the structure and meaning of an-

other class.

3 EXAMPLE

We will illustrate the approach by exemplifying how

the behaviour of classes/objects in a GPL may be de-

ﬁned using a state machine. Speciﬁcally, we will see

how the state of an object can be maintained by a state

machine and how methods in the class of the object

may be invoked as a consequence of a state change in

the state machine model. To the best of our knowl-

edge, no composition mechanism available can han-

dle simultaneous composition at both the metamodel

TowardsNon-intrusiveCompositionofExecutableModels

113

and model levels in the situation where the behaviour

of classes/objects are deﬁned by a state machine.

Figure 3 gives an overview of the metamodel of

the GPL. The metamodel allows creating very sim-

ple programs. We have kept the number of statement

types to a bare minimum, yet they sufﬁce to model

interesting enough programs for the purpose of illus-

trating our framework. We will not consider other

language artefacts like concrete syntax in detail and

merely use such to visualise models.

name : EString

Class

name : EString

Attribute

Statement

exec(ClassInstance)

MethodCall Assignment

text : EString

Type

Integer

Value

New

value : EInt

create() : ClassInstance

Int

Method

run(ClassInstance)

name : EString

Package

name : EString

0..* classes

0..* methods

0..* statements

0..1 attribute

0..1 reference

1..1 target

1..1 type

1..1 classDef

1..1 source

0..* attributes

1..1 methodDef

exec(ClassInstance)

ClassInstance

Figure 3: Metamodel of a simpliﬁed General-Purpose Lan-

guage (GPL).

Brieﬂy explained, a program consists of a package

with an arbitrary number of classes. The classes may

have attributes and methods. An attribute is either

of the primitive type Integer or class-typed. Methods

have no return type or parameters. They may be de-

ﬁned using a combination of assignments, print state-

ments and method calls. A method may either invoke

other methods deﬁned in the same class or methods

in any other class deﬁned within the same package

by using references (class-typed attributes). ClassIn-

stance represents a (runtime) object of a class. Notice

how Method and Statement both have operations with

a ClassInstance parameter. This allows invoking meth-

ods and executing statements for one particular object

(class instance). A ClassInstance is constructed by in-

voking the operation create() in the New class.

StateMachine

1..1 event

run(Event, EObject)

name : EString

State

step(Event, EObject)

Transition

trigger(Event, EObject)

Action

invoke(EObject)

Event

name : EString

0..1 action

1..1 target

0..* incoming

1..1 source

0..* outgoing

0..* states

1..1 initial

1..1 stateMachine

1..1 current

0..* events

Figure 4: Metamodel of a State Machine Language (SML).

The metamodel for the SML is given in Figure

4. The StateMachine class has an operation named run

that takes two arguments. The ﬁrst parameter is of

type Event, the other is of the more generic type EOb-

ject. The latter allows sending an object of an EObject

subtype as an optional argument when a new event is

raised. The Transition class has an operation named trig-

ger which causes a state change if the event received

matches the event associated with any of the outgo-

ing transitions. The metamodel includes a class Action

with an operation named invoke. The invoke() operation

has to be overridden in a subtype of Action in order to

provide a custom action semantics (when using the

language by itself).

Both metamodels are deﬁned in EMF. The oper-

ational semantics of the classes has been added by

building on the code generated using the built-in code

generator of the EMF framework. Thus, the mod-

els/programs of the two languages may be run stan-

dalone. In order to model the behaviour of objects we

need to extend the GPL metamodel with concepts for

sending signals/events. In particular, we want to add

a new kind of statement that allows sending signals

from within methods. Figure 5 shows how this can be

achieved.

name : EString

Attribute

Statement

exec(ClassInstance)

SendSignal

Behaviour

1..1 attribute

0..1 behaviour

eventName : EString

exec(BehaviourEvent,

ClassInstance)

BehaviourEvent

name : EString

Class

exec(ClassInstance)

0..* attributes

Figure 5: Additional classes for modelling of signal-

s/events.

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

114

Behaviour is intended to be a proxy class for the

StateMachine class in the SML metamodel, whereas

BehaviourEvent is intended to represent the Event class.

Notice that using send signal statements and creating

Behaviour objects are optional, which means that ex-

isting models and tools are not impacted signiﬁcantly,

e.g. existing models of the GPL metamodel are still

valid. That is, classes in the extended GPL language

may have behaviour externally deﬁned if required.

The only required update to e.g. a model editor is to

support creating instances of a proxy class, if such

is added to a metamodel to facilitate composition

(existing classes in a metamodel can also be used as

proxy classes).

package Exam p l e {

class C 1 {

attribute c 2 : C 2

ma i n ( ) {

c2 = new C2 ( );

c2 . pr i n t ( ) ;

se n d S i gn a l ( " O n " , c 2 );

c2 . pr i n t ( ) ;

se n d S i gn a l ( " Off " , c 2 );

c2 . pr i n t ( ) ;

se n d S i gn a l ( " O n " , c 2 );

c2 . pr i n t ( ) ;

}

class C 2 [ beh a v i o u r = true] {

attribute a : I nt

se t A 0 () { a = 0 ; }

se t A 1 () { a = 1 ; }

pr i n t () { _print( " Va l u e : " + a ); }

}

Figure 6: An example GPL program.

The next step is to compose the metamodels and

models in the two languages. The behaviour of the

objects of a class may be modelled by a state ma-

chine. An object’s state thus depends on the current

state of the state machine and what signals (events)

that have been received. The source of such signals

is irrelevant in this case, but we assume there is some

kind of sensor. An example program in the extended

GPL is given in Figure 6. A send signal statement

takes two arguments; an event name and the object

on which to send the signal. The signalling concept

could have been deﬁned to wait for an external event

from e.g. a sensor. A behaviour is associated to the

C2 class by setting a ﬂag named behaviour (resulting

in the creation of a Behaviour object). To keep things

manageable, what we set out to do can be summarised

by these main points:

• Program execution starts by invocation of main

• An ”On” signal/event is sent to an object of the C2

class

• The event is forwarded to the speciﬁed SML

model (utilising the framework)

• The current state of the state machine changes

from Idle to On

• The state change causes invocation of setA1() in

C2 (utilising the framework)

• The value of a is printed to screen

The simple scenario above sufﬁces to underline

the mechanics of our framework.

4 THE FRAMEWORK

We have implemented a prototypical framework that

realises the concepts of this paper. The framework

builds on top of EMF. This means that it works

with all EMF-compatible metamodels and their oper-

ational semantics (model code). Non-intrusive com-

position using the framework corresponds to the ﬁve

phases illustrated in Figure 7. We will discuss each

phase in detail using the example.

Definition of

Code Generators

Specification of

Unification Model

Execution of ModelsGode Generation

Specification of

Linking Model

3 4 5

Figure 7: The ﬁve phases of non-intrusive model composi-

tion.

4.1 Speciﬁcation of Uniﬁcation Model

In order to specify the behaviour for the Class con-

cept using a state machine model we have to create

a set of uniﬁcation points that relate the classes of

the two metamodels. The Behaviour class in the GPL

metamodel is going to represent the StateMachine class

in the SML metamodel, whereas Action will be repre-

senting Method. Furthermore, the BehaviourEvent class

of the GPL metamodel will be uniﬁed with the Event

class of the SML metamodel. Four uniﬁcation points

are required to achieve this.

Behaviour is intended to be a proxy class for

StateMachine. Hence, all the structure of Behaviour

needs to be matched by equivalent structure in

StateMachine, since code generated for the Class con-

cept will implicitly refer to such structure. Behaviour

contains an operation with two parameters; one of

type BehaviourEvent and one of type ClassInstance.

StateMachine contains an operation as well with pa-

rameters of type Event and EObject. The only way that

Behaviour and StateMachine can be uniﬁed is if the Be-

haviourEvent class can be uniﬁed with the Event class

and the ClassInstance class can be uniﬁed with the

TowardsNon-intrusiveCompositionofExecutableModels

115

Behaviour StateMachine

exec

run

BehaviourEvent

ClassInstance

Event

EObject

«unification point»

Method

Action

run

invoke

ClassInstance

EObject

«unification point»

BehaviourEvent

Event

name

String

«unification point»

ClassInstance

EObject

«unification point»

Figure 8: The four uniﬁcation points between classes in the GPL and SML metamodels.

EMF built-in EObject interface. BehaviourEvent con-

sists of an attribute with a String type. Event has a

String attribute as well. Hence, BehaviourEvent and

Event can be uniﬁed by a symmetric uniﬁcation point

since BehaviourEvent and Event are structurally equiva-

lent. Moreover, ClassInstance can be uniﬁed with EOb-

ject. ClassInstance is not a subtype of EObject. How-

ever, the Java counterpart of ClassInstance, ClassIn-

stanceImpl, will be generated as a subtype of the EOb-

jectImpl Java class by the built-in EMF code generator.

EObjectImpl implements the EObject interface. As a re-

sult, Behaviour and StateMachine may indeed be uniﬁed

by an asymmetric uniﬁcation point. The purpose of

the EObject parameter in the run() operation is to al-

low sending an optional argument. In the example, a

ClassInstance object of the C2 class, whose behaviour

is modelled by the state machine model, is passed as

an argument. It is later used to know what object on

which to invoke the setA1() operation. Action contains

an operation named invoke with an EObject parameter,

whereas Method contains an operation run() with a pa-

rameter of type ClassInstance. We have already seen

that ClassInstance and EObject are type-compatible,

thus, Action and Method can be uniﬁed. Notice that

additional structure in StateMachine with respect to Be-

haviour, and additional structure in Method with respect

to Action, would have been ignored as it is not required

for the partial representation whose requirements are

speciﬁed by the proxy classes (Behaviour and Action).

Figure 8 gives the complete Uniﬁcation Model. The

nodes representing parameters are replaced with types

instead of parameter names to improve the readability

of the ﬁgure.

4.2 Deﬁnition of Code Generators

The framework supports the automatic generation of

reﬂective code for linking the operational semantics

of two metamodels non-intrusively. By also using

subtyping and overriding of methods we ensure that

the existing operational semantics does not need to be

changed.

In the example, the added Behaviour class in the

GPL metamodel is intended to represent the StateMa-

chine class in the SML metamodel. This means that

the operational semantics of the Class concept of the

GPL metamodel needs to be revised to reﬂect this.

This is achieved by creating a code generator which

outputs a subtype of ClassImpl. ClassImpl is the Java

class generated by EMF which deﬁnes the Class con-

cept’s operational semantics. The subtype will con-

tain the necessary code for interacting with the op-

erational semantics of the StateMachine class. The

code will be deﬁned in an operation named signal.

The signal() operation has a parameter typed with Be-

haviourEvent and one typed with ClassInstance. It will

be invoked from the operational semantics of the

SendSignal class, i.e. an overridden version of the

exec() operation as deﬁned in Statement. See Figure

public class C l a s sI mp lC us to m extends C l a s s I mp l

{

public void signal ( B e h a vi ou rE ve nt be ,

Cl a s s In st a nc e ci )

{

.. .

}

Figure 9: The subtype of ClassImpl.

Similarly, Action is intended to represent Method.

Thus, a code generator that generates a subtype of the

TransitionImpl class needs to be constructed. The code

generators may be simple Java classes or utilise emit-

ter templates. Code generators are used as tools for

simplifying speciﬁcation of glue code. It is possible

to deﬁne the subtypes manually and utilise the frame-

work directly, though this requires writing a lot more

code.

4.3 Code Generation

The code generators are run to generate code required

for linking the operational semantics of two or more

metamodels. The new code is added to the existing

code deﬁning a metamodel’s operational semantics

by using inheritance. A build script also ensures that

the EMF factories are updated to create objects of the

generated subtypes. The subtypes are still compatible

with EMF. The generated subtypes contain manually

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

116

deﬁned domain-speciﬁc code and automatically pro-

duced reﬂective code. There are two types of reﬂec-

tive code that may be generated: code for accessing

attributes and/or code for invoking operations. The

reﬂective code may be tailored by using a set of sim-

ple options/ﬂags, e.g. it may be required to clone a set

of objects at runtime or send objects as operation ar-

guments that will later be returned in a callback fash-

ion. The framework will take care of forwarding in-

vocations between two metamodels’ operational se-

mantics and convert parameter types at runtime (cor-

responding to symmetric uniﬁcation points). That is,

it eliminates the need for a common type (used in the

deﬁnitions of both metamodels) when sending non-

primitive values.

4.4 Speciﬁcation of Linking Model

The Linking Model allows pin-pointing what (proxy)

object of a given model that should be linked to a (tar-

get) object in another model. The Linking Model is

built by referring to objects of different models and

building pairs of two objects. In principle, there is no

restriction to what objects that may be linked. How-

ever, only pairs that reﬂect uniﬁcation points in the

Uniﬁcation Model are valid.

: Class

"C2"

: Package

"Example"

: Method

"setA0"

GPL Model

SML Model

«mapping #1»

: State

Idle

: State

Off

: State

Machine

: Action

Proxy #1

: Action

Proxy #2

"On"

"Off"

"On"

: Behaviour

Proxy #1

: Method

"setA1"

«mapping #2» «mapping #3»

: Class

"C1"

Figure 10: Linking of the objects in the GPL and SML mod-

els (graphical representation of the Linking Model).

Figure 10 gives a state machine model whose def-

inition captures the intended class/object behaviour,

and the objects of the GPL program previously intro-

duced. Notice the event names that trigger the tran-

sitions, e.g. ”On” for the transition between the Idle

and On states. What we want to achieve is that each

signal/event from the GPL program is forwarded to

the state machine model. Hence, we need to create

an M

-mapping between the Behaviour object and the

object of the StateMachine class. An important point

is that each instance of the C2 class needs a unique

set of runtime objects representing the state machine

model, since their behaviour is independent. This is

achieved by setting a ﬂag when utilising the generate-

OperationCall() method of the framework

. However,

it is still possible to specify the Linking Model with

only one state machine model (at M

). The state ma-

chine model contains two Action objects. These ob-

jects need to be linked to the Method objects represent-

ing the setA0() and setA1() methods. By creating these

mappings, we complete the deﬁnition of the Linking

Model.

4.5 Execution of Models

By linking model objects we are able to ensure that

the corresponding runtime objects (Java objects) are

linked as well. This is essential for the operational

semantics of different metamodels to work in con-

cert. The framework forwards operation invocations

and deals with conversion of runtime objects used as

arguments. It utilises the Uniﬁcation Model to ﬁnd

the correct pairing of classes and creates objects us-

ing reﬂective code. Figure 11 details how the op-

erational semantics of the two languages work to-

gether. It also summarises how non-intrusive compo-

sition works. To avoid confusion we use the term ob-

ject for an M

-object, e.g. the object C1 resulting from

instantiating the Class concept in the GPL metamodel.

For a runtime object of C1 we use the term instance.

Furthermore, invocations of operations (language se-

mantics) are in a regular font, whereas invocations of

methods (in GPL programs) are in an italic font.

The execution starts by invoking the exec() opera-

tion on the Class object that represents C1 in the GPL

model (1). A instance of C1 (represented by a ClassIn-

stance object) is passed as argument to the operation

(manually chosen). The semantics of the exec() oper-

ation invokes the main() method as deﬁned in the C1

class (2). The print() method of the C2 class is then

invoked after instantiating this class (3). The next

statement of the main() method is a send signal state-

ment (4). The semantics of this statement creates a

BehaviourEvent instance and invokes the signal() opera-

tion on the C2 object (5). The BehaviourEvent and C2

instances are passed as arguments to the operation.

signal() invokes the exec() operation on the associated

Behaviour object (6). More precisely, the invocation

The method generates reﬂective code for invocation of

an operation.

TowardsNon-intrusiveCompositionofExecutableModels

117

1. C1.exec( CI[C1] )

«Unification/Linking lookup»

exec() run()

BehaviourEvent["On"] Event["On"]

2. CI[C1].main()

3. CI[C2].print()

4. C1.main.sendSignal

.exec( "On", CI[C2] );

6. C1.behaviour.exec( BE["On"], CI[C2] );

7. StateMachine.run( E["On"], CI[C2] );

8. State.step( E["On"], CI[C2] );

9. Transition.trigger( E["On"], CI[C2] );

10. Action.invoke( CI[C2] );

12. CI[C2] .setA1()

13. CI[C2] .print()

«Unification/Linking lookup»

run() invoke()

class C1

{

attribute c2 : C2;

main()

{

c2 = new C2();

c2.print();

sendSignal( c2, "On" );

c2.print();

...

}

: State

Idle

: State

Off

: State

Machine

: Action

Proxy #1

: Action

Proxy #2

"On"

"Off"

"On"

10.

class C2

{

attribute a : Int;

setA0() { a = 0; }

setA1() { a = 1; }

print() { … }

}

11. 12.

3. 13.

13.

11. C2.setA1.run( CI[C2] )

5. C2.signal( "On", CI[C2] );

Figure 11: Illustration of how a object’s behaviour is executed at runtime. Acronyms used: ClassInstance (CI), Be-

haviourEvent (BE), Event (E).

of exec() does not result in the actual operation in the

Behaviour class to be invoked. Instead the operation

invocation is sent to the framework where it is re-

solved and forwarded as an invocation of the run() op-

eration on the StateMachine object in the SML model

(7). This includes converting the BehaviourEvent in-

stance passed as argument to an Event object. Notice

how the ClassInstance object, representing the instance

of C2, is sent as the second argument. The Event object

causes the transition between the Idle and On state to

be triggered (9). This results in the invoke() operation

on the Action object to be invoked (10), or more pre-

cisely, the invocation of the operation is resolved by

the framework, which forwards the invocation to the

run() operation on the designated Method object (11).

The argument to run() is the ClassInstance object that

was initally passed via the call to the run() operation

on the StateMachine object. The setA1() method is then

invoked on the ClassInstance object, i.e. the instance

of the C2 class. Finally, the print() method is invoked

and the value 1 is printed to screen. Notice how the

Uniﬁcation Model and Linking Model are queried for

information at runtime.

5 EVALUATION

The key problem arising when composing metamod-

els is how existing tools and models are rendered

invalid. The approach of this paper addresses this.

Speciﬁcally, we wanted to show that it is possible

to combine two languages’ operational semantics by

deﬁning mappings between the languages’ concepts

and objects in the models of these languages in a sep-

arate manner. By using reﬂective code we are able to

forward operation invocations and convert parameter

types. The key advantage with our approach is that

the metamodels’ structures are not woven together.

Hence, there are minimal impacts on modelling arte-

facts that are deﬁned relative to the metamodels. Even

though the approach is ﬂexible, it may be required

to design a metamodel in a way that allows it to be

composed with another metamodel. As an example,

it may be required to add a proxy class to an exist-

ing metamodel in order to create the structural bridge

between metamodels. That said, an object of such a

proxy class would be optional and therefore not im-

pact existing tools or models signiﬁcantly. The proxy

class is only instantiated when the metamodel is in-

tended to be composed with another metamodel. An

interesting observation is that the object of a class

changes role depending on whether the class is part of

a uniﬁcation point or not. Consider the Method class

of the GPL metamodel in Figure 3. Let us assume

that we have a metamodel for modelling of methods

- an expression language. The Method class may thus

represent a proxy for the top node class of such an

expression language. In such case, an object of the

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

118

Method class does now have a different purpose. It is

merely used to establish an M

-mapping in the Link-

ing Model. This means that its contained statement

objects would have been ignored. A class may have

several methods. Each method object would thus be

linked to a distinct expression language model.

Evolution of metamodels requires evolution of the

Uniﬁcation Model and Linking Model. However, the

complexity concerned with changing these models

are signiﬁcantly lower than addressing co-evolution

of models and other modelling artefacts.

The mechanism described in this paper focuses on

how the operational semantics of different languages

can work together. The M

- and M

-mappings may

also be used by tools, e.g. by editors, to present inte-

grated views of different languages.

Reﬂective code is known to be slower than non-

reﬂective code. The mechanism discussed in this pa-

per uses reﬂective code to decouple different meta-

models’ operational semantics. However, the reﬂec-

tive code is only active when the operational seman-

tics of the metamodels interact. For the example in

this paper, this adds up to two operation invocations

(with instantiation of arguments) per new signal/event

received. That is, most of the operational seman-

tics being executed is based entirely on non-reﬂective

code.

In the example, we saw how the Behaviour class

is a placeholder for the StateMachine class. Conse-

quently, it appears that an object of Class contains a

StateMachine object via the behaviour containment ref-

erence. This is an important point, because the con-

tainment reference dictates the type of composition

between the GPL and SML metamodels. That is, the

association represents a composition relation.

We have not discussed tool support for creating

the Uniﬁcation Model and Linking Model. In an in-

dustrial context, a reﬂective graphical editor (created

using e.g. GMF) may greatly simplify the process

of specifying these models by allowing to draw the

- and M

-mappings directly between metamodel

and model structure. The graphical models can then

be used to generate the Uniﬁcation Model and Link-

ing Model automatically. A graphical editor may also

provide a simple way of specifying the manual code

required to realise uniﬁcation of two classes’ opera-

tional semantics. An editor may also implement func-

tionality for addressing co-evolution of the models.

6 RELATED WORK

We have not been able to ﬁnd much related work con-

cerned directly with the implicit nature of our com-

position approach. That is, the literature mainly cov-

ers explicit model composition and adaptation strate-

gies using migration techniques and transformations.

Most of the available related work addresses compo-

sition of structure and does not directly consider com-

position of operational semantics.

Methods for automatic co-evolution of metamod-

els and models are necessary to further model-driven

engineering. The work of (Herrmannsdoerfer et al.,

2009) describes how models may be migrated as

a consequence of metamodel adaptations. This is

achieved using coupled transactions. A coupled trans-

action is constructed using a set of primitives. There

are two types of primitives: primitives for query-

ing a metamodel or model, and primitives for mod-

ifying such artefacts. A coupled transaction pre-

serves both metamodel consistency and metamodel-

model conformance. The work has been validated by

implementing a language on top of EMF. With re-

spect to the work of our paper, the method for cou-

pled co-evolution works on metamodels and mod-

els by changing these explicitly. Hence, other mod-

elling artefacts are impacted by the changes, i.e. co-

evolution of tools are not addressed.

Another similar approach for metamodel-model

co-evolution is discussed in (Wachsmuth, 2007). The

work is based on the application of transformations

both on the metamodel and model level. Co-evolution

of metamodels is described using a set of relations

between metamodels, in which are used to ensure se-

mantics and instance preservation for the transforma-

tions.

The authors of (Cicchetti et al., 2008a)(Cicchetti

et al., 2008b) discuss how model migration steps can

be generated directly from a difference model that en-

corporates information on the evolutionary changes of

a metamodel. The difference model is used as basis

for a higher-order transformation in which produces a

transformation that is capable of re-establishing con-

formance between models and their metamodel. The

work addresses concerns related to parallel dependent

metamodel manipulations which may cause conﬂicts

as they work on the same metamodel elements. These

can be resolved in an iterative process, which yields a

set of parallel independent modiﬁcations.

The work of (Herrmannsdoerfer et al., 2011)

presents a catalogue of (coupled) operators for

achieving automated migration of models as a con-

sequence of evolving metamodels. The opera-

tors are classiﬁed according to several dimensions:

language preservation, model preservation and bi-

directionality. The work discussed in our paper does

not utilise coupled operators. However, the M

mappings carefully reﬂect the M

-mappings. Speciﬁ-

TowardsNon-intrusiveCompositionofExecutableModels

119

cally, only objects whose classes are related using M

mappings may safely be related using M

-mappings.

Another approach utilising higher-order transfor-

mations is discussed in (Hoisl et al., 2014). The ap-

proach is based on deﬁning bi-directional transforma-

tions between modelling artefacts, and uses higher-

order transformations on the speciﬁcations of the bi-

directional transformations. This ensures that also the

transformations between the modelling artefacts co-

evolve correctly.

An approach for deﬁning reusable metamodel be-

haviour is discussed in (de Lara and Guerra, 2011).

The approach is based on generic concepts which al-

low adding the same behaviour to unrelated meta-

models. This is achieved by using pattern matching

according to the parameters and requirements of the

concept. A similar approach, in the form of model

types, is discussed in (Steel and Jzquel, 2007).

7 CONCLUSION AND FUTURE

WORK

Composition mechanisms that work on both the meta-

model and model level are important to ensure consis-

tency in the metamodelling ecosystem. In this paper,

we have illustrated how metamodels and models can

be composed in a practically non-intrusive manner in

order for their operational semantics to be linked to-

gether. Non-intrusive composition is achieved by util-

ising a set of mappings, both at the metamodel level

and at the model level. By building on the principle

of partial representation we are able to specify proxy

classes. A proxy class is a placeholder for another

class. Its attributes and operations represent structural

requirements that need to be supported by the class for

which the proxy class is a placeholder. Non-intrusive

composition allows for metamodels and models to

be composed without rendering models, editors and

other modelling artefacts invalid.

An interesting next step is to see whether the map-

pings may be realised in a different form and incorpo-

rated more closely into a language’s deﬁnition, and to

study whether non-intrusive composition brings value

also for non-executable models. Future work also

includes solidiﬁcation of the framework to industry

standard, with the inclusion of a graphical editor.

REFERENCES

Cicchetti, A., D. Ruscio, D., Eramo, R., and Pierantonio,

A. (2008a). Automating co-evolution in model-driven

engineering. In Enterprise Distributed Object Com-

puting Conference (2008).

Cicchetti, A., D. Ruscio, D., Eramo, R., and Pierantonio,

A. (2008b). Meta-model differences for supporting

model co-evolution. In Proceedings of the 2nd Work-

shop on Model-Driven Software Evolution.

de Lara, J. and Guerra, E. (2011). From types to type re-

quirements: Genericity for model-driven engineering.

In Software and Systems Modeling. Springer (2011).

Demuth, A., Lopez-Herrejon, R., and Egyed, A. (2013).

Supporting the co-evolution of metamodels and con-

straints through incremental constraint management.

In Model Driven Engineering Languages and Sys-

tems, LNCS vol. 8107, pp.287-303. Springer (2013).

Di Ruscio, D., Iovino, L., and Pierantonio, A. (2012).

Evolutionary togetherness: How to manage coupled

evolution in metamodeling ecosystems. In Graph

Transformations, LNCS vol. 7562, pp.20-37. Springer

(2012).

EMF (2014). Eclipse modeling framework (emf).

Fleurey, F., Baudry, B., France, R., and Ghosh, S. (2008).

A generic approach for automatic model composition.

In Models in Software Engineering, LNCS vol. 5002,

pp.7-15. Springer (2008).

Garca, J., Diaz, O., and Azanza, M. (2013). Model trans-

formation co-evolution: A semi-automatic approach.

In Software Language Engineering, LNCS vol. 7745,

pp.144-163. Springer (2013).

Groher, I. and Voelter, M. (2007). Xweave - models and

aspects in concert. In 10th international workshop on

Aspect-Oriented Modeling (AOM ’07) pp.35-40. ACM

Press (2007).

Herrmannsdoerfer, M., Benz, S., and Juergens, E. (2009).

Cope: Coupled evolution of metamodels and models

for the eclipse modeling framework. In ECOOP 2009

- Object-Oriented Programming, LNCS vol. 5653,

pp.52-76. Springer (2009).

Herrmannsdoerfer, M., D. Vermolen, S., and Wachsmuth,

G. (2011). An extensive catalog of operators for the

coupled evolution of metamodels and models. In Soft-

ware Language Engineering, LNCS vol. 6563, pp.163-

182. Springer (2011).

Hoisl, B., Hu, Z., and Hidaka, S. (2014). Towards co-

evolution in model-driven development via bidirec-

tional higher-order transformation. In Proceedings

of the 2nd International Conference on Model-Driven

Engineering and Software Development. Springer

(2014) [to appear].

Kolovos, D. S., Paige, R. F., and Polack, F. A. (2006). Merg-

ing models with the epsilon merging language (eml).

In Model Driven Engineering Languages and Sys-

tems, LNCS vol. 4199, pp.215-229. Springer (2006).

Morin, B., Perrouin, G., Lahire, P., Barais, O., Van-

wormhoudt, G., and Jzquel, J.-M. (2009). Weav-

ing variability into domain metamodels. In Model

Driven Engineering Languages and Systems, LNCS

vol. 5795, pp.690-705. Springer (2009).

Muller, P.-A., Fleurey, F., and Jzquel, J.-M. (2005). Weav-

ing executability into object-oriented meta-languages.

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

120

In Model Driven Engineering Languages and Sys-

tems, LNCS vol. 3173, pp.264-278. Springer (2005).

OMG (2014). Meta object facility (mof) core speciﬁcation.

Steel, J. and Jzquel, J.-M. (2007). On model typing. In

Software and Systems Modeling, vol. 6, no. 4, pp.401-

413. Springer (2007).

Wachsmuth, G. (2007). Metamodel adaptation and model

co-adaptation. In ECOOP 2007 - Object-Oriented

Programming, LNCS vol. 4609, pp.600-624. Springer

(2007).

TowardsNon-intrusiveCompositionofExecutableModels

121