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-specific Modelling, Languages. Abstract: In model-driven engineering, models are considered first-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 func- tional model types. That is, model types whose defi- nition 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 (us- ing 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 tm 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 op- erations 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- tm = hTStateMachine;fStateMachine; State; cility (EMOF) (OMG, 2013) architecture comprises Transition; Eventg;fsm : StateMachine; events : a set of classes contained in one or more packages, Eventg; ftransitionTable : Stringgi · 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.