=Paper=
{{Paper
|id=Vol-2019/multi_5
|storemode=property
|title=Maintenance of Multi-level Models – An Analysis of Elementary Change Operations
|pdfUrl=https://ceur-ws.org/Vol-2019/multi_5.pdf
|volume=Vol-2019
|authors=Daniel Töpel,Björn Benner
|dblpUrl=https://dblp.org/rec/conf/models/TopelB17
}}
==Maintenance of Multi-level Models – An Analysis of Elementary Change Operations==
https://ceur-ws.org/Vol-2019/multi_5.pdf
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.