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 structure, software evolution and how to define functional model types. That is, model types whose definition also cover behavioural semantics in addition to Model-Driven Engineering (MDE) (Kent, 2002) is structure. a collective term for a number of approaches and methodologies for software development in which The success of object-orientation is to a large ex- models are first-class entities. MDE can be seen as tent a consequence of its powerful mechanisms, e.g. a natural progression of object-orientation by rais- specialisation, polymorphism and composition (using the abstraction level from the class level to the ing object references). The MDE philosophy sup- model level. A model is a set of interconnected ob- ports the idea that such mechanisms should also be jects, whose descriptions are formalised by a meta- available at the model and metamodel levels. Many model (class model). In spite of MDE’s model-centric mechanisms address these aspects of (meta)model us- view on software design and development, most MDE age and evolution, e.g. (Fabro et al., 2006)(Kolovos technologies and tools do not have native support for et al., 2006)(Groher and Voelter, 2007)(Fleurey et al., typing models or metamodels. This has consequences 2008)(Morin et al., 2009)(Morin et al., 2008). How- with respect to reuse of models, model transforma- ever, these mechanisms require the use of additional tions and interpreters. The notion of polymorphism at frameworks. Furthermore, composition and vari- the metamodel level is also unclear, as the type of a ability directives are described in separate resources metamodel is not well defined. The work of (Khne, (files) in the form of either a weaving model, point- 2010) motivates strongly why model substitutability cut model or composition/variability rules. Such ad- is a valuable property to aim for in MDE, whereas ditional resources complicate reuse. They also pose (Khne, 2006) discusses using inheritance, in the form certain challenges in maintaining files to reflect alter- of subtype specialisations, as a basic relationship be- ations of the metamodels. tween models. The notion of specialising (as in subtyping) meta- The work of (Steel and Jzquel, 2007) presents one models has not received the same attention as model approach for realising model typing in MDE. In par- transformations and composition. In this paper, we ticular, the work adresses concerns related to reuse of discuss how metamodels can be typed by nesting model transformations and interpreters, or in general, them within an enclosing class. We will see how the situations where externally defined code should be ap- enclosing class may indeed represent the type of the plicable to a number of different models all sharing enclosed metamodel. The enclosing class can be sub- a minimum set of properties as specified by a refer- typed which allows us to specialise metamodels. We ence model type. However, there are still many open will focus on metamodels whose behavioural seman- questions on how to support cases where model types tics is defined in methods or operations, as supported also cover behavioural semantics, and not just model by the Eclipse Modeling Framework (EMF) (Eclipse-

Berg H. and Møller-pedersen B.. 111 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 Copyright c 2014 SCITEPRESS (Science and Technology Publications, Lda.) MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

Foundation, 2013a), Kermeta (Muller et al., 2005) 2.1 Definitions and Example and Epsilon Object Language (EOL) (EclipseFoun- dation, 2013b). Definition 1. A metamodel type is an enclosing class The paper is organised in five main sections. Sec- containing an arbitrary number of non-static nested tion 2 discusses the basic mechanics of using class classes, attributes and operations. The nested classes nesting to type metamodels, and the purpose of typing constitute an EMOF-compatible metamodel. A meta- metamodels. Section 3 delves into the matter of using model type τm can be described as the sequence class nesting for defining metamodel types, whereas hname,c,a,oi · s, where c ⊂ C - a finite set of EMOF- Section 4 presents related work. Section 5 concludes compatible (nested) classes, a ⊂ A - a finite set of the paper. attributes (or references), o ⊂ O - a finite set of operations and s ⊂ T - a finite set of super metamodel types. 2 METAMODEL TYPES An example of a state machine metamodel type, named TStateMachine, is given below: A metamodel defined in the Essential MetaObject Fa- τm = hTStateMachine,{StateMachine, State, cility (EMOF) (OMG, 2013) architecture comprises Transition, Event},{sm : StateMachine, events : a set of classes contained in one or more packages, Event}, {transitionTable : String}i · nil whose objects constitute one or more models. The classes are related by association and specialisation Definition 2. A metamodel type instance is an object relationships (in the form of class properties). A of the class defining a metamodel type. The meta- metamodel can be uniquely identified by the name model classes of a metamodel type can be accessed and namespace of its containing package. However, a and instantiated via a metamodel type instance. Sev- package is not a semantically powerful concept (Mon- eral models can be created using the same instance. perrus et al., 2009), and can not be used as a type A metamodel type instance may have attributes (ac- specification for the contained metamodel. Specifi- cording to the metamodel type definition) whose val- cally, it is not clear how different packages relate and ues can be used to customise the metamodel. which operations that can globally be applied on the We will use Kermeta to illustrate the idea of meta- data (model objects) described by the package con- model types1. However, we will only use a subset of tents (classes). Kermeta to avoid complicating the picture. Kermeta A class specifies the type of its instances. The type is an object-oriented language for creating EMOF- is defined by the attributes and operations of the class. compatible metamodels. It allows specifying the be- In addition, non-static nested classes (inner classes) havioural semantics of metamodels within class oper- contribute to the type, as they can be considered class- ations. The operations are invoked at runtime when valued attributes. In this paper, we pursue the idea executing a model/program. We do not discuss static of defining a metamodel within an enclosing class. semantics (OCL) in this paper. The enclosing class is contained in a package. The Figure 1 gives the metamodel type TStateMachine purpose of defining a metamodel within an enclosing implemented in Kermeta syntax. The metamodel type class is that the class explicitly describes a type for the encloses a metamodel/language for modelling of state metamodel. Hence, using an enclosing class allows us machines. The metamodel comprises the four classes: to take advantage of established principles of object- StateMachine, State, Transition and Event. StateMachine orientation - at the metamodel level. The metamodel’s is the top node class of the metamodel from which type is that of the enclosing class. In the context of all other classes are reachable through relationships. this paper, we will simply refer to a class that encloses There is a reference typed with this class in the en- a metamodel as a metamodel type. A specific instance closing TStateMachine class. This reference is used to of a metamodel type represents a specific metamod- access the current model being processed by a tool el/language, and models of this metamodel/language (editor, interpreter, etc.). The metamodel details are will be in terms of objects of the classes enclosed in not of interest, therefore three consecutive dots are the specific instance. The instances of a given meta- used to represent content. model type will be generated by tools, while mod- As seen in Figure 1, the enclosing class has a ref- ellers will only be concerned with making models us- erence typed with the metamodel’s top node class. It ing the enclosed classes. also has a global operation named transitionTable() that

1Note that the current version of EMOF/Kermeta does not support nesting of classes as discussed in this paper.

112 TypingandSubtypingofMetamodels

returns a textual description of all possible state tran- the general variant of the state machine metamodel sitions captured by a state machine model (i.e. the (tools e.g. editors will not be able to instantiate new model referenced by the sm reference). A step of the classes that have been added in subtypes). The exist- state machine is performed by invoking step(...) in the ing models of the initial state machine metamodel are State class. The step is carried out if the current state still valid, as changes and added properties are given has a transition whose event value is equal to the op- in the metamodel type variant. Existing tools may eration argument. then invoke redefined virtual operations in the nested classes of the metamodel subtype. A metamodel type package state_machine; for a weighted state machine is given below (the ar- class TStateMachine { rows indicate inheritance): // Reference typed with the top node metamodel class reference sm : StateMachine[1..1] τmw = hTWeightedStateMachine, {State ↑ State, Transition ↑ Transition},{},{}i · // Events that may occur attribute events : Event[1..*] {TStateMachine} // Operation global to all the metamodel classes Figure 2 illustrates the new metamodel type in operation transitionTable() : String is do sm.states.each{ s | ... } Kermeta. Notice that TWeightedStateMachine is as ... result := ... a specialisation of TStateMachine. Specifically, the end classes Transition and State are given additional prop- // Metamodel classes class StateMachine { erties. attribute states : State[0..*] reference currentState : State[1..1] reference initialState : State[1..1] ... package weighted_state_machine; } require "state_machine.kmt" class State { class TWeightedStateMachine inherits TStateMachine { attribute name : String class State inherits TStateMachine.State { ... } reference incoming : Transition[0..*] class Transition inherits TStateMachine.Transition { attribute outgoing : Transition[0..*]#source attribute probability : Real operation step( event : Event ) is do ... end } ... } } class Transition { Figure 2: A metamodel type for weighted state machines. reference source : State[1..1]#outgoing reference target : State[1..1] reference event : Event[1..1] operation trigger () is do ... end Alternatively, a state machine that supports com- } posite states can be defined as: class Event { ... } } τmc = hTCompositeStateMachine, {CompositeState ↑ State,},{},{}i · Figure 1: A simple metamodel type for state machines (lan- {TStateMachine} guage). Figure 3 shows the metamodel type in Kermeta syntax. A weighted state machine is a variant of the basic state machine that supports the description of a package composite_state_machine; probabilistic aspect of events: how likely that a given require "state_machine.kmt" transition should be triggered. This aspect can be ap- class TCompositeStateMachine inherits TStateMachine { class CompositeState inherits State { plied to the basic state machine using specialisation. attribute stateMachine : StateMachine[0..1] } A first attempt to define this special kind of state ma- } chine would be to define a subclass of StateMachine. This seems obvious, as objects of the class StateMa- Figure 3: A state machine metamodel type with simple and chine represent state machine models, and as such the composite state constructs. class StateMachine appears to be the type of all these models. However, this would not work as intended, as Note that this metamodel type includes two the addition should be in the Transition class. Hence, a classes for modelling of states: State and CompositeS- next step would be to create a subclass of Transition (in tate. addition to the existing Transition class). However, this would imply that even simple state machine models 2.2 Specialisation and Polymorphism might have weighted transitions. Instead, by defining the additional properties of a weighted state machine Changing or refining an artefact of a system is not within a subclass of TStateMachine, we are able to spe- trivial since changes may impact other parts of the cialise the state machine metamodel as a holistic en- system, or even other systems. Changes made to arte- tity and clearly differentiate the state machine variants facts at higher abstraction levels typically are more while still being able to use tools defined according to severe when it comes to impacting other parts of a

113 MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

software system. A metamodel is a model describing and trigger() operations. Figure 4 shows a skeletal of a set of models, i.e. the language of realisable mod- such a framework. This code will work regardless of els (Favre, 2004). Changing a metamodel impacts state machine variants (a consequence of virtual oper- all the conformant models. That is, the language of ations). valid models that can be recognised is changed. In most cases, changing a metamodel may render its ex- class StateMachineInterpreter { isting conformant models incompatible. This in turn operation interpret( TStateMachine.StateMachine sm ) is do var initial : State init sm.initialState requires manually changing the models or automat- ... initial.step( event ) ing this process by creating a model transformation ... end 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 Figure 4: Excerpt of an interpreter for execution of state possible to create new metamodel variations without machine models. render existing tools unusable. That is, the tools will still work by invoking redefined virtual operations. A typical approach for generating executable Hence, some of the challenges of software evolution DSLs is to use code generators that work on purely (additions) can be tackled. structural metamodels/models. One of the main contributions using metamodel However, the operations may also be used to im- types is the ability to use polymorphism. In the exam- plement a code generator (where each class contains code for a target language). Since we allow subtyp- ple, the metamodel type TWeightedStateMachine may ing both the enclosing class and the inner classes of be used as a substitute for TStateMachine. Importantly, this can be achieved without type casting. External a metamodel type, we are able to redefine the code code defined according to basic state machines can generator using virtual operations (and types). still be used with weighted state machines. Metamodel type hierarchies may form a type sys- 3.2 Analysis Tools tem that facilitates reuse of commonly occurring metamodel structure and semantics (Cho and Gray, The operations in the classes may also be used to 2011). Using an enclosing class to specify a meta- generate information about the conformant models. model type yields a high degree of encapsulation; a In particular the enclosing class may contain operations that work on models as a whole. We have given tool that is built to be compatible with the TStateMa- one such operation in the TStateMachine, namely tran- chine type can also operate on subtypes of this, e.g. sitionTable(). This operation contains semantics that TWeightedStateMachine. is not part of of the metamodel/language for creating state machines. Yet, it allows calculating information about a state machine that can be presented 3 IMPLICATIONS OF to the modeller during the modelling process. By us- METAMODEL TYPES ing subtyping it is possible for analysis tools to work on metamodel variants, since the access points of the analysis tools are predefined as global operations in 3.1 Interpretation and Code Generation the enclosing class.

In Kermeta, the metamodels’ behavioural semantics 3.3 Type Safety are defined in class operations. For instance, the semantics for stepping/triggering a new state in the state In this paper, we relate variants of metamodel types machine metamodel is defined in the step(...) and trig- using the subtyping relation (Liskov and Wing, 1994). ger() operations in the State and Transition classes. The Subtyping imposes certain restrictions on subtypes: exact definition of this semantics is not interesting. the parameter types of an operation are required to be However, it is clear that the default stepping/trigger- contravariant, whereas the return type needs to be co- ing semantics will not suffice for a weighted state ma- variant. What this means is that virtual operations of chine. By subtyping State and Transition, the semantics subtypes can be invoked type-safely in place of their of these classes can be redefined for the new state ma- supertype equivalents. As pointed out in (Steel and chine type. The main point here is that a framework Jzquel, 2007), types of class properties are required for interpretation of state machine models will still to be invariant in MetaObject Facility (MOF) (OMG, work on the redefined semantics due to dynamic bind- 2013) metamodels. This latter requirement is diffi- ing, e.g. such a framework may invoke the step(...) cult to fulfill, as additions of attributes and references

114 TypingandSubtypingofMetamodels

to a class is common when creating metamodel vari- differently, a metamodel can be constructed by com- ants. Such additions change the type of the contain- bining an arbitrary number of patterns. This means ing class, which in turn results in a covariant redefi- that a metamodel can also be considered from sev- nition of attributes and references that are typed with eral perspectives depending on situation and purpose the class. Let us see how this affects metamodel types (e.g. a tool may present several viewpoints to the as presented in this paper. user, where each viewpoint correspond to a meta- There are two places where subtyping occurs in model type). creating a metamodel type variant. First, the enclosing class is subtyped. Second, the inner classes con- package metamodel; require "state_machine.kmt" stituting the metamodel may be subtyped selectively require "game.kmt" depending on which specialisations that are required. class TMetamodel inherits TStateMachine, TGame ... Recall how the Transition class needs an additional at- } tribute probability to create a weighted state machine metamodel from the basic state machine metamodel. Figure 5: Using multiple inheritance to relate metamodel Let us assume that this would be the only required types (yielding a composite metamodel). addition to the basic state machine metamodel. What we have now is a situation of covariant type redefini- Regardless of specialisations of the inner classes, tion. The attributes incoming and outgoing of the State the enclosed metamodel of TMetamodel can still be class (see Figure 1) are typed with Transition. The new considered from two perspectives/aspects: state ma- Transition class variant contains an additional attribute. chines and game. That is, tools defined for TStateMa- Hence, the types of the incoming and outgoing refer- chine and TGame can still be used. For example, it is ences in the State class of the metamodel type variant convenient to analyse a model conforming to the com- (TWeightedStateMachine) are not invariant, but covari- posite metamodel from the state machine perspective ant. A potential problem would occur when related alone, e.g. by writing out the state transition table or metamodel types are mixed, e.g. when a model con- similar. This is possible regardless of the added prop- tains instances of both state machine and weighted erties in specialisations of the inner classes. state machine metamodel classes. However, these sit- Using multiple inheritance may potentially re- uations do not occur since e.g. a model editor has to quire resolution of name conflicts. There are several instantiate either of these types. Hence, it is not pos- approaches to improve the applicability of multiple sible to instantiate the subtype of the Transition class inheritance, e.g. Kermeta allows the modeller to ex- when creating a basic state machine. plicitly specify the operation to override in ambigious Attributes and references have multiplicities situations. We will not go into details on this subject. which indicate the possible amount of values/objects the properties may take. We consider attributes and 3.5 Defining Metamodel Types references to be immutable. An important ability in metamodels is to define A metamodel type can be created automatically by bi-directional relationships. Using bi-directional re- enclosing the metamodel in a class. Additional at- lationships in the nested metamodel of a metamodel tributes and operations may then be added by the type does not induce any new challenges. metamodel developer if required. An enclosing class According to (OMG, 2011), classes in MOF do may also be created implicitly by tools, e.g. if a meta- not define XMI namespaces. Nesting of classifiers model is not defined as a metamodel type. This works may thus yield name collisions. However, the idea as long as no additional elements are required in the presented in this paper utilises a constrained form of enclosing class. class nesting, where the enclosing class has a special role. We do not discuss arbitrary nesting of classes. 3.6 Using Virtual Classes and Generic Parameters 3.4 Multiple Inheritance The classes of a metamodel type can both be defined We have seen how metamodel types can be used to as virtual and utilise generic type parameters. Let us represent metamodel patterns or fragments, e.g. a return to our example. If the language for making state machine. We have also discussed how a meta- metamodels (e.g. Kermeta) supports virtual classes model can be considered and interpreted from the per- (Madsen and Mller-Pedersen, 1989), then the Transi- spective of one specific metamodel type. Seen in the tion could be defined as a virtual class and then rede- light of this, a metamodel may have several types. Put fined in TWeightedStateMachine (by extending the Tran-

115 MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

sition class). This allows code in TStateMachine to gen- the definition of a class. The mechanism allows defin- erate Transition objects with the additional property, ing new aspects that are combined with an existing given that the context in which this code is executed class definition. Aspects allow creating metamodel is an object of TWeightedStateMachine. For an in-depth variants. However, they can not be used to type a discussion on this topic, see (Berg et al., 2011). Vir- metamodel - the resulting classes are contained in a tual classes also allows existing tools like editors to regular package. instantiate redefined classes in subtypes. Model types, as described in (Steel and Jzquel, 2007) resembles the work of this paper. There are 3.7 Metamodel Customisation some differences and similarities that we will discuss. First, a model type can be seen as a type-safe set In its simplest form, an enclosing class does not of an arbitrary number of model object types. The contain other elements than the nested metamodel model type mechanism defines a conformance rela- classes. The enclosing class may also contain at- tion between model types, which allows reusing code tributes and operations. This adds a new dimension or transformations. Specifically, code for manipulat- to metamodels. Specifically, the state of a meta- ing or executing models (interpretation) can be de- model type object can be used to customise the be- fined according to a reference model type. All models havioural semantics of its encapsulated metamodel. that are typed with a model type conformant to the ref- As an example, the behavioural semantics of a meta- erence model type can be manipulated or executed by model (as defined in operations) may use different the same code. A model type is created by referring to algorithms depending on context. These algorithms classes of an arbitrary number of existing metamod- may share basic properties (attributes) whose values els. This is a powerful ability, since classes defined in can be changed with the intention of tuning the be- different packages can be ”extracted” to constitute a havioural semantics for a specific usage or context. model type. Being able to adjust these properties simultaneously A metamodel type, as discussed in this paper, al- for all the algorithms allows customising the seman- lows typing metamodels as holistic MDE structures. tics easily without changing the actual models. The We have used the notion metamodel type instead of properties with their values are in the object of the en- model type because of a significant difference be- closing class. Hence, this object’s state captures an tween the approaches. An instance of a metamodel (execution) configuration for models of a given meta- type (object of the enclosing class) represents one par- model/language. Changing such values for a meta- ticular metamodel. The object can be used to access model/language would change the meaning for all the metamodels’ classes and thereby create model ob- conformant models/programs. It would also be possi- jects. The object of the enclosing class also refer- ble to maintain several objects of the enclosing class ences one model whose semantics is e.g. intended and thereby facilitate execution profiles (serialised to to be executed at runtime. Conversely, in the work files). However, this will give rise to an additional of (Steel and Jzquel, 2007), an instance of a model level of polymorphism as different object states give type can not be used to instantiate the classes of the different execution results. model type. Instances of these classes are instead added to the model type instance. The model type instance acts as a filter where only objects of the model 4 RELATED WORK type’s classes can be added to the model type instance successfully. The similarity in this respect between There are several mechanisms that address model the approaches is that both a metamodel type instance composition and variability. Some of these are dis- and a model type instance can be used to reference a cussed in (Berg and Mller-Pedersen, 2013). Common conformant model. The capabilities of the two model to these mechanisms is their external definition from typing approaches differ. Model types are designed to the language used to define the models and/or meta- simplify reuse of code from an external perspective, models. Moreover, most mechanisms use some kind e.g. from the perspective of an interpreter or transfor- of merging techniques to combine the metamodels mation. Conversely, metamodel types allow creating which compromises the principle of encapsulation. metamodel variants. By design, metamodel types are We have used Kermeta to illustrate metamodel functional types. Reuse of code is achieved by cre- types. Kermeta features a mechanism known as static ating type variants in the form of subtypes. Model introduction. This mechanism allows specifying par- types, on the other hand, are structural. They can not tial class definitions using aspects. Several aspect def- be combined, or be related to create variations. initions are combined (or woven) at runtime to form The inability to use substitution in model typing

116 TypingandSubtypingofMetamodels

is addressed by (Guy et al., 2012). The paper dis- imise the forward-compatibility of a language since cusses four subtyping mechanisms, and how these al- this allows reusing existing tools on new models (via low defining relations between model types as defined redefined virtual operations). The subtyping relation in (Steel and Jzquel, 2007). The work differentiates ensures a high degree of forward-compatibility. Sub- between total and partial subtyping relations, that are typing also guarantees mutator forward-compatibility. either isomorphic (model type matching with respect This supports a round-trip between new instances of to properties and operations) or non-isomorphic. Ac- submodels and support of these by existing tools. cording to the definitions of (Guy et al., 2012), using That is, the submodel instances appear like super- an enclosing class as type specification for metamod- model instances. Subtyping is the most restrictive els can be seen as a total isomorphic subtyping rela- specialisation relationship, with strict behaviour con- tion that is declared explicitly. The explicitly declared formance of subtypes. We believe that this type of re- subtyping relation allows reusing structure of super- lationship is the best suited to relate metamodel types. types through inheritance. And, as we have seen, the inherited classes can be redefined. Using an enclosing class supports compile-time checking of the subtyping relations between types. It is stated in (Guy 5 CONCLUSIONS et al., 2012) that it is not possible to achieve type group substitutability using object subtyping. The The work discussed in this paper presents a novel way work on metamodel types shows that this is in fact of typing a metamodel by defining it within an enclos- possible when a metamodel is a property of an object ing class. The purpose of the enclosing class is to fa- - as realised using class nesting. Hence, we are able cilitate object-orientation at the metamodel level that to achieve type group substitutability based upon es- can be utilised by tools. Hence, we achieve a man- tablished object subtyping principles. This includes ner of defining functional types for metamodels that the ability to reuse existing type checking algorithms. can be related using subtyping. An object of the en- The drawback of our approach is that substitutability closing class is not part of a model, but used by tools of metamodels can not be defined partially. However, to manage the enclosed metamodel. Subtyping en- as illustrated, a metamodel can be typed according to sures substitutability between metamodel types. That several metamodel types, which addresses this con- is, tools defined according to a metamodel type can be cern to some extent. reused on subtype variations of this metamodel type (possible by redefinition of virtual operations). An- An approach for generic specification of meta- other important aspect of using subtyping is the abil- model’s behaviour is discussed in (de Lara and ity to maintaining conformance between models and Guerra, 2011). The approach relies on the use of their metamodels. generic concepts to define behaviour that is applica- To the best of our knowledge, there are currently ble to a family of unrelated metamodels. Concepts no metamodelling tools or environments that support allow specifying details of models’ structure by util- nesting of classes. Formalising and implementing a ising parameters. A concept can be bound to meta- complete type system with inner classes is a very models that satisfy the concept’s requirements using time-consuming endeavour. As a first iteration, we pattern matching. There is no dependency between a have therefore focused on the theoretical approach to metamodel and a concept. Hence, utilising concepts the subject. is non-intrusive. Conversely, we have seen how metamodel types are related using subtyping in two levels. In other words, we utilise a typical object-oriented typing scheme that allows defining metamodel vari- REFERENCES ants explicitly using subtyping. Specialisation relationships between models are Berg, H. and Mller-Pedersen, B. (2013). Type-safe symmet- carefully discussed in (Khne, 2010). The work for- ric composition of metamodels using templates. In malises two relations for specifying forward- and 7th International Workshop on System Analysis and Modelling (SAM ’12), LNCS vol. 7744, pp.160-178. backward-compatibility between models and applies Springer (2013). these relations to, e.g. models related using subtyp- Berg, H., Mller-Pedersen, B., and Krogdahl, S. (2011). Ad- ing. The compatibility relations are defined using a vancing generic metamodels. In SPLASH ’11 Work- definition of conformance. Forward-compatibility is shops Proceedings, pp.19-24. ACM Press (2011). achieved if instances of a submodel conform to the su- Cho, H. and Gray, J. (2011). Design patterns for metamod- permodel, and vice versa for backward-compatibility. els. In SPLASH ’11 Workshops Proceedings, pp.25- One important point discussed is the desire to max- 32. ACM Press (2011).

117 MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

de Lara, J. and Guerra, E. (2011). From types to type re- Muller, P.-A., Fleurey, F., and Jzquel, J.-M. (2005). Weav- quirements: Genericity for model-driven engineering. ing executability into object-oriented meta-languages. In Software and Systems Modeling. Springer (2011). In Model Driven Engineering Languages and Sys- EclipseFoundation, T. (2013a). Eclipse modeling frame- tems, LNCS vol. 3173, pp.264-278. Springer (2005). work (emf). OMG (2011). Omg issue 7603, received 27th of july 2004, EclipseFoundation, T. (2013b). Epsilon object language closed 27th of may 2011. (eol). OMG (2013). Meta object facility (mof) core speciﬁcation. Fabro, M. D. D., Bzivin, J., and Valduriez, P. (2006). Weav- Steel, J. and Jzquel, J.-M. (2007). On model typing. In ing models with the eclipse amw plugin. In Eclipse Software and Systems Modeling, vol. 6, no. 4, pp.401- Modeling Symposium, Eclipse Summit Europe 2006. 413. Springer (2007). 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 inheritance. 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 subtyping. 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).

118