Maintenance of Multi-Level Models – An Analysis of Elementary Change Operations Daniel Töpel Björn Benner Department of Computing Information Systems and Enterprise Modeling Sheffield Hallam University University of Duisburg-Essen Sheffield, United Kingdom Essen, Germany Abstract—The application of multi-level modelling inevitably implicitly, as they allow to perform the model creation in any leads to the necessity to constantly evolve a model from one order, but some orders will lead to an inconsistent state, i.e., iteration to the next. During each of the iterations, potentially all the model has to be recreated from scratch. levels are subject to change and even more levels are affected by those changes. A set of well-defined change operations is required An adequate modelling tool for multi-level modelling to develop a modelling tool that supports the modeller at refining should restrict the modeller as little as possible while ensuring his models. In this paper we will derive all possible change the model’s consistency. In order to develop such a modelling operations for a reduced multi-level metamodel and provide a tool, it is necessary to identify all possible operations of possible definition for their behaviour. change which can be performed on a multi-level model. Index Terms—Co-Evolution, Maintenance, Multi-Level Mod- elling, FMMLX Due to the complexity of multi-level modelling, identifying all possible changes is a challenging endeavour by itself. I. I NTRODUCTION Therefore, this work presents a starting point by identifying all possible changes in a reduced metamodel for multi-level Multi-level modelling is an emerging field and provides modelling, denoted as minimal model. Thus, the outcome of advanced modelling capabilities over traditional approaches of this research does not represent a full-fledged approach for conceptual modelling [1]. Hence, there are several publications handling change in multi-level models. which investigate multi-level modelling, e.g., [1]–[4], however, The remaining parts of the paper are structured as follows: to the best of our knowledge, no guidelines exist that support Section II discusses multi-level modelling and the relevance the creation of multi-level models. of change therein. Afterwards, the handling of change in Due to this lack of guidelines, it is not straightforward to traditional conceptual modelling is explored in Section III, create a convincing multi-level model. Thus, a multi-level followed by the presentation of the developed approach in model is presumably not created by monotonically adding Section IV. Following, the results are discussed in Section V. elements, but it usually requires several iterations with reoccur- Eventually, the paper closes with a conclusion and an outlook ring tasks of adding, modifying and deleting model elements. for future work in Section VI. Due to this omnipresence of change, it is mandatory to choose an appropriate means for creating such a model. II. M ULTI -L EVEL M ODELLING AND C HANGE The use of pencil, paper and eraser probably provides the A. Multi-level Modelling most freedom in terms of creating a multi-level model. As this means does not include mechanisms for checking the validity, Frank characterizes multi-level modelling by pointing out multi-level models can be changed freely. However, this lack three major differences to traditional conceptual modelling: of validation also implies that it is not possible to ensure the 1) Flexible Number of Classification Levels, 2) Relaxing model’s consistency automatically. Furthermore, the developed the Rigid Instantiation/Specialization Dichotomy, 3) No Strict models are created as a physical sketch on paper, thus, these Separation of Language Levels [1]. models cannot be interpreted or executed by a computer. As multi-level modelling allows for a Flexible Number In contrast, modelling tools do allow an automatic con- of Classification Levels, those models are not limited to a sistency check as well as an interpretation and execution fixed language architecture, but allow for facilitating as many by a computer. However, prevalent modelling tools do not classification levels as required. allow conducting non-monotonic changes as freely as by using Furthermore, the Rigid Instantiation/Specialization Di- pencil, paper and eraser. Thus, modelling tools lack freedom chotomy is relaxed. In traditional conceptual modelling, there because they restrict the model creation and modification is a strict distinction between Instantiation and Specialization, either explicitly or implicitly. Tools like MetaEdit+ [5] or i. e., those are mutually exclusive: Two elements might be con- EMF/GMF [6] limit the model creation explicitly by enforcing nected either by an instance-of-relation or by a specialization- a user to follow a clearly defined order of tasks. Other relation, but never by both at the same time. In contrast, this Tools like the XModeler [7], [8] restrict the model creation dichotomy is relaxed in multi-level modelling, as it accounts for elements, which are both instance and specialization of C. Application for Change in Multi-level Modelling another element at the same time. Following, challenges and potential solutions are illustrated, Moreover, in multi-level modelling there is no Strict Separa- which have to be faced by a modelling tool as XModeler. tion of Language Levels. Therefore, in multi-level modelling it Fig. 1 shows an example in which the concept of Device is is possible to create associations that cross classification levels. refined over the concept of Printer down to the specification Thus, multi-level modelling corresponds to natural technical of specific printer types and instances of those types (cf. [1]). languages, which potentially requires to connect concepts on different levels of abstraction. Hence, multi-level modelling allows for overcoming the artificial borders of classifications levels created by traditional conceptual modelling. Device 3 1 listPrice:Float 0 salesPrice:Float B. FMMLX and XModeler There are different multi-level modelling languages (e.g., [9], [10]) and meta-modelling tools (e.g. [11], [12]). However, to the best of our knowledge, the combination of FMMLX [1] Printer:Device 2 Scanner:Device 2 and XModeler [7], [8] is the only configuration which supports 0 color:Boolean 1 duplex:Boolean executable multi-level modelling. 0 pagesPrinted:Float 0 pagesScanned:Integer The acronym FMMLX stands for Flexible Meta-Modeling and Execution Language; “the ‘x’ is intended both to express the flexible classification level of the metamodel and to in- dicate that the metamodel, as well as all models instantiated from it, are executable” [1]. Model300C:Printer 1 Model500B:Printer 1 The FMMLX allows an arbitrary number of classification listPrice = 299.90 listPrice = 199.90 levels, whereby each level is denoted by an unique identifier [1]. Objects are on the level M0 ; Classes are on M1 and are illustrated with a white background color. For each further level, the index is increased by 1. Metaclasses are on M2 and have a black background. Additionally, the background printerInRoom0815 printerInRoom0915 of elements on M3 is blue, on M4 red and on M5 green. :Model300C 0 :Model500B 0 Furthermore, FMMLX provides deferred instantiation by salesPrice = 249.90 salesPrice = 189.90 intrinsicness which is visualized by a white number on a black pagesPrinted = 3456.0 pagesPrinted = 5678.0 background in front of an attribute [1]. The number implies color = true color = false the instantiation level of the attribute, e.g., “1” means that an attribute is instantiated on M1 . Intrinsicness can also be applied on associations and attributes. A similar concept is potency of Figure 1: Example, before change Deep Instantiation [3]. XModeler uses a specifically designed language called If we review this model, we discover that some mistakes XOCL (eXecutable OCL) and is based on a kernel model were made by the designer. A minor mistake is, that page- called XCore, on which all other features of XModeler are sPrinted is of type Float, although Integer is more appropriate. built on. Furthermore, XCore has been enhanced in order to If the type is changed the value does not fit anymore. This support multi-level modelling with FMMLX . situation is not much different to a two-level system, but The architecture of XModeler has a shared conceptualiza- the change must be adapted to a multi-level environment, tion and representation of model and source code, so that as the slot is two classification levels away here. To avoid any changes in the model go into effect immediately without inconsistencies the values have been replaced by the null value. generating a new version of code. That means for example, Ideally a conversion function could be supplied here to convert that the constructor of a newly created class is immediately from Float to Integer, so that the values would not get lost. available and can be invoked to create instances. These in- Furthermore, the attribute color in Printer could be regarded stances themselves can then be referenced, for instance in the as wrong. This attribute indicates whether this printer is a body of operations. Operations in turn can be compiled and color-printer or not and is wrongly stated as to be instantiated invoked at runtime. on level 0. Therefore, the actual printers on level 0 were all While the tool basically allows multi-level modelling, only a created with this slot. The attribute should better be a property specific order of modelling is currently supported. The results applying to level 1. When the instantiation level of the attribute from this and subsequent papers are intended to be used as is changed, the slots on level 0 must be removed, and new ones specifications for implementing a multi-level modelling editor have to be created on level 1. In this case, as all instances (for which is not limited to top-down-modelling each class respectively) had the same slot value, that value modelling language (DSML). Thus, it is necessary to change Device 3 the corresponding metamodel [16]. The process of adapting a 1 listPrice:Float metamodel is called metamodel evolution. 0 salesPrice:Float Metamodel evolution is a special case of model evolution, because it implies a model co-evolution of the instantiated models. Model co-evolution describes the evolution of models with the intention to comply to its evolved metamodel. It is Printer:Device 2 Scanner:Device 2 mandatory to conduct a model co-evolution after a metamodel 1 color:Boolean 1 duplex:Boolean evolution in order to maintain a consistent language architec- 1 pagesPerMinute:Float 0 pagesScanned:Integer ture [19]. Or to put it differently: If only the metamodel is 0 pagesPrinted:Integer changed without adapting the instantiated models, the models do not comply to the metamodel anymore. Thus, the language architecture would get inconsistent. Model300C:Printer 1 Model500B:Printer 1 B. Existing approaches listPrice = 299.90 listPrice = 199.90 In the context of object oriented modelling, there are several color = true color = false approaches which aim at dealing with model evolution and/or pagesPerMinute = 300.0 pagesPerMinute = 500.0 model co-evolution. Gruschko et al. classify possible changes of a metamodel evolution into Not Breaking Changes, Breaking and Resolv- able Changes and Breaking and Unresolvable Changes [24]. printerInRoom0815 printerInRoom0915 :Model300C 0 :Model500B 0 Not Breaking Changes occur in the metamodel, but do not make the instantiated models inconsistent. Breaking and Re- salesPrice = 249.90 salesPrice = 189.90 solvable Changes do make instantiated models inconsistent, pagesPrinted = 3456 pagesPrinted = 5678 however, the consistency can be regained automatically. Lastly, Breaking and Unresolvable Changes do also break the consis- tency, but the consistency cannot be regained automatically. Figure 2: Example, after change Wachsmuth develops change operations for models which allow a stepwise meta-model evolution [16]. Thereby, Wachsmuth distinguishes between three adaptation groups: can be reused for their classes. The final state after all these refactoring, construction and destruction. Furthermore, the changes is shown in Fig. 2 model co-evolution is also considered in this approach by Considering the discussed example, changes in a multi- corresponding adaption mechanisms. level model might be more complex than in traditional con- Vermolen et al. investigate the model evolution from an ex- ceptual modelling: In traditional modelling, it is possible to post perspective, i.e., they compare two versions of one meta- perform several changes on a metamodel in the first step and model in order to identify the differences [17]. Based on these adapting the instantiated models afterwards. However, multi- differences, the required change operations are derived. The level modelling requires to adapt both aspects at the same required change operations are a composition of previously time. If only the metamodel is adapted, the overall multi-level identified basics change operations, which are derived from model becomes inconsistent, because some instances do not model refactoring mechanisms. correspond to their classes anymore. Thus, adaption constitute Herrmannsdoerfer et al. develop an approach which aims at one inseparable unit in the realm of multi-level modelling. the coupled conduction of metamodel evolution and model co- evolution [15]. Therefore, they developed a library of coupled III. T RADITIONAL C ONCEPTUAL M ODELLING AND operations, which describes a set of operations for metamodel C HANGE evolution and their implied operations for model co-evolution [14]. A. Model Evolution and Co-Evolution Narayanan et al. developed a language for dealing with The role of changes in traditional conceptual modelling metamodel evolution and model co-evolution [25]. With this has been discussed widely (e.g., [13]–[20]). In that context, language, the conducted metamodel evolution is explicated the process of adapting a model has been coined as “Model by defining mapping-relation between elements in the pre- Evolution” or “Model Adaption” [13]. Exemplary areas of evolutionary metamodel and the post-evolutionary metamodel. application for model evolution are database management Based on this, an automated model co-evolution can be systems [21] or Model-driven Engineering [20], [22], [23]. performed. Model evolution is also relevant for metamodelling. For Similarly, Cicchetti et al. present an approach, in which the example, if there are changes in a specific domain of discourse, differences due to evolution are explicated with a difference it might imply changes in a corresponding domain specific model [22], [23]. A difference model contains all differences between two stages of a metamodel evolution. Similar to the In a two-level system there is no choice when to create approach of Narayanan et al., a difference model allows for an the slot for an object from an attribute of a class. In multi- automatic model co-evolution. level models, there is the option to add the attribute not only An approach for dealing with change in multi-level model- in the entity directly above the level where the slot is to be ing is presented by Atkinson et al. [26]. In their publication, an created, but also in any level above. An attribute which cause “Emendation Service Architecture” [26, p. 202] is suggested slot creation only after more than one instantiation is called that is responsible for handling occurring changes. In an an intrinsic attribute. In addition to the name, an attribute now subsequent example, this architecture is discussed in terms needs one more parameter, which describes when the slot will of four change operations: add, remove, change and move be available. an attribute. Although some operations are missing (e.g., The attribute also has a type, which can be any instantiable changing a parent), the publication presents a first approach entity. In a two-level architecture the slot must contain a direct for dealing with change in multi-level modelling. instance of the type, as we can instantiate it only once. In Jahn presents a further approach, where he derives a set of a multi-level architecture we can instantiate multiple times. change operations for a multi-level system [27]. He claims to The exact classification level of the slot value has not been have a complete set of change operations, induced by having specified yet. The corresponding slot must hold a value which a change operation for each property of each element of his is an instance of the given type (or recursively an instance meta-model and a deleting operation for each element of his thereof). The null-value satisfies all types. meta-model. Operations, which are adding elements, are inten- The meta model also allows inheritance. In this context tionally omitted as not causing inconsistencies. Additionally inheritance means, that an instantiable entity has a link to one there are some moving operations which are necessary for or more parents. The entity and its parents must have the completeness, but not covered by the argument above. Also, same level. Attribute names must be unique within a class we think the adding operations should not be treated as trivial, and all its parents recursively. Also, inheritance cycles are not as for instance the operation adding an attribute would leave allowed. some existing instances in an inconsistent state. Jahn’s approach uses class migration as a default method to Multiple inheritance is allowed, as it does not cause ad- resolve some of the inconsistencies arising. The delete Concept ditional issues here. As long as the concept of overriding – operation for example would leave the instances of the deleted either attributes or operations – is not introduced, duplicate concept orphaned. To resolve that issue, these instances now attributes are not an issue, as those duplicate attributes are become top-level concepts where the instanceOf link is not set. in fact identical attributes received through different means, Instead, we would like to avoid class migration as a default which materialise in only one slot for each attribute added to method. We might add alternative change operations in the an entity. future, which offer an advantage by using class migration, but The meta model also allows for a representation of primitive for this paper we will focus on change operations free of class data types. An Entity with name Integer on level 1 without migration to avoid side effects. attributes can be added. Then any required integer number Those existing approaches are used as inspiration for can be added as an Entity on level 0 where the of-link points analysing the potential change operations in a multi-level to Integer and the value is stored in the name-property. modelling. The following terms will be used to refer from one entity’s perspective to another entity. An entity may have a Class IV. E VOLUTION IN M ULTI - LEVEL M ODELS which it was instantiated of. The class of its class is called a A. Minimal Model Meta-Class. We expand this concept by adding an exponent to Following, a minimal metamodel of multi-level modelling "Meta", where the exponent indicates the number of instantia- is described step-by-step. The complete model is shown in tion steps from the referred entity to the referring entity, which Figure 3. have been made beyond the classical single instantiation. That To begin with, the meta model includes Entities. These means: When a class has been instantiated once, there have entities can serve as classes and instances at the same time been no additional instantiation steps made, the full term as explained in section II-A. These entities have a name, a would be Meta0 -Class, which is equivalent to Class. Also, a classification level and a class they were instantiated from. Meta-Class would be Meta1 -Class in the full notation. Finally An entity can be instantiated from the meta-model, which we add a + to the exponent when referring to all entities where requires a name and a classification level to be chosen. When are at least that number of additional instantiation steps were instantiated, the instance requires a name as well, but the made. The same type of notation is used for the instances classification level will be in any case one less than its class’s of an entity, where the term Intrinsicn -Instance indicates classification level. If an instance has classification level zero, the number of instantiation steps done beyond the classical it cannot be instantiated further. one. The terms Instance and Intrinsic-Instance are used to The metamodel also includes attributes. An instantiable indicate zero or one step respectively. The modifier + can entity may have a named attribute, which causes its instance also be used here. These terms also include instances from to have a slot which can have a value. subclasses unless stated otherwise. Figure 3: Minimal Metamodel for Multi-level Modelling B. Finding the Evolutionary Steps This is a many-to-many link, so we only need an add- and a remove-operation. An operation for moving a parent link To make sure we get a complete list of change operations, to another target may appear necessary at a first glance. we derive them from the properties and links in the diagram in Nevertheless the many-to-many link does not demand such Figure 3. When describing the state of a model, we describe an operation, as adding the new link first and removing the the state of an instance of the class Package. When we start old one does the required tasks without data loss. Fortunately modelling we have such an object which represents the empty the constraints do not prevent us from having the old and new model. This is the root element, of which exactly one exists. link simultaneously. We can now add and remove the other objects i. e., Entity, There are five properties, all with a multiplicity of one. That Attribute or Slot. These objects cannot exist on their own as means, they only need a change-operation. The property level they all are on one end of a link which requires them to be in Entity is immutable and the property name in slot may not linked to something else. E.g., an Attribute must be connected be altered on its own. For the other three, an operation is to exactly one Entity. These links give us the first group of available. change operations. An object of the zero-to-many end of the link can be created and added to one object of the one-to- C. Change Operations one side of the link. It can also be removed and discarded. addEntity(level, name): This operation adds a new top- And there is a third change operation which for a given object level-entity to the model. This new entity does not have a from the zero-to-many end replaces the object on the one-to- class it is instantiated from. It requires a name and a level. one end. Implicitly, the instanceOf -link is set to the null-reference. The Four of these possible change operations are not used. class name is required to be unique within the model. Also it There are no operations concerning Slot, as constraints prohibit must follow a given rule set, which is not yet specified, e. g., independent changes on slots. As we only have one root it must not contain white spaces. The level cannot be negative, element, an Entity cannot be transferred to a different root. as negative levels are not defined. While a level of zero might Additionally, because the instanceOf and the level of Entity are be thinkable, it is rather useless, as such an object does neither immutable, two different operations are necessary for creating have slots or any other features. While a level of one does not entities: One for creating a top-level-class from the meta- make use of any multi-level features, it still serves at least one model and a second one for creating an instance from an interesting purpose: This allows any two level-architecture to existing entity. be a special case of a multi-level architecture. Therefore it is There are two links which are many-to-one. These are decided, that the level must be at least one. No slots will be Attribute to Entity, named type and Slot to Entity, named Value. created as this entity is not instantiated from anything which That means that every attribute refers to exactly one entity, could have applicable attributes. which in turn may be referred to by any number of attributes. addEntity(of, name): This operation adds a new entity to Therefore we only need a replace-operation which replaces the model. This new entity is instantiated from another entity, the type entity in the attribute. The same holds true for the known as its class. The name property and the instanceOf- value entity in slot. link is set from the argument given. The level property is The link Entity to Entity, named instanceOf will not be implicitly set one less than the level of the class. As the new considered. These links are only added or removed when an level cannot be less than zero, the level of the class must not entity is added or removed. be less than one. The name property follows the same rules There is one more link: Entity to Entity, named parent. as above. Where the meta0+ -classes have attributes with an instantiation level equal to this entity’s level, the entity has to new slot is created has its slot linked with the value of its have slots to be in a consistent state. direct metan -class’s slot. This only works on a decrease, as an removeEntity(name): This operation removes an entity entity has only one direct metan -class’s on a given level but from the model if possible. It checks if the entity is not has possibly any number of intrinsicn -instances on any given referenced anywhere but in the model’s list of entities and if it level. While not doing it here, we still have the option to add refers to nothing but its of-Entity. If that is the case, the entity some rules on how to determine a new slot value from a set is removed. If it is not possible, the entity is not removed. of former slot values. For the moment the new slot value for This operation will not attempt to remove usage of this entity an increasing level will be the null-value. on its own. It will nevertheless be useful and possible to have an aggregated operation doing so in the future. changeAttributeType(entityName, attName, newType): changeEntityName(oldName, newName): This operation This operation changes the type link of an Attribute. This is changes the name property. As for addEntity, the new name likely to violate the constraint, that a slot’s value must be an must follow certain rules. The entity is referred to only by intrinsic0+ -instance of the type of the attribute it was created links and not its name, so no other data needs to be adjusted. from. Some slots may still have a conforming value, so they addAttribute(entityName, attName, type, level): This can remain. Other slots may have a non-conforming value, operation creates an Attribute and links it to an Entity. As which have to be dealt with. The easiest solution is to replace arguments the entity, a name, a type and an instantiation them with a null-value. A future option would be an instruction level are required. The instantiation level is a number which how to initialize the slot values, i. e., a conversion function. indicates the level where a corresponding slot is created and moveAttribute(oldEntityName, newEntityName, is non-negative but less than the level of the entity. The type attName): This operation is aimed at moving attributes can be any entity which can be instantiated, i. e., has a level between related entities. A classic example would be moving of one or higher. an attribute from a class to its superclass. If we move the The name used here will be used for the slots as well. As attribute up along inheritance or classification, we will have no two slots in one entity may have the same name, this has objects which gain a slot, if we move down, some objects implications on the attributes as well. An entity gets a slot from will lose a slot. It is not necessary to move attributes up and every attribute it finds in an entity which it is linked to through down in one step, as there is no loss doing this in separate instanceOf and parent links, going only in the direction from steps. For simplification it is sensible to limit this change source to target, and where the attribute’s instantiation level to directly related classes, and use it repeatedly for longer equals its own level. This hypothetical instance where a name distances. clash could occur does not necessarily exist yet. We need to check for this issue here, otherwise we will have an entity changeSlotValue(entityName, value): This operation which should be instantiable by merit of their level, but cannot changes the target of the value-link of Slot. There is no danger be instantiated without violating consistency. We will use the of inconsistencies as long as the new value is an intrinsic0+ - phrase related entity to refer to two entities which have the instance the type of the attribute the slot was created from. potential to cause a name clash in entities later on, without Additionally a null-value is always considered a legal value. exactly specifying their relationship here. addParent(childEntityName, parentEntityName): This If those instances are already existent, then a slot has to operation adds a new parent-link between two Entities. Incon- be created for each of them. Slot creation is explained in sistencies may arise from the fact, that the scope of attributes is IV-C: addEntity(of, name). changed. This is not limited to the attributes of the two entities removeAttribute(entityName, attName): This operation involved. With a possibly larger scope, some attributes may no removes an attribute from an entity. As a consequence, in longer have a unique name therein. Also, this new link must all intrinsic0+ -instances of the entity which are on the level not result in any loops. That means, there must be no closed specified by the attribute, the slot with the same name as the loop paths through any number of parent or instanceOf links attribute is removed. following their direction specified. The entity on the source changeAttributeName(entityName, oldAttName, newAt- end is referred to as subclass, the entity on the target will be tName): to as superclass. As inheritance affects the slot creation from This operation changes the name property of an Attribute. The the attributes, both entities must be able to have attributes, new name must follow the same rules as in IV-C: addAttribute. i. e., they have a level of at least one. If the link can be added All slots derived from this attribute must have their name- legally, the subclass’s intrinsic0+ -instances may gain a slot. property adapted. changeAttributeLevel(entityName, attName, newLevel): removeParent(childEntityName, parentEntityName): This operation changes the level property of an Attribute. This This operation removes an existing parent-link between two actually means that existing slots have to be removed in some Entities. This may affect slots in existing intrinsic0+ -instances entities, whereas in other entities slots have to be created. If we of the class at the source end. Also, those very instances may used removeAttribute and addAttribute instead, the slot values now be illegal values in other slots, as they not necessarily are lost. When the level is decreased, the entity where the intrinsic0+ -instances of the required type any more. V. D ISCUSSION Furthermore, the current conception of multi-level model evolution is only on a theoretic level. It is further necessary In the following, the contribution of this paper in terms of to provide a prove of concept by developing a multi-level an approach for multi-level model evolution is discussed in modelling tool which supports the multi-level model evolution. detail. Additionally, the presented approach comprises only atomic To our best knowledge, only one approach [27] for multi- change operations, i.e., those operations represent the minimal level model evolution has been conducted so far. That ap- possible changes to a multi-level model which maintain the proach is a good inspiration, but not sufficient for our demand. model’s consistency and do not lead to an information loss. Therefore, a corresponding approach is proposed in this paper. It would be desirable to incorporate mechanisms for bundling For supporting the development of a well-founded approach, atomic operations to more complex operation. For instance, the work from adjacent fields – namely object oriented mod- the presented changes include only an operation for removing elling and metamodelling – has been utilized. Due to the wider an entity; however, it might be desirable to delete an entire subject of multi-level modelling, the approaches for evolution entity hierarchy at once. in object oriented modelling and metamodelling are not suit- Furthermore, the transfer of model evolution and model co- able for being used in multi-level modelling. However, due to evolution to multi-level modelling is just one approach for similarities (e.g., instantiation relations between entities, the dealing with change in multi-level models. Another imaginable characterization of entities with attributes, etc.), the approaches approach would be to omit the co-evolution, but to consider can be used as a starting point respectively an inspiration for the evolved multi-level model as a new version of it. In this developing a suitable approach. new version, there are only those entities present which are In the fields of object oriented modelling and metamod- consistent with the new version. For example, if an entity is elling, the terms model evolution and model co-evolution has enhanced by an attribute, its instances are not taken over to been coined. While model evolution concerns the adaption of the new version. In order to make those instances part of the models respectively metamodels, model co-evolution describes new version, each instance has to be migrated individually to the corresponding adaption of the dependent model instances a consistent instance of the entity’s new version. However, respectively metamodel instances (i.e., models). This termi- this approach would require to deal with class migration in nology is only partly applicable for multi-level modelling, multi-level models. because a multi-level model comprises several classification levels, e.g., metamodel, model and model instance. There- VI. C ONCLUSION / F UTURE W ORK fore, the separation between model evolution and model co- In this paper, a conceptualization of change in multi-level evolution is not reasonable for multi-level modelling. If a models is developed. Due to the complexity of multi-level classification layer is evolved, it is mandatory to adapt the modelling, change has been investigated in terms of a minimal depending classification layers in order to maintain the multi- metamodel of multi-level modelling (i.e., reduced metamodel). level model’s consistency. By applying the operations “add”, “remove” and “modify” The development of a full-fledged conception for multi-level on all elements of the minimal model, all possible change model evolution is a challenging endeavour due to the number operations have been identified. Due to the conceptualiza- of modelling constructs in multi-level modelling. In order tion of multi-level modelling, not each of those operation is to reduce this number and therefore to reduce the possible meaningful. Thus, this set of operation has been reduced by number of change operations, a minimal model for multi-level meaningless operations in order to derive a complete list of modelling has been defined. all relevant change operations on multi-level models. For identifying all possible change operations, the basic As those change operations are founded on a minimal change operations “add”, “modify” and “delete” have been model, this set is complete in terms of this minimal model applied on the elements of this minimal model. As not all but does not represent a full-fledged approach for multi- possible change operations are meaningful in terms of the level modelling. Therefore it is necessary to enhance both the multi-level modelling, the list is reduced by all pointless minimal model and the list of change operations stepwise by change operations. further language constructs respectively by further operations. By removing the meaningless operations, all operations are Furthermore, this conceptualization has only been created on a identified which are possible and meaningful in terms of the theoretical level, i.e., it is necessary to develop a correspond- minimal model. Thus, this set is a complete set of change ing modelling tool, which supports the application of those operations in terms of the minimal model. changes on a multi-level model. Although the set of change operations is complete for the Another issue arises when the meta model includes op- minimal model, it is not a full-fledged approach for multi- erations that contain a body. These operation bodies will level model evolution. In order to develop a holistic multi-level refer to named properties like attributes or other operations. model evolution approach, it is necessary to enrich the minimal These references must be kept consistent with the meta-model. model as well as the set of change operations step wise While refactoring operation bodies in a fully typed, classical by further modelling constructs respectively further change two-level environment has been widely addressed [28], it is operations. necessary to adapt those approaches to multi-level modelling. Thus, future work aims at developing a full-fledged concep- [24] B. Gruschko, D. Kolovos, and R. Paige, “Towards synchronizing models tualization of change in multi-level modelling. Furthermore, with evolving metamodels,” in Proceedings of the International Work- shop on Model-Driven Software Evolution. IEEE, 2007. this conceptualization should be underpinned by a proof of [25] A. Narayanan, T. Levendovszky, D. Balasubramanian, and G. Karsai, concept. This should be a multi-level modelling tool which “Automatic Domain Model Migration to Manage Metamodel Evolution,” supports the application of all relevant changes on models in Model Driven Engineering Languages and Systems, 2009, pp. 706– 711. without compromising the model’s integrity. [26] C. Atkinson, R. Gerbig, and B. Kennel, “On-the-fly emendation of multi- level models,” Modelling Foundations and Applications, pp. 194–209, R EFERENCES 2012. [1] U. Frank, “Multilevel modeling: Toward a new paradigm of conceptual [27] M. Jahn, “Evolution von meta-modellen mit sprachbasierten mustern,” modeling and information systems design,” Business and Information Ph.D. dissertation, Bayreuth, 2014. Systems Engineering, pp. 319–337, 2014. [28] E. Murphy-Hill, C. Parnin, and A. P. Black, “How we refactor, and how [2] T. Clark, C. Gonzalez-Perez, and B. Henderson-Sellers, “A foundation we know it,” IEEE Transactions on Software Engineering, pp. 5–18, for multi-level modelling,” in MULTI@ MoDELS, 2014, pp. 43–52. 2012. [3] C. Atkinson and T. Kühne, “In defence of deep modelling,” Inf. Softw. Technol., vol. 64, no. C, pp. 36–51, Aug. 2015. [4] V. A. Carvalho and J. P. A. Almeida, “Toward a well-founded theory for multi-level conceptual modeling,” Software & Systems Modeling, pp. 1–27, 2016. [5] MetaCase, “MetaEdit+,” http://www.metacase.com/products.html, 2017. [6] The Eclipse Foundation, “Graphical Modeling Framework,” https:// www.eclipse.org/modeling/gmp/, 2017. [7] T. Clark, P. Sammut, and J. Willans, Superlanguages: Developing Languages and Applications with XMF. Ceteva, 2008. [8] ——, Applied Metamodelling A Foundation For Language Driven Development: Second Edition. Ceteva, 2008. [9] C. Atkinson, M. Gutheil, and B. Kennel, “A flexible infrastructure for multilevel language engineering.” IEEE Trans. Software Eng., vol. 35, no. 6, pp. 742–755, 2009. [10] B. Neumayr, K. Grün, and M. Schrefl, “Multi-level domain modeling with m-objects and m-relationships,” in Proceedings of the Sixth Asia- Pacific Conference on Conceptual Modeling - Volume 96, ser. APCCM ’09. Darlinghurst, Australia, Australia: Australian Computer Society, Inc., 2009, pp. 107–116. [11] C. Atkinson and R. Gerbig, “Flexible deep modeling with melanee,” in Modellierung 2016, 2.-4. März 2016, Karlsruhe - Workshopband, ser. Modellierung 2016, S. B. U. Reimer, Ed., vol. 255. Bonn: Gesellschaft für Informatik, 2016, pp. 117–122. [12] J. de Lara and E. Guerra, Deep Meta-modelling with MetaDepth. Berlin, Heidelberg: Springer Berlin Heidelberg, 2010, pp. 1–20. [13] J.-M. Favre, “Meta-model and model co-evolution within the 3D soft- ware space,” in ELISA: Workshop on Evolution of Large-Scale Industrial Software Applications, 2003, pp. 98–109. [14] M. Herrmannsdoerfer, S. Benz, and E. Juergens, “Cope - automating coupled evolution of metamodels and models,” in Proceedings of the 23rd European Conference on ECOOP 2009, 2009, pp. 52–76. [15] M. Herrmannsdoerfer, S. D. Vermolen, and G. Wachsmuth, “An Exten- sive Catalog of Operators for the Coupled Evolution of Metamodels and Models,” in Software Language Engineering, 2010, pp. 163–182. [16] G. Wachsmuth, “Metamodel adaptation and model co-adaptation,” in European Conference on Object-Oriented Programming, 2007, pp. 600– 624. [17] S. D. Vermolen, G. Wachsmuth, and E. Visser, “Reconstructing complex metamodel evolution,” in International Conference on Software Lan- guage Engineering, 2011, pp. 201–221. [18] D. E. Khelladi, R. Hebig, R. Bendraou, J. Robin, and M.-P. Gervais, “De- tecting Complex Changes During Metamodel Evolution,” in Advanced Information Systems Engineering. Springer, Cham, 2015, pp. 263–278. [19] A. Demuth, M. Riedl-Ehrenleitner, R. E. Lopez-Herrejon, and A. Egyed, “Co-evolution of metamodels and models through consistent change propagation,” Journal of Systems and Software, pp. 281–297, 2016. [20] L. Iovino, A. Pierantonio, and I. Malavolta, “On the Impact Significance of Metamodel Evolution in MDE.” Journal of Object Technology, 2012. [21] F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec, “Schema and database evolution in the o2 object database system,” in Proceedings of the 21th International Conference on Very Large Data Bases, ser. VLDB ’95, 1995, pp. 170–181. [22] A. Cicchetti, D. Di Ruscio, R. Eramo, and A. Pierantonio, “Automating co-evolution in model-driven engineering,” in Enterprise Distributed Object Computing Conference, 2008, pp. 222–231. [23] ——, “Meta-model differences for supporting model co-evolution,” in Proceedings of the 2nd Workshop on Model-Driven Software Evolution- MODSE, 2008, pp. 1–10.