Typing and Subtyping of Metamodels

Henning Berg and Birger Møller-Pedersen

Department of Informatics, University of Oslo, Oslo, Norway

Keywords:

Metamodelling, Typing, Subtyping, Domain-speciﬁc Modelling, Languages.

Abstract:

In model-driven engineering, models are considered ﬁrst-class entities. Model-driven engineering has been

around for over a decade. Still, there has not been much work on how to type models or metamodels, which is

important to realise true model-driven software development. In this paper, we discuss how a metamodel can

be typed by means of an enclosing class whose state can be utilised by tools such as editors and interpreters.

This allows using established object-oriented mechanisms on the metamodel level and supports specialisation

of metamodels.

1 INTRODUCTION

Model-Driven Engineering (MDE) (Kent, 2002) is

a collective term for a number of approaches and

methodologies for software development in which

models are ﬁrst-class entities. MDE can be seen as

a natural progression of object-orientation by rais-

ing the abstraction level from the class level to the

model level. A model is a set of interconnected ob-

jects, whose descriptions are formalised by a meta-

model (class model). In spite of MDE’s model-centric

view on software design and development, most MDE

technologies and tools do not have native support for

typing models or metamodels. This has consequences

with respect to reuse of models, model transforma-

tions and interpreters. The notion of polymorphism at

the metamodel level is also unclear, as the type of a

metamodel is not well deﬁned. The work of (Khne,

2010) motivates strongly why model substitutability

is a valuable property to aim for in MDE, whereas

(Khne, 2006) discusses using inheritance, in the form

of subtype specialisations, as a basic relationship be-

tween models.

The work of (Steel and Jzquel, 2007) presents one

approach for realising model typing in MDE. In par-

ticular, the work adresses concerns related to reuse of

model transformations and interpreters, or in general,

situations where externally deﬁned code should be ap-

plicable to a number of different models all sharing

a minimum set of properties as speciﬁed by a refer-

ence model type. However, there are still many open

questions on how to support cases where model types

also cover behavioural semantics, and not just model

structure, software evolution and how to deﬁne func-

tional model types. That is, model types whose deﬁ-

nition also cover behavioural semantics in addition to

structure.

The success of object-orientation is to a large ex-

tent a consequence of its powerful mechanisms, e.g.

specialisation, polymorphism and composition (us-

ing object references). The MDE philosophy sup-

ports the idea that such mechanisms should also be

available at the model and metamodel levels. Many

mechanisms address these aspects of (meta)model us-

age and evolution, e.g. (Fabro et al., 2006)(Kolovos

et al., 2006)(Groher and Voelter, 2007)(Fleurey et al.,

2008)(Morin et al., 2009)(Morin et al., 2008). How-

ever, these mechanisms require the use of additional

frameworks. Furthermore, composition and vari-

ability directives are described in separate resources

(ﬁles) in the form of either a weaving model, point-

cut model or composition/variability rules. Such ad-

ditional resources complicate reuse. They also pose

certain challenges in maintaining ﬁles to reﬂect alter-

ations of the metamodels.

The notion of specialising (as in subtyping) meta-

models has not received the same attention as model

transformations and composition. In this paper, we

discuss how metamodels can be typed by nesting

them within an enclosing class. We will see how the

enclosing class may indeed represent the type of the

enclosed metamodel. The enclosing class can be sub-

typed which allows us to specialise metamodels. We

will focus on metamodels whose behavioural seman-

tics is deﬁned in methods or operations, as supported

by the Eclipse Modeling Framework (EMF) (Eclipse-

111

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

Typing and Subtyping of Metamodels.

DOI: 10.5220/0004713901110118

In Proceedings of the 2nd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2014), pages 111-118

ISBN: 978-989-758-007-9

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

Foundation, 2013a), Kermeta (Muller et al., 2005)

and Epsilon Object Language (EOL) (EclipseFoun-

dation, 2013b).

The paper is organised in ﬁve main sections. Sec-

tion 2 discusses the basic mechanics of using class

nesting to type metamodels, and the purpose of typing

metamodels. Section 3 delves into the matter of using

class nesting for deﬁning metamodel types, whereas

Section 4 presents related work. Section 5 concludes

the paper.

2 METAMODEL TYPES

A metamodel deﬁned in the Essential MetaObject Fa-

cility (EMOF) (OMG, 2013) architecture comprises

a set of classes contained in one or more packages,

whose objects constitute one or more models. The

classes are related by association and specialisation

relationships (in the form of class properties). A

metamodel can be uniquely identiﬁed by the name

and namespace of its containing package. However, a

package is not a semantically powerful concept (Mon-

perrus et al., 2009), and can not be used as a type

speciﬁcation for the contained metamodel. Speciﬁ-

cally, it is not clear how different packages relate and

which operations that can globally be applied on the

data (model objects) described by the package con-

tents (classes).

A class speciﬁes the type of its instances. The type

is deﬁned by the attributes and operations of the class.

In addition, non-static nested classes (inner classes)

contribute to the type, as they can be considered class-

valued attributes. In this paper, we pursue the idea

of deﬁning a metamodel within an enclosing class.

The enclosing class is contained in a package. The

purpose of deﬁning a metamodel within an enclosing

class is that the class explicitly describes a type for the

metamodel. Hence, using an enclosing class allows us

to take advantage of established principles of object-

orientation - at the metamodel level. The metamodel’s

type is that of the enclosing class. In the context of

this paper, we will simply refer to a class that encloses

a metamodel as a metamodel type. A speciﬁc instance

of a metamodel type represents a speciﬁc metamod-

el/language, and models of this metamodel/language

will be in terms of objects of the classes enclosed in

the speciﬁc instance. The instances of a given meta-

model type will be generated by tools, while mod-

ellers will only be concerned with making models us-

ing the enclosed classes.

2.1 Deﬁnitions and Example

Deﬁnition 1. A metamodel type is an enclosing class

containing an arbitrary number of non-static nested

classes, attributes and operations. The nested classes

constitute an EMOF-compatible metamodel. A meta-

model type τ

can be described as the sequence

hname, c, a, oi · s, where c ⊂ C - a ﬁnite set of EMOF-

compatible (nested) classes, a ⊂ A - a ﬁnite set of

attributes (or references), o ⊂ O - a ﬁnite set of op-

erations and s ⊂ T - a ﬁnite set of super metamodel

types.

An example of a state machine metamodel type,

named TStateMachine, is given below:

= hT StateMachine, {StateMachine, State,

Transition, Event}, {sm : StateMachine, events :

Event}, {transitionTable : String}i · nil

Deﬁnition 2. A metamodel type instance is an object

of the class deﬁning a metamodel type. The meta-

model classes of a metamodel type can be accessed

and instantiated via a metamodel type instance. Sev-

eral models can be created using the same instance.

A metamodel type instance may have attributes (ac-

cording to the metamodel type deﬁnition) whose val-

ues can be used to customise the metamodel.

We will use Kermeta to illustrate the idea of meta-

model types

. However, we will only use a subset of

Kermeta to avoid complicating the picture. Kermeta

is an object-oriented language for creating EMOF-

compatible metamodels. It allows specifying the be-

havioural semantics of metamodels within class oper-

ations. The operations are invoked at runtime when

executing a model/program. We do not discuss static

semantics (OCL) in this paper.

Figure 1 gives the metamodel type TStateMachine

implemented in Kermeta syntax. The metamodel type

encloses a metamodel/language for modelling of state

machines. The metamodel comprises the four classes:

StateMachine, State, Transition and Event. StateMachine

is the top node class of the metamodel from which

all other classes are reachable through relationships.

There is a reference typed with this class in the en-

closing TStateMachine class. This reference is used to

access the current model being processed by a tool

(editor, interpreter, etc.). The metamodel details are

not of interest, therefore three consecutive dots are

used to represent content.

As seen in Figure 1, the enclosing class has a ref-

erence typed with the metamodel’s top node class. It

also has a global operation named transitionTable() that

Note that the current version of EMOF/Kermeta does

not support nesting of classes as discussed in this paper.

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

112

returns a textual description of all possible state tran-

sitions captured by a state machine model (i.e. the

model referenced by the sm reference). A step of the

state machine is performed by invoking step(...) in the

State class. The step is carried out if the current state

has a transition whose event value is equal to the op-

eration argument.

package s t a t e_ m a c hi n e ;

class T S t a te M a c hi n e {

// Reference typed with the top node metamodel class

reference sm : Sta t eM ac h in e [1 .. 1 ]

// Events that may occur

attribute e ve nt s : E ve nt [ 1 . . *]

// Operation global to all the metamodel classes

operation t r a n si t io n T a bl e () : S tr in g is do

sm . s ta te s . e ach { s | . .. }

...

result := ...

end

// Metamodel classes

class S t a t eM ac h in e {

attribute s ta te s : S ta te [ 0 . . *]

reference c u r r en tS t at e : Sta te [1 .. 1]

reference i n i t ia lS t at e : Sta te [1 .. 1]

...

}

class S tat e {

attribute n a me : St r i n g

reference i nc om in g : Tr an si t i o n [0 . .* ]

attribute o ut go in g : Tr an si t i o n [0 .. *] # sou rc e

operation s t ep ( e ven t : Eve nt ) is do ... end

...

}

class T ra n s i ti on {

reference s ou rc e : S ta te [ 1 . .1 ]# o u t go in g

reference t ar ge t : S ta te [ 1 . . 1]

reference e ven t : Eve nt [1 .. 1]

operation t ri gg er () is do . . . end

}

class E ven t { .. . }

}

Figure 1: A simple metamodel type for state machines (lan-

guage).

A weighted state machine is a variant of the ba-

sic state machine that supports the description of a

probabilistic aspect of events: how likely that a given

transition should be triggered. This aspect can be ap-

plied to the basic state machine using specialisation.

A ﬁrst attempt to deﬁne this special kind of state ma-

chine would be to deﬁne a subclass of StateMachine.

This seems obvious, as objects of the class StateMa-

chine represent state machine models, and as such the

class StateMachine appears to be the type of all these

models. However, this would not work as intended, as

the addition should be in the Transition class. Hence, a

next step would be to create a subclass of Transition (in

addition to the existing Transition class). However, this

would imply that even simple state machine models

might have weighted transitions. Instead, by deﬁning

the additional properties of a weighted state machine

within a subclass of TStateMachine, we are able to spe-

cialise the state machine metamodel as a holistic en-

tity and clearly differentiate the state machine variants

while still being able to use tools deﬁned according to

the general variant of the state machine metamodel

(tools e.g. editors will not be able to instantiate new

classes that have been added in subtypes). The exist-

ing models of the initial state machine metamodel are

still valid, as changes and added properties are given

in the metamodel type variant. Existing tools may

then invoke redeﬁned virtual operations in the nested

classes of the metamodel subtype. A metamodel type

for a weighted state machine is given below (the ar-

rows indicate inheritance):

= hTWeightedStateMachine, {State ↑

State, Transition ↑ Transition}, {}, {}i ·

{T StateMachine}

Figure 2 illustrates the new metamodel type in

Kermeta. Notice that TWeightedStateMachine is as

a specialisation of TStateMachine. Speciﬁcally, the

classes Transition and State are given additional prop-

erties.

package w e ig h te d _ s t a t e_ m ac h in e ;

require " s ta te _ ma ch i ne . kmt "

class T W ei g ht e d S ta t eM a ch i ne inherits TS t at eM a ch in e {

class S tat e inherits TS t a te Ma c hi ne . S t at e { .. . }

class T ra n s i ti on inherits T S t at e M a ch in e . Tr a n s it io n {

attribute p ro b ab il i t y : Rea l

}

Figure 2: A metamodel type for weighted state machines.

Alternatively, a state machine that supports com-

posite states can be deﬁned as:

= hTCompositeStateMachine,

{CompositeState ↑ State, }, {}, {}i ·

{T StateMachine}

Figure 3 shows the metamodel type in Kermeta

syntax.

package c o mp o si t e_ s t a t e _ ma c hi n e ;

require " s ta te _ ma ch i ne . kmt "

class T C om p os i t e S t a te M ac h in e inherits TS ta t e M ac h i n e {

class C o m p os i te St a te inherits St a te {

attribute s t a t eM ac h in e : St at eM a ch in e [0 .. 1]

}

Figure 3: A state machine metamodel type with simple and

composite state constructs.

Note that this metamodel type includes two

classes for modelling of states: State and CompositeS-

tate.

2.2 Specialisation and Polymorphism

Changing or reﬁning an artefact of a system is not

trivial since changes may impact other parts of the

system, or even other systems. Changes made to arte-

facts at higher abstraction levels typically are more

severe when it comes to impacting other parts of a

TypingandSubtypingofMetamodels

113

software system. A metamodel is a model describing

a set of models, i.e. the language of realisable mod-

els (Favre, 2004). Changing a metamodel impacts

all the conformant models. That is, the language of

valid models that can be recognised is changed. In

most cases, changing a metamodel may render its ex-

isting conformant models incompatible. This in turn

requires manually changing the models or automat-

ing this process by creating a model transformation

that incorporates knowledge about the changes to ap-

ply. Changes to a metamodel also impact its tools. By

using specialisation based upon metamodel types it is

possible to create new metamodel variations without

render existing tools unusable. That is, the tools will

still work by invoking redeﬁned virtual operations.

Hence, some of the challenges of software evolution

(additions) can be tackled.

One of the main contributions using metamodel

types is the ability to use polymorphism. In the exam-

ple, the metamodel type TWeightedStateMachine may

be used as a substitute for TStateMachine. Importantly,

this can be achieved without type casting. External

code deﬁned according to basic state machines can

still be used with weighted state machines.

Metamodel type hierarchies may form a type sys-

tem that facilitates reuse of commonly occurring

metamodel structure and semantics (Cho and Gray,

2011). Using an enclosing class to specify a meta-

model type yields a high degree of encapsulation; a

tool that is built to be compatible with the TStateMa-

chine type can also operate on subtypes of this, e.g.

TWeightedStateMachine.

3 IMPLICATIONS OF

METAMODEL TYPES

3.1 Interpretation and Code Generation

In Kermeta, the metamodels’ behavioural semantics

are deﬁned in class operations. For instance, the se-

mantics for stepping/triggering a new state in the state

machine metamodel is deﬁned in the step(...) and trig-

ger() operations in the State and Transition classes. The

exact deﬁnition of this semantics is not interesting.

However, it is clear that the default stepping/trigger-

ing semantics will not sufﬁce for a weighted state ma-

chine. By subtyping State and Transition, the semantics

of these classes can be redeﬁned for the new state ma-

chine type. The main point here is that a framework

for interpretation of state machine models will still

work on the redeﬁned semantics due to dynamic bind-

ing, e.g. such a framework may invoke the step(...)

and trigger() operations. Figure 4 shows a skeletal of

such a framework. This code will work regardless of

state machine variants (a consequence of virtual oper-

ations).

class S t at e Ma c h i n e I n t e rp r et e r

{

operation i nt e r p re t ( T S t at e M a ch i n e . St a te Ma c hi ne s m ) is do

var i ni ti al : St ate init s m . i ni ti a lS ta t e

...

in it ia l . s te p ( eve nt )

...

end

}

Figure 4: Excerpt of an interpreter for execution of state

machine models.

A typical approach for generating executable

DSLs is to use code generators that work on purely

structural metamodels/models.

However, the operations may also be used to im-

plement a code generator (where each class contains

code for a target language). Since we allow subtyp-

ing both the enclosing class and the inner classes of

a metamodel type, we are able to redeﬁne the code

generator using virtual operations (and types).

3.2 Analysis Tools

The operations in the classes may also be used to

generate information about the conformant models.

In particular the enclosing class may contain opera-

tions that work on models as a whole. We have given

one such operation in the TStateMachine, namely tran-

sitionTable(). This operation contains semantics that

is not part of of the metamodel/language for creat-

ing state machines. Yet, it allows calculating infor-

mation about a state machine that can be presented

to the modeller during the modelling process. By us-

ing subtyping it is possible for analysis tools to work

on metamodel variants, since the access points of the

analysis tools are predeﬁned as global operations in

the enclosing class.

3.3 Type Safety

In this paper, we relate variants of metamodel types

using the subtyping relation (Liskov and Wing, 1994).

Subtyping imposes certain restrictions on subtypes:

the parameter types of an operation are required to be

contravariant, whereas the return type needs to be co-

variant. What this means is that virtual operations of

subtypes can be invoked type-safely in place of their

supertype equivalents. As pointed out in (Steel and

Jzquel, 2007), types of class properties are required

to be invariant in MetaObject Facility (MOF) (OMG,

2013) metamodels. This latter requirement is difﬁ-

cult to fulﬁll, as additions of attributes and references

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

114

to a class is common when creating metamodel vari-

ants. Such additions change the type of the contain-

ing class, which in turn results in a covariant redeﬁ-

nition of attributes and references that are typed with

the class. Let us see how this affects metamodel types

as presented in this paper.

There are two places where subtyping occurs in

creating a metamodel type variant. First, the enclos-

ing class is subtyped. Second, the inner classes con-

stituting the metamodel may be subtyped selectively

depending on which specialisations that are required.

Recall how the Transition class needs an additional at-

tribute probability to create a weighted state machine

metamodel from the basic state machine metamodel.

Let us assume that this would be the only required

addition to the basic state machine metamodel. What

we have now is a situation of covariant type redeﬁni-

tion. The attributes incoming and outgoing of the State

class (see Figure 1) are typed with Transition. The new

Transition class variant contains an additional attribute.

Hence, the types of the incoming and outgoing refer-

ences in the State class of the metamodel type variant

(TWeightedStateMachine) are not invariant, but covari-

ant. A potential problem would occur when related

metamodel types are mixed, e.g. when a model con-

tains instances of both state machine and weighted

state machine metamodel classes. However, these sit-

uations do not occur since e.g. a model editor has to

instantiate either of these types. Hence, it is not pos-

sible to instantiate the subtype of the Transition class

when creating a basic state machine.

Attributes and references have multiplicities

which indicate the possible amount of values/objects

the properties may take. We consider attributes and

references to be immutable.

An important ability in metamodels is to deﬁne

bi-directional relationships. Using bi-directional re-

lationships in the nested metamodel of a metamodel

type does not induce any new challenges.

According to (OMG, 2011), classes in MOF do

not deﬁne XMI namespaces. Nesting of classiﬁers

may thus yield name collisions. However, the idea

presented in this paper utilises a constrained form of

class nesting, where the enclosing class has a special

role. We do not discuss arbitrary nesting of classes.

3.4 Multiple Inheritance

We have seen how metamodel types can be used to

represent metamodel patterns or fragments, e.g. a

state machine. We have also discussed how a meta-

model can be considered and interpreted from the per-

spective of one speciﬁc metamodel type. Seen in the

light of this, a metamodel may have several types. Put

differently, a metamodel can be constructed by com-

bining an arbitrary number of patterns. This means

that a metamodel can also be considered from sev-

eral perspectives depending on situation and purpose

(e.g. a tool may present several viewpoints to the

user, where each viewpoint correspond to a meta-

model type).

package m et a m o de l ;

require " s ta te _ ma ch i ne . kmt "

require " ga me . k mt "

class T Me t a m od el inherits TS ta te Ma ch in e , T G am e

...

}

Figure 5: Using multiple inheritance to relate metamodel

types (yielding a composite metamodel).

Regardless of specialisations of the inner classes,

the enclosed metamodel of TMetamodel can still be

considered from two perspectives/aspects: state ma-

chines and game. That is, tools deﬁned for TStateMa-

chine and TGame can still be used. For example, it is

convenient to analyse a model conforming to the com-

posite metamodel from the state machine perspective

alone, e.g. by writing out the state transition table or

similar. This is possible regardless of the added prop-

erties in specialisations of the inner classes.

Using multiple inheritance may potentially re-

quire resolution of name conﬂicts. There are several

approaches to improve the applicability of multiple

inheritance, e.g. Kermeta allows the modeller to ex-

plicitly specify the operation to override in ambigious

situations. We will not go into details on this subject.

3.5 Deﬁning Metamodel Types

A metamodel type can be created automatically by

enclosing the metamodel in a class. Additional at-

tributes and operations may then be added by the

metamodel developer if required. An enclosing class

may also be created implicitly by tools, e.g. if a meta-

model is not deﬁned as a metamodel type. This works

as long as no additional elements are required in the

enclosing class.

3.6 Using Virtual Classes and Generic

Parameters

The classes of a metamodel type can both be deﬁned

as virtual and utilise generic type parameters. Let us

return to our example. If the language for making

metamodels (e.g. Kermeta) supports virtual classes

(Madsen and Mller-Pedersen, 1989), then the Transi-

tion could be deﬁned as a virtual class and then rede-

ﬁned in TWeightedStateMachine (by extending the Tran-

TypingandSubtypingofMetamodels

115

sition class). This allows code in TStateMachine to gen-

erate Transition objects with the additional property,

given that the context in which this code is executed

is an object of TWeightedStateMachine. For an in-depth

discussion on this topic, see (Berg et al., 2011). Vir-

tual classes also allows existing tools like editors to

instantiate redeﬁned classes in subtypes.

3.7 Metamodel Customisation

In its simplest form, an enclosing class does not

contain other elements than the nested metamodel

classes. The enclosing class may also contain at-

tributes and operations. This adds a new dimension

to metamodels. Speciﬁcally, the state of a meta-

model type object can be used to customise the be-

havioural semantics of its encapsulated metamodel.

As an example, the behavioural semantics of a meta-

model (as deﬁned in operations) may use different

algorithms depending on context. These algorithms

may share basic properties (attributes) whose values

can be changed with the intention of tuning the be-

havioural semantics for a speciﬁc usage or context.

Being able to adjust these properties simultaneously

for all the algorithms allows customising the seman-

tics easily without changing the actual models. The

properties with their values are in the object of the en-

closing class. Hence, this object’s state captures an

(execution) conﬁguration for models of a given meta-

model/language. Changing such values for a meta-

model/language would change the meaning for all

conformant models/programs. It would also be possi-

ble to maintain several objects of the enclosing class

and thereby facilitate execution proﬁles (serialised to

ﬁles). However, this will give rise to an additional

level of polymorphism as different object states give

different execution results.

4 RELATED WORK

There are several mechanisms that address model

composition and variability. Some of these are dis-

cussed in (Berg and Mller-Pedersen, 2013). Common

to these mechanisms is their external deﬁnition from

the language used to deﬁne the models and/or meta-

models. Moreover, most mechanisms use some kind

of merging techniques to combine the metamodels

which compromises the principle of encapsulation.

We have used Kermeta to illustrate metamodel

types. Kermeta features a mechanism known as static

introduction. This mechanism allows specifying par-

tial class deﬁnitions using aspects. Several aspect def-

initions are combined (or woven) at runtime to form

the deﬁnition of a class. The mechanism allows deﬁn-

ing new aspects that are combined with an existing

class deﬁnition. Aspects allow creating metamodel

variants. However, they can not be used to type a

metamodel - the resulting classes are contained in a

regular package.

Model types, as described in (Steel and Jzquel,

2007) resembles the work of this paper. There are

some differences and similarities that we will discuss.

First, a model type can be seen as a type-safe set

of an arbitrary number of model object types. The

model type mechanism deﬁnes a conformance rela-

tion between model types, which allows reusing code

or transformations. Speciﬁcally, code for manipulat-

ing or executing models (interpretation) can be de-

ﬁned according to a reference model type. All models

that are typed with a model type conformant to the ref-

erence model type can be manipulated or executed by

the same code. A model type is created by referring to

classes of an arbitrary number of existing metamod-

els. This is a powerful ability, since classes deﬁned in

different packages can be ”extracted” to constitute a

model type.

A metamodel type, as discussed in this paper, al-

lows typing metamodels as holistic MDE structures.

We have used the notion metamodel type instead of

model type because of a signiﬁcant difference be-

tween the approaches. An instance of a metamodel

type (object of the enclosing class) represents one par-

ticular metamodel. The object can be used to access

the metamodels’ classes and thereby create model ob-

jects. The object of the enclosing class also refer-

ences one model whose semantics is e.g. intended

to be executed at runtime. Conversely, in the work

of (Steel and Jzquel, 2007), an instance of a model

type can not be used to instantiate the classes of the

model type. Instances of these classes are instead

added to the model type instance. The model type in-

stance acts as a ﬁlter where only objects of the model

type’s classes can be added to the model type instance

successfully. The similarity in this respect between

the approaches is that both a metamodel type instance

and a model type instance can be used to reference a

conformant model. The capabilities of the two model

typing approaches differ. Model types are designed to

simplify reuse of code from an external perspective,

e.g. from the perspective of an interpreter or transfor-

mation. Conversely, metamodel types allow creating

metamodel variants. By design, metamodel types are

functional types. Reuse of code is achieved by cre-

ating type variants in the form of subtypes. Model

types, on the other hand, are structural. They can not

be combined, or be related to create variations.

The inability to use substitution in model typing

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

116

is addressed by (Guy et al., 2012). The paper dis-

cusses four subtyping mechanisms, and how these al-

low deﬁning relations between model types as deﬁned

in (Steel and Jzquel, 2007). The work differentiates

between total and partial subtyping relations, that are

either isomorphic (model type matching with respect

to properties and operations) or non-isomorphic. Ac-

cording to the deﬁnitions of (Guy et al., 2012), using

an enclosing class as type speciﬁcation for metamod-

els can be seen as a total isomorphic subtyping rela-

tion that is declared explicitly. The explicitly declared

subtyping relation allows reusing structure of super-

types through inheritance. And, as we have seen, the

inherited classes can be redeﬁned. Using an enclos-

ing class supports compile-time checking of the sub-

typing relations between types. It is stated in (Guy

et al., 2012) that it is not possible to achieve type

group substitutability using object subtyping. The

work on metamodel types shows that this is in fact

possible when a metamodel is a property of an object

- as realised using class nesting. Hence, we are able

to achieve type group substitutability based upon es-

tablished object subtyping principles. This includes

the ability to reuse existing type checking algorithms.

The drawback of our approach is that substitutability

of metamodels can not be deﬁned partially. However,

as illustrated, a metamodel can be typed according to

several metamodel types, which addresses this con-

cern to some extent.

An approach for generic speciﬁcation of meta-

model’s behaviour is discussed in (de Lara and

Guerra, 2011). The approach relies on the use of

generic concepts to deﬁne behaviour that is applica-

ble to a family of unrelated metamodels. Concepts

allow specifying details of models’ structure by util-

ising parameters. A concept can be bound to meta-

models that satisfy the concept’s requirements using

pattern matching. There is no dependency between a

metamodel and a concept. Hence, utilising concepts

is non-intrusive. Conversely, we have seen how meta-

model types are related using subtyping in two levels.

In other words, we utilise a typical object-oriented

typing scheme that allows deﬁning metamodel vari-

ants explicitly using subtyping.

Specialisation relationships between models are

carefully discussed in (Khne, 2010). The work for-

malises two relations for specifying forward- and

backward-compatibility between models and applies

these relations to, e.g. models related using subtyp-

ing. The compatibility relations are deﬁned using a

deﬁnition of conformance. Forward-compatibility is

achieved if instances of a submodel conform to the su-

permodel, and vice versa for backward-compatibility.

One important point discussed is the desire to max-

imise the forward-compatibility of a language since

this allows reusing existing tools on new models (via

redeﬁned virtual operations). The subtyping relation

ensures a high degree of forward-compatibility. Sub-

typing also guarantees mutator forward-compatibility.

This supports a round-trip between new instances of

submodels and support of these by existing tools.

That is, the submodel instances appear like super-

model instances. Subtyping is the most restrictive

specialisation relationship, with strict behaviour con-

formance of subtypes. We believe that this type of re-

lationship is the best suited to relate metamodel types.

5 CONCLUSIONS

The work discussed in this paper presents a novel way

of typing a metamodel by deﬁning it within an enclos-

ing class. The purpose of the enclosing class is to fa-

cilitate object-orientation at the metamodel level that

can be utilised by tools. Hence, we achieve a man-

ner of deﬁning functional types for metamodels that

can be related using subtyping. An object of the en-

closing class is not part of a model, but used by tools

to manage the enclosed metamodel. Subtyping en-

sures substitutability between metamodel types. That

is, tools deﬁned according to a metamodel type can be

reused on subtype variations of this metamodel type

(possible by redeﬁnition of virtual operations). An-

other important aspect of using subtyping is the abil-

ity to maintaining conformance between models and

their metamodels.

To the best of our knowledge, there are currently

no metamodelling tools or environments that support

nesting of classes. Formalising and implementing a

complete type system with inner classes is a very

time-consuming endeavour. As a ﬁrst iteration, we

have therefore focused on the theoretical approach to

the subject.

REFERENCES

Berg, H. and Mller-Pedersen, B. (2013). Type-safe symmet-

ric composition of metamodels using templates. In

7th International Workshop on System Analysis and

Modelling (SAM ’12), LNCS vol. 7744, pp.160-178.

Springer (2013).

Berg, H., Mller-Pedersen, B., and Krogdahl, S. (2011). Ad-

vancing generic metamodels. In SPLASH ’11 Work-

shops Proceedings, pp.19-24. ACM Press (2011).

Cho, H. and Gray, J. (2011). Design patterns for metamod-

els. In SPLASH ’11 Workshops Proceedings, pp.25-

32. ACM Press (2011).

TypingandSubtypingofMetamodels

117

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).

EclipseFoundation, T. (2013a). Eclipse modeling frame-

work (emf).

EclipseFoundation, T. (2013b). Epsilon object language

(eol).

Fabro, M. D. D., Bzivin, J., and Valduriez, P. (2006). Weav-

ing models with the eclipse amw plugin. In Eclipse

Modeling Symposium, Eclipse Summit Europe 2006.

Favre, J.-M. (2004). Towards a basic theory to model model

driven engineering. In 3rd International Workshop on

Software Model Engineering (WISME ’04).

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).

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).

Guy, C., Combemale, B., Derrien, S., Steel, J., and

Jzquel, J.-M. (2012). On model subtyping. In Mod-

elling Foundations and Applications, LNCS vol. 7349,

pp.400-415. Springer (2012).

Kent, S. (2002). Model driven engineering. In Inte-

grated Formal Methods, LNCS vol. 2335, pp.286-298.

Springer (2002).

Khne, T. (2006). Matters of (meta-) modeling. In Soft-

ware and Systems Modeling, vol. 5, no. 4, pp.387-394.

Springer (2006).

Khne, T. (2010). An observer-based notion of model inher-

itance. In Model Driven Engineering Languages and

Systems, LNCS vol. 6394, pp.31-45. Springer (2010).

Kolovos, D., Paige, R., and Polack, F. (2006). Merging

models with the epsilon merging language (eml). In

Model Driven Engineering Languages and Systems,

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

Liskov, B. and Wing, J. (1994). A behavioral notion of sub-

typing. In ACM Transactions on Programming Lan-

guages and Systems, vol. 16, no. 6., pp.1811-1841.

ACM Press (1994).

Madsen, O. L. and Mller-Pedersen, B. (1989). Virtual

classes - a powerful mechanism in object-oriented

programming. In Proceedings of OOPSLA ’89.

Monperrus, M., Beugnard, A., and Champeau, J. (2009). A

deﬁnition of abstraction level for metamodels. In 16th

Annual IEEE International Conference and Work-

shop on the Engineering of Computer Based Sys-

tems (ECBS ’09), pp.315-320, IEEE Computer Soci-

ety (2009).

Morin, B., Klein, J., and Barais, O. (2008). A generic

weaver for supporting product lines. In 13th Interna-

tional Workshop on Early Aspects (EA ’08), pp.11-18.

ACM Press (2008).

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.

In Model Driven Engineering Languages and Sys-

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

OMG (2011). Omg issue 7603, received 27th of july 2004,

closed 27th of may 2011.

OMG (2013). 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).

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

118