-The application of multi-level modelling inevitably leads to the necessity to constantly evolve a model from one iteration to the next. During each of the iterations, potentially all levels are subject to change and even more levels are affected by those changes. A set of well-defined change operations is required to develop a modelling tool that supports the modeller at refining his models. In this paper we will derive all possible change operations for a reduced multi-level metamodel and provide a possible definition for their behaviour. Index Terms-Co-Evolution, Maintenance, Multi-Level Modelling, FMMLX
Multi-level modelling is an emerging field and provides
advanced modelling capabilities over traditional approaches of
conceptual modelling [
Due to this lack of guidelines, it is not straightforward to create a convincing multi-level model. Thus, a multi-level model is presumably not created by monotonically adding elements, but it usually requires several iterations with reoccurring tasks of adding, modifying and deleting model elements. Due to this omnipresence of change, it is mandatory to choose an appropriate means for creating such a model.
The use of pencil, paper and eraser probably provides the most freedom in terms of creating a multi-level model. As this means does not include mechanisms for checking the validity, multi-level models can be changed freely. However, this lack of validation also implies that it is not possible to ensure the model’s consistency automatically. Furthermore, the developed models are created as a physical sketch on paper, thus, these models cannot be interpreted or executed by a computer.
In contrast, modelling tools do allow an automatic
consistency check as well as an interpretation and execution
by a computer. However, prevalent modelling tools do not
allow conducting non-monotonic changes as freely as by using
pencil, paper and eraser. Thus, modelling tools lack freedom
because they restrict the model creation and modification
either explicitly or implicitly. Tools like MetaEdit+ [
An adequate modelling tool for multi-level modelling should restrict the modeller as little as possible while ensuring the model’s consistency. In order to develop such a modelling tool, it is necessary to identify all possible operations of change which can be performed on a multi-level model.
Due to the complexity of multi-level modelling, identifying all possible changes is a challenging endeavour by itself. Therefore, this work presents a starting point by identifying all possible changes in a reduced metamodel for multi-level modelling, denoted as minimal model. Thus, the outcome of this research does not represent a full-fledged approach for handling change in multi-level models.
The remaining parts of the paper are structured as follows: Section II discusses multi-level modelling and the relevance of change therein. Afterwards, the handling of change in traditional conceptual modelling is explored in Section III, followed by the presentation of the developed approach in Section IV. Following, the results are discussed in Section V. Eventually, the paper closes with a conclusion and an outlook for future work in Section VI.
Frank characterizes multi-level modelling by pointing out three major differences to traditional conceptual modelling:
the Rigid Instantiation/Specialization Dichotomy, 3) No Strict
As multi-level modelling allows for a Flexible Number of Classification Levels, those models are not limited to a fixed language architecture, but allow for facilitating as many classification levels as required.
Furthermore, the Rigid Instantiation/Specialization Dichotomy is relaxed. In traditional conceptual modelling, there is a strict distinction between Instantiation and Specialization, i. e., those are mutually exclusive: Two elements might be connected either by an instance-of-relation or by a specializationrelation, but never by both at the same time. In contrast, this dichotomy is relaxed in multi-level modelling, as it accounts for elements, which are both instance and specialization of another element at the same time.
Moreover, in multi-level modelling there is no Strict Separation of Language Levels. Therefore, in multi-level modelling it is possible to create associations that cross classification levels. Thus, multi-level modelling corresponds to natural technical 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. B. FMMLX and XModeler
There are different multi-level modelling languages (e.g.,
[
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
indicate that the metamodel, as well as all models instantiated
from it, are executable” [
The FMMLX allows an arbitrary number of classification
levels, whereby each level is denoted by an unique identifier
[
Furthermore, FMMLX provides deferred instantiation by
intrinsicness which is visualized by a white number on a black
background in front of an attribute [
XModeler uses a specifically designed language called XOCL (eXecutable OCL) and is based on a kernel model called XCore, on which all other features of XModeler are built on. Furthermore, XCore has been enhanced in order to support multi-level modelling with FMMLX .
The architecture of XModeler has a shared conceptualization and representation of model and source code, so that any changes in the model go into effect immediately without generating a new version of code. That means for example, that the constructor of a newly created class is immediately available and can be invoked to create instances. These instances themselves can then be referenced, for instance in the body of operations. Operations in turn can be compiled and invoked at runtime.
While the tool basically allows multi-level modelling, only a specific order of modelling is currently supported. The results from this and subsequent papers are intended to be used as specifications for implementing a multi-level modelling editor which is not limited to top-down-modelling
Following, challenges and potential solutions are illustrated,
which have to be faced by a modelling tool as XModeler.
Fig. 1 shows an example in which the concept of Device is
refined over the concept of Printer down to the specification
of specific printer types and instances of those types (cf. [
If we review this model, we discover that some mistakes were made by the designer. A minor mistake is, that pagesPrinted is of type Float, although Integer is more appropriate. If the type is changed the value does not fit anymore. This situation is not much different to a two-level system, but the change must be adapted to a multi-level environment, as the slot is two classification levels away here. To avoid inconsistencies the values have been replaced by the null value. Ideally a conversion function could be supplied here to convert from Float to Integer, so that the values would not get lost.
Furthermore, the attribute color in Printer could be regarded as wrong. This attribute indicates whether this printer is a color-printer or not and is wrongly stated as to be instantiated on level 0. Therefore, the actual printers on level 0 were all created with this slot. The attribute should better be a property applying to level 1. When the instantiation level of the attribute is changed, the slots on level 0 must be removed, and new ones have to be created on level 1. In this case, as all instances (for each class respectively) had the same slot value, that value
Printer:Device 1 color:Boolean 1 pagesPerMinute:Float 0 pagesPrinted:Integer 2 can be reused for their classes. The final state after all these changes is shown in Fig. 2
Considering the discussed example, changes in a multilevel model might be more complex than in traditional conceptual modelling: In traditional modelling, it is possible to perform several changes on a metamodel in the first step and adapting the instantiated models afterwards. However, multilevel modelling requires to adapt both aspects at the same time. If only the metamodel is adapted, the overall multi-level model becomes inconsistent, because some instances do not correspond to their classes anymore. Thus, adaption constitute one inseparable unit in the realm of multi-level modelling.
The role of changes in traditional conceptual modelling
has been discussed widely (e.g., [
Model evolution is also relevant for metamodelling. For
example, if there are changes in a specific domain of discourse,
it might imply changes in a corresponding domain specific
modelling language (DSML). Thus, it is necessary to change
the corresponding metamodel [
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
mandatory to conduct a model co-evolution after a metamodel
evolution in order to maintain a consistent language
architecture [
In the context of object oriented modelling, there are several approaches which aim at dealing with model evolution and/or model co-evolution.
Gruschko et al. classify possible changes of a metamodel
evolution into Not Breaking Changes, Breaking and
Resolvable Changes and Breaking and Unresolvable Changes [
tency, but the consistency cannot be regained automatically.
Wachsmuth develops change operations for models which
allow a stepwise meta-model evolution [
Vermolen et al. investigate the model evolution from an
expost perspective, i.e., they compare two versions of one
metamodel in order to identify the differences [
Herrmannsdoerfer et al. develop an approach which aims at
the coupled conduction of metamodel evolution and model
coevolution [
Narayanan et al. developed a language for dealing with
metamodel evolution and model co-evolution [
Similarly, Cicchetti et al. present an approach, in which the
differences due to evolution are explicated with a difference
model [
An approach for dealing with change in multi-level
modeling is presented by Atkinson et al. [
Jahn presents a further approach, where he derives a set of
change operations for a multi-level system [
Jahn’s approach uses class migration as a default method to resolve some of the inconsistencies arising. The delete Concept operation for example would leave the instances of the deleted concept orphaned. To resolve that issue, these instances now become top-level concepts where the instanceOf link is not set. Instead, we would like to avoid class migration as a default method. We might add alternative change operations in the future, which offer an advantage by using class migration, but for this paper we will focus on change operations free of class migration to avoid side effects.
Those existing approaches are used as inspiration for analysing the potential change operations in a multi-level modelling.
Following, a minimal metamodel of multi-level modelling is described step-by-step. The complete model is shown in Figure 3.
To begin with, the meta model includes Entities. These entities can serve as classes and instances at the same time as explained in section II-A. These entities have a name, a classification level and a class they were instantiated from. An entity can be instantiated from the meta-model, which requires a name and a classification level to be chosen. When instantiated, the instance requires a name as well, but the classification level will be in any case one less than its class’s classification level. If an instance has classification level zero, it cannot be instantiated further.
The metamodel also includes attributes. An instantiable entity may have a named attribute, which causes its instance to have a slot which can have a value.
In a two-level system there is no choice when to create the slot for an object from an attribute of a class. In multilevel models, there is the option to add the attribute not only in the entity directly above the level where the slot is to be created, but also in any level above. An attribute which cause slot creation only after more than one instantiation is called an intrinsic attribute. In addition to the name, an attribute now needs one more parameter, which describes when the slot will be available.
The attribute also has a type, which can be any instantiable entity. In a two-level architecture the slot must contain a direct instance of the type, as we can instantiate it only once. In a multi-level architecture we can instantiate multiple times. The exact classification level of the slot value has not been specified yet. The corresponding slot must hold a value which is an instance of the given type (or recursively an instance thereof). The null-value satisfies all types.
The meta model also allows inheritance. In this context inheritance means, that an instantiable entity has a link to one or more parents. The entity and its parents must have the same level. Attribute names must be unique within a class and all its parents recursively. Also, inheritance cycles are not allowed.
Multiple inheritance is allowed, as it does not cause additional issues here. As long as the concept of overriding – either attributes or operations – is not introduced, duplicate attributes are not an issue, as those duplicate attributes are in fact identical attributes received through different means, which materialise in only one slot for each attribute added to an entity.
The meta model also allows for a representation of primitive data types. An Entity with name Integer on level 1 without attributes can be added. Then any required integer number can be added as an Entity on level 0 where the of-link points to Integer and the value is stored in the name-property.
The following terms will be used to refer from one entity’s perspective to another entity. An entity may have a Class which it was instantiated of. The class of its class is called a Meta-Class. We expand this concept by adding an exponent to "Meta", where the exponent indicates the number of instantiation steps from the referred entity to the referring entity, which have been made beyond the classical single instantiation. That means: When a class has been instantiated once, there have been no additional instantiation steps made, the full term would be Meta0-Class, which is equivalent to Class. Also, a Meta-Class would be Meta1-Class in the full notation. Finally we add a + to the exponent when referring to all entities where are at least that number of additional instantiation steps were made. The same type of notation is used for the instances of an entity, where the term Intrinsicn-Instance indicates the number of instantiation steps done beyond the classical one. The terms Instance and Intrinsic-Instance are used to indicate zero or one step respectively. The modifier + can also be used here. These terms also include instances from subclasses unless stated otherwise.
To make sure we get a complete list of change operations, we derive them from the properties and links in the diagram in Figure 3. When describing the state of a model, we describe the state of an instance of the class Package. When we start modelling we have such an object which represents the empty model. This is the root element, of which exactly one exists.
We can now add and remove the other objects i. e., Entity, Attribute or Slot. These objects cannot exist on their own as they all are on one end of a link which requires them to be linked to something else. E.g., an Attribute must be connected to exactly one Entity. These links give us the first group of change operations. An object of the zero-to-many end of the link can be created and added to one object of the one-toone side of the link. It can also be removed and discarded. And there is a third change operation which for a given object from the zero-to-many end replaces the object on the one-toone end.
Four of these possible change operations are not used. There are no operations concerning Slot, as constraints prohibit independent changes on slots. As we only have one root element, an Entity cannot be transferred to a different root. Additionally, because the instanceOf and the level of Entity are immutable, two different operations are necessary for creating entities: One for creating a top-level-class from the metamodel and a second one for creating an instance from an existing entity.
There are two links which are many-to-one. These are
That means that every attribute refers to exactly one entity, which in turn may be referred to by any number of attributes. Therefore we only need a replace-operation which replaces the type entity in the attribute. The same holds true for the value entity in slot.
The link Entity to Entity, named instanceOf will not be considered. These links are only added or removed when an entity is added or removed.
There is one more link: Entity to Entity, named parent. 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 another target may appear necessary at a first glance. Nevertheless the many-to-many link does not demand such an operation, as adding the new link first and removing the old one does the required tasks without data loss. Fortunately the constraints do not prevent us from having the old and new link simultaneously.
There are five properties, all with a multiplicity of one. That means, they only need a change-operation. The property level in Entity is immutable and the property name in slot may not be altered on its own. For the other three, an operation is available.
addEntity(level, name): This operation adds a new toplevel-entity to the model. This new entity does not have a class it is instantiated from. It requires a name and a level. Implicitly, the instanceOf -link is set to the null-reference. The class name is required to be unique within the model. Also it must follow a given rule set, which is not yet specified, e. g., it must not contain white spaces. The level cannot be negative, as negative levels are not defined. While a level of zero might be thinkable, it is rather useless, as such an object does neither have slots or any other features. While a level of one does not make use of any multi-level features, it still serves at least one interesting purpose: This allows any two level-architecture to be a special case of a multi-level architecture. Therefore it is decided, that the level must be at least one. No slots will be created as this entity is not instantiated from anything which could have applicable attributes.
addEntity(of, name): This operation adds a new entity to the model. This new entity is instantiated from another entity, known as its class. The name property and the instanceOflink is set from the argument given. The level property is implicitly set one less than the level of the class. As the new level cannot be less than zero, the level of the class must not be less than one. The name property follows the same rules as above. Where the meta0+-classes have attributes with an instantiation level equal to this entity’s level, the entity has to have slots to be in a consistent state.
removeEntity(name): This operation removes an entity from the model if possible. It checks if the entity is not referenced anywhere but in the model’s list of entities and if it refers to nothing but its of-Entity. If that is the case, the entity is removed. If it is not possible, the entity is not removed. This operation will not attempt to remove usage of this entity on its own. It will nevertheless be useful and possible to have an aggregated operation doing so in the future.
changeEntityName(oldName, newName): This operation changes the name property. As for addEntity, the new name must follow certain rules. The entity is referred to only by links and not its name, so no other data needs to be adjusted.
addAttribute(entityName, attName, type, level): This operation creates an Attribute and links it to an Entity. As arguments the entity, a name, a type and an instantiation level are required. The instantiation level is a number which indicates the level where a corresponding slot is created and is non-negative but less than the level of the entity. The type can be any entity which can be instantiated, i. e., has a level of one or higher.
The name used here will be used for the slots as well. As no two slots in one entity may have the same name, this has implications on the attributes as well. An entity gets a slot from every attribute it finds in an entity which it is linked to through instanceOf and parent links, going only in the direction from source to target, and where the attribute’s instantiation level equals its own level. This hypothetical instance where a name clash could occur does not necessarily exist yet. We need to check for this issue here, otherwise we will have an entity which should be instantiable by merit of their level, but cannot be instantiated without violating consistency. We will use the phrase related entity to refer to two entities which have the potential to cause a name clash in entities later on, without exactly specifying their relationship here.
If those instances are already existent, then a slot has to be created for each of them. Slot creation is explained in IV-C: addEntity(of, name).
removeAttribute(entityName, attName): This operation removes an attribute from an entity. As a consequence, in all intrinsic0+-instances of the entity which are on the level specified by the attribute, the slot with the same name as the attribute is removed.
changeAttributeName(entityName, oldAttName, newAttName): This operation changes the name property of an Attribute. The new name must follow the same rules as in IV-C: addAttribute. All slots derived from this attribute must have their nameproperty adapted.
changeAttributeLevel(entityName, attName, newLevel): This operation changes the level property of an Attribute. This actually means that existing slots have to be removed in some entities, whereas in other entities slots have to be created. If we used removeAttribute and addAttribute instead, the slot values are lost. When the level is decreased, the entity where the new slot is created has its slot linked with the value of its direct metan-class’s slot. This only works on a decrease, as an entity has only one direct metan-class’s on a given level but has possibly any number of intrinsicn-instances on any given level. While not doing it here, we still have the option to add some rules on how to determine a new slot value from a set of former slot values. For the moment the new slot value for an increasing level will be the null-value.
changeAttributeType(entityName, attName, newType): This operation changes the type link of an Attribute. This is likely to violate the constraint, that a slot’s value must be an intrinsic0+-instance of the type of the attribute it was created from. Some slots may still have a conforming value, so they can remain. Other slots may have a non-conforming value, which have to be dealt with. The easiest solution is to replace them with a null-value. A future option would be an instruction how to initialize the slot values, i. e., a conversion function.
moveAttribute(oldEntityName, newEntityName, attName): This operation is aimed at moving attributes between related entities. A classic example would be moving an attribute from a class to its superclass. If we move the attribute up along inheritance or classification, we will have objects which gain a slot, if we move down, some objects will lose a slot. It is not necessary to move attributes up and down in one step, as there is no loss doing this in separate steps. For simplification it is sensible to limit this change to directly related classes, and use it repeatedly for longer distances.
changeSlotValue(entityName, value): This operation changes the target of the value-link of Slot. There is no danger of inconsistencies as long as the new value is an intrinsic0+instance the type of the attribute the slot was created from. Additionally a null-value is always considered a legal value.
addParent(childEntityName, parentEntityName): This operation adds a new parent-link between two Entities. Inconsistencies may arise from the fact, that the scope of attributes is changed. This is not limited to the attributes of the two entities involved. With a possibly larger scope, some attributes may no longer have a unique name therein. Also, this new link must not result in any loops. That means, there must be no closed loop paths through any number of parent or instanceOf links following their direction specified. The entity on the source end is referred to as subclass, the entity on the target will be to as superclass. As inheritance affects the slot creation from the attributes, both entities must be able to have attributes, i. e., they have a level of at least one. If the link can be added legally, the subclass’s intrinsic0+-instances may gain a slot.
removeParent(childEntityName, parentEntityName): This operation removes an existing parent-link between two Entities. This may affect slots in existing intrinsic0+-instances of the class at the source end. Also, those very instances may now be illegal values in other slots, as they not necessarily intrinsic0+-instances of the required type any more.
V. DISCUSSION
In the following, the contribution of this paper in terms of an approach for multi-level model evolution is discussed in detail.
To our best knowledge, only one approach [
In the fields of object oriented modelling and metamodelling, the terms model evolution and model co-evolution has been coined. While model evolution concerns the adaption of models respectively metamodels, model co-evolution describes the corresponding adaption of the dependent model instances respectively metamodel instances (i.e., models). This terminology is only partly applicable for multi-level modelling, because a multi-level model comprises several classification levels, e.g., metamodel, model and model instance. Therefore, the separation between model evolution and model coevolution is not reasonable for multi-level modelling. If a classification layer is evolved, it is mandatory to adapt the depending classification layers in order to maintain the multilevel model’s consistency.
The development of a full-fledged conception for multi-level model evolution is a challenging endeavour due to the number of modelling constructs in multi-level modelling. In order to reduce this number and therefore to reduce the possible number of change operations, a minimal model for multi-level modelling has been defined.
For identifying all possible change operations, the basic change operations “add”, “modify” and “delete” have been applied on the elements of this minimal model. As not all possible change operations are meaningful in terms of the multi-level modelling, the list is reduced by all pointless change operations.
By removing the meaningless operations, all operations are identified which are possible and meaningful in terms of the minimal model. Thus, this set is a complete set of change operations in terms of the minimal model.
Although the set of change operations is complete for the minimal model, it is not a full-fledged approach for multilevel model evolution. In order to develop a holistic multi-level model evolution approach, it is necessary to enrich the minimal model as well as the set of change operations step wise by further modelling constructs respectively further change operations.
Furthermore, the current conception of multi-level model evolution is only on a theoretic level. It is further necessary to provide a prove of concept by developing a multi-level modelling tool which supports the multi-level model evolution.
Additionally, the presented approach comprises only atomic change operations, i.e., those operations represent the minimal possible changes to a multi-level model which maintain the model’s consistency and do not lead to an information loss. It would be desirable to incorporate mechanisms for bundling atomic operations to more complex operation. For instance, the presented changes include only an operation for removing an entity; however, it might be desirable to delete an entire entity hierarchy at once.
Furthermore, the transfer of model evolution and model coevolution to multi-level modelling is just one approach for dealing with change in multi-level models. Another imaginable approach would be to omit the co-evolution, but to consider the evolved multi-level model as a new version of it. In this new version, there are only those entities present which are consistent with the new version. For example, if an entity is enhanced by an attribute, its instances are not taken over to the new version. In order to make those instances part of the new version, each instance has to be migrated individually to a consistent instance of the entity’s new version. However, this approach would require to deal with class migration in multi-level models.
In this paper, a conceptualization of change in multi-level models is developed. Due to the complexity of multi-level modelling, change has been investigated in terms of a minimal metamodel of multi-level modelling (i.e., reduced metamodel). By applying the operations “add”, “remove” and “modify” on all elements of the minimal model, all possible change operations have been identified. Due to the conceptualization of multi-level modelling, not each of those operation is meaningful. Thus, this set of operation has been reduced by meaningless operations in order to derive a complete list of all relevant change operations on multi-level models.
As those change operations are founded on a minimal model, this set is complete in terms of this minimal model but does not represent a full-fledged approach for multilevel modelling. Therefore it is necessary to enhance both the minimal model and the list of change operations stepwise by further language constructs respectively by further operations. Furthermore, this conceptualization has only been created on a theoretical level, i.e., it is necessary to develop a corresponding modelling tool, which supports the application of those changes on a multi-level model.
Another issue arises when the meta model includes
operations that contain a body. These operation bodies will
refer to named properties like attributes or other operations.
These references must be kept consistent with the meta-model.
While refactoring operation bodies in a fully typed, classical
two-level environment has been widely addressed [
Thus, future work aims at developing a full-fledged conceptualization of change in multi-level modelling. Furthermore, this conceptualization should be underpinned by a proof of concept. This should be a multi-level modelling tool which supports the application of all relevant changes on models without compromising the model’s integrity.