Co-Evolution of Metamodels and Model Transformations E-Book

Steffen Kruse

• Herausgeber: Books on Demand
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 277

Veröffentlichungsjahr: 2015

Beschreibung

Complexity is an essential property of software systems that increases in a non-linear fashion with the size of the software system. In software engineering, Model Driven Engineering (MDE) aims to alleviate this complexity by utilising models and modelling activities to raise the level of abstraction and to automate the production of artefacts. One specialised technique with this purpose is the model transformation, which allows the automated creation and modification of output models based on input models. As models and model transformations are used in a productive capacity, they underlie the same evolutionary pressure that conventionally build software systems do. Here the tight coupling between model transformations and metamodels becomes problematic, as changing the one often results in the need to check and adapt the other accordingly. This thesis presents an operator-based, stepwise approach to support software architects in the co-evolution of metamodels and model transformations. The approach allows the description of changes done to a metamodel and the automatic or semi-automatic resolution of the impact on related model transformations. Overall the effort needed for co-evolution is reduced.

Leseprobe

Abstract

With the continual increase in size and complexity of modern software systems, the evolution of software remains one of the big challenges of software engineering. Model Driven Engineering (MDE) is one approach to meet this challenge – by breaking down the description of software systems under development into manageable abstractions, each embodied by a suitable kind of artefact. Kinds of artefacts are models and metamodels, along with model transformations, (modelling) languages, generators and others. Yet the benefits expected from MDE can only be fully realised when the complexity of the MDE artefacts and their relationships remain manageable themselves.

The challenge addressed in this context by this thesis is the co-evolution of metamodels and model transformations; expressed as transformation descriptions in common, dedicated transformation languages. Transformations are used to produce output models conforming to a metamodel based on input models conforming to another (or the same) metamodel and are expressed in terms of the metamodels used. This enforces a tight coupling between metamodels and transformation descriptions. In consequence, any change made to one or more metamodel potentially invalidates existing transformations so that every change requires the validation and adaptation of all dependent transformations. This can lead to an exceeding amount of effort necessary to keep metamodels and transformations consistent as the number of transformations and metamodels increase.

This work presents an operator-based, stepwise approach to support software architects in the co-evolution of metamodels and transformations. To this end we propose a set of operators which, when applied to metamodels, perform an evolution step on the metamodel. The impacts of such a change in the form of an operator applied to a metamodel can be predicted for transformations that depend on the metamodel. The approach further allows the resolution of the impacts to restore consistency, either automatically or with minimal human input – depending on the type of change and the kind and complexity of the transformation. In the worst case, the use of operators at least indicates potentially invalid transformation parts that need further validation to fulfil their original intended purpose. Overall the approach reduces the effort needed for co-evolution.

The approach is implemented and integrated into MDE tooling commonly used for modelling and transformation creation to demonstrate its feasibility. The operators are formalised on the basis of the Essential MOF (EMOF) and the impact resolution is provided for the ATLAS Transformation Language (ATL).

Contents

Abstract

1. Introduction

1.1. Motivation

1.2. Application Scenario

1.3. Contribution

1.4. Outline

I Foundations

2. Model Driven Engineering

2.1. Model

2.2. Metamodel

2.3. The Meta Object Facility (MOF)

2.4. The Eclipse Modeling Framework (EMF) / Ecore

2.5. Model Transformations

3. Model Transformation Languages

3.1. Model Transformation Language Features

3.2. The ATLAS Transformation Language (ATL)

3.3. MOF Query/View/Transformation (QVT)

3.4. The Object Constraint Language (OCL)

4. Software Evolution and MDE

4.1. MDE and the Evolution of MDS

4.2. Model Refactoring

II Operator-based Co-Evolution of Metamodels and Model Transformations

5. Supporting the Evolution of Model Driven Systems: A Stepwise Approach

5.1. Problem Description

5.2. Goal: Providing Support for Co-Evolution

5.3. Requirements

5.4. Approach

5.5. Phase 1: Metamodel Adaptation

5.6. Phase 2: Operator Impact Detection

5.7. Phase 3: Impact Resolution

5.8. The Overall Co-Evolution Process

6. Operators for EMOF Metamodel Evolution

6.1. On the Usage of the QVT-R Graphical Notation for Operator Definition

6.2. Operator Overview

6.3. Add / Remove Element

6.4. Move Property

6.5. Push Simple Property

6.6. Push Complex Property

6.7. Pull Simple Property

6.8. Pull Complex Property

6.9. Restrict (Unidirectional) Property

6.10. Generalise (Unidirectional) Property

6.11. Extract Class

6.12. Inline Class

6.13. Extract Superclass

6.14. Flatten Hierarchy

6.15. Association to Class

6.16. Generalization to Composition

6.17. Introduce Composite Pattern

7. Impact Resolution for ATL

7.1. Operator Impact Overview

7.2. Support Functions and Omissions

7.3. Add Element

7.4. Remove Element

7.5. Rename NamedElement

7.6. Move Property

7.7. Push Simple Property

7.8. Push Complex Property

7.9. Pull Simple Property

7.10. Pull Complex Property

7.11. Restrict (Unidirectional) Property

7.12. Generalise (Unidirectional) Property

7.13. Extract Class

7.14. Inline Class

7.15. Extract Superclass

7.16. Flatten Hierarchy

7.17. Association to Class

7.18. Generalization to Composition

7.19. Introduce Composite Pattern

8. Related Work

8.1. Co-Evolution of Metamodels and Models

8.2. Co-Evolution of Models and OCL Constraints

8.3. Co-Evolution of of Metamodels and Transformations

8.4. Comparison

III Validation and Conclusion

9. Evaluation

9.1. Completeness

9.2. Petri Net Evolution Scenario

9.3. Summary

10. Proof of Concept Prototype

10.1. Overview

10.2. Preliminary Considerations

10.3. ATL Concrete and Abstract Syntax Implementation

10.4. Graphical Model Editor

10.5. Operator Implementation

10.6. Impact Detection and Resolution

11. Conclusion

11.1. Summary

11.2. Benefits

11.3. Future Work

Appendix

A. Execution of Extract Superclass

B. ATL Implementation in Xtext

Glossary

Acronyms

List of Figures

List of Listings

Index

Bibliography

CHAPTER 1

Introduction

Complexity is an essential property of software systems that increases in a non-linear fashion with the size of the software system [16]. Model Driven Engineering (MDE) is a software engineering approach that aims to alleviate this complexity in software development and maintenance by utilising models and modelling activities to raise the level of abstraction and to automate the production of artefacts. One specialised approach with this purpose is the model transformation, which allows the automated creation and modification of output models based on input models. Model transformations can be expressed in specialised transformation languages to be executed by a transformation engine. As models and model transformations are used in a productive capacity in software engineering, they underlie the same evolutionary pressure that conventionally build software systems do. Here the tight coupling between model transformations and metamodels becomes problematic, as changing the one often results in the need to check and adapt the other accordingly.

This thesis presents an approach to lessen this co-evolution problem by providing a systematic method to software architects of describing changes done to a metamodel and determining and resolving the impact on related model transformations.

The remainder of this chapter motivates this approach. Section 1.1 describes the co-evolution problem for metamodels and model transformations in more detail and Section 1.2 provides a simple illustration as an application scenario. Section 1.3 lists the proposed scientific contributions of this work. An outline of this thesis is provided in Section 1.4.

1.1. Motivation

During the MoDELS’08 conference a workshop was held to identify ‘Challenges in Model-Driven Software Engineering’ and to propose the ways in which to best address these challenges in the next 10 or more years. Two of the challenges brought forward by the participants were the lack of proper process support for model driven engineering activities and specifically the lack of support for model evolution and inconsistency management in large, multi-user and distributed development settings. [105]

The participants argued that models can become inconsistent where dependencies between them exist, especially if the models are developed in a distributed fashion. As a first step to a solution, the need to identify the change types possible and the possible ways to resolve their impact on dependencies were identified. Furthermore, rapid prototyping for domain-specific modelling languages would be needed, as rapid prototyping provides the advantage of ‘continuous, incremental feedback’ for development in MDE. Yet rapid prototyping can only be achieved if handling the dependencies between modelling artefacts can be done as rapidly as evolving the prototype. The focus here was mainly on the relationship between models and metamodels, but the argument is also valid for model transformations that depend on the metamodels they are build on. [105]

In 2011, Hans Vangheluwe identified the evolution of development artefacts used in MDE, specifically models and modelling languages as a major challenge for the community, as the evolution of models has repercussions on all related artefacts, amongst them model transformations. He suggest for MDE and the related Domain Specific Modelling (DSM):

‘If MDE and DSM are to be usable at an industrial scale, modeling language evolution has to be dealt with, ideally by (semi-) automatically co-evolving artifacts.’ [106]

Figure 1.1.: The impact on metamodel evolution on dependent artefacts

Co-evolution is the model engineering task of changing dependent artefacts together to maintain consistency [22]. What constitutes consistency depends on the artefacts involved, for metamodels and models it is given in part by the conformance of the models to their metamodels. For metamodels and transformations, it is for one the suitability of the metamodel to represent the input and output models of the model transformation. But the expected function of the transformation also needs to be taken into account; an evolutionary change can introduce inconsistencies that cause a transformation to produce the wrong output, although it is still executable.

Figure 1.1 illustrates the problem of metamodel evolution and the impact it has on the artefacts involved in a transformation. It contains a transformation T, which is specified by a transformation model which can be expressed in a transformation language like ATL. The transformation model refers to two metamodels A and B, where A serves as the source or left-hand-side (LHS) and B as the target, or right-hand-side (RHS) in this case. If the transformation model describes an executable transformation and it is executed on some input model a, the execution results in a concrete transformation instance and produces a model b as output. If the transformation is correct, the model b conforms to its metamodel B. The transformation instance can be produced as an actual model in the form of a trace model1 by the execution or it can simply be the concrete pair of models a and b that are linked by the transformation.

Evolution occurs in the form of some change done to metamodel A, represented by the curved arrow at . An important part of handling the evolution of dependent artefacts is determining or recording what kind of change has taken place in a metamodel. A variety of different approaches dedicated to this problem exist for different purposes and technologies. These are discussed in chapter 8. Chapter 6 introduces an operator-based approach to describe possible changes made to a metamodel that is suited to resolving co-evolution issues with dependent transformations written in ATL.

After the metamodel is changed, the relationships to the other artefacts involved in the transformation may no longer hold and need to be evaluated and updated accordingly for the transformation to be consistent. This is represented in the figure by the flash symbol. The first relation is that of all the models a and their metamodel A at . This relationship is one of conformance, indicating whether or not the model fulfils all constraints dictated by its metamodel, or in linguistic terms, whether the model is a valid statement in the language that the metamodel represents. This co-evolution problem has been investigated by numerous researchers and a number of different approaches to address it exist (see Section 8.1 for further details). This problem is not covered further in this work and we assume that it can be handled adequately.

The next relationship that may have been impacted is that between the metamodel A and any transformation model that makes use of the metamodel. This relationship is named ‘refers to’ and the impact is illustrated at Whether or not the relationship is impacted at all by an evolution step and whether it can be resolved automatically depends on a number of factors. For example, the transformation may not even refer to the element that was changed in the metamodel and continue to function as before without needing any adaptation. Furthermore, if an impact occurs, what needs to be done to check and resolve it depends greatly on how it is expressed in the given transformation language or modelling technology. We investigate this problem for ATL as a central part of this work and suggest an approach for the impact resolution in chapter 7.

Without looking at the impact of the metamodel change and updating the transformation model accordingly, the updated models a may no longer fulfil the role of source models in their transformation instance . In practical terms this means that an executable transformation can no longer read the input models without error or even worse, it executes without raising an error but delivers false results. Both these problems can be reduced to the problem of co-evolution of the metamodel and the transformation model, as when the transformation model is updated to reflect the change in the metamodel, re-executing the model transformation leads to a new and correct set of models b and accordingly to a set of new transformation instances.

Figure 1.1 illustrates a metamodel evolution on the left-hand-side of a transformation. The problem can also occur on the right-hand-side and affect target models. Should metamodel B be changed, the target models b may become invalid, i.e. the transformation no longer produces the correct result. Here the relationship between the target metamodel and the transformation model needs to be updated to reflect the evolution. Source and target elements are referred to differently in many transformation languages so that the side of the change plays an important role when resolving its impact. For this reason many of the impact resolutions introduced in chapter 7 make this distinction.

The next section introduces an application scenario containing two metamodels and a transformation between them in ATL. It further illustrates what impact changes done to one of the metamodels have on the transformation and how resolving inconsistencies can be addressed.

1.2. Application Scenario

This section contains a small example consisting of a model transformation between two metamodels and a scenario of metamodel evolution that affects the transformation. It illustrates how the changes made to a metamodel can impact the validity of a transformation and how this impact can be resolved. The example is also used in the remainder of this work to illustrate different aspects of operators or resolutions.

Figure 1.2.: The extended EMF-Library Metamodel example

Both metamodels are slightly modified versions of those we used in [19]. The first metamodel as seen in Figure 1.2 is an extended version of the common EMF-Library metamodel example [101]. The EMF-Library is a simple domain model of a public library, with entities like ‘Book’, ‘Writer’, ‘Borrower’ etc. In this fictional scenario, we assume the EMF-Library example metamodel serves as the basis for the development activities for software applications to manage a public library.

Figure 1.3.: The IMDB Metamodel example

The second metamodel represents a small and artificial model of the domain of the Internet Movie Database (IMDB) which is an internet database of information related to films and television programs2 currently owned by Amazon. The metamodel contains entities like ‘Film’ with attributes like ‘title’ and ‘year’ of release and the ‘Actor’s that star in the film. The two domains of the two metamodels are related, as a library may also contains films that can be borrowed on video cassette.

The transformation example in listing 1.1 converts instances of the IMDB metamodel to those of the extended EMF-Library metamodel. It is written in ATL and consists of two rules. An entity of type VideoCassette is created for each IMDB entity Film. Furthermore, the information on any actor that stars as a Figure in the film is created as a Cast element and associated with the Film. This transformation could implement or model the task of adding new films into the stock of the library.

Listing 1.1: A simple transformation between the IMDB Metamodel and the extended EMF-Library Metamodel

As an example of metamodel evolution, we propose the removal of a shortcoming of the extended EMF-Library metamodel: in its current state, each VideoCassette contains the general information of the film on the cassette and a list of CastMembers that star in the film. This is fine as long as there are few duplicate cassettes of the same film in a library. Otherwise, the same information is duplicated for each copy, causing redundant information to be stored and managed. Furthermore, if we wanted to use the model to create a list of all the films an actor starred in, this is not easily done, as the CastMember is duplicated for each new cassette.

Should the library decide to start buying numerous copies of especially popular films, the model can be improved to reflect this change in the domain. One approach would be to introduce an entity ‘Film’ to represent the film itself and to associate the actors with the film. The entity VideoCassette would continue to hold the information on the actual copies available, like who borrowed a cassette and whether it is damaged or not and would be linked to the film that is on the cassette.

Three steps are necessary to accommodate this change:

Figure 1.4.: The modified extended EMF-Library Metamodel example

Some of the properties needed for the new entity

Film

currently belong to parent entities of

VideoCassette

and are available to

Video-Cassette

by inheritance. These are moved down into

VideoCassette

in preparation so that they can later be moved to

Film.

The relevant properties are

publicationDate

in

Item

and

title

and

minutesLength

in

AudioVisualItem.

This means that they also need to be moved down into other subclasses which are siblings of

VideoCassette

so that they remain available there. These are

Periodical, Book

and

BookOnTape

for the property

publicationDate

and

BookOnTape

for both the properties

title

and

minutesLength.

In the next step we can create a new entity

Film

and link the two entities by an association.

Now we can move the relevant properties and the association to

Cast-Member

from

VideoCassette

to

Film.

The resulting metamodel is shown in Figure 1.4. Please note that other entities were also updated as a result so that Book now also owns an attribute publicationDate directly.

Listing 1.2: The updated transformation between the IMDB Metamodel and the evolved extended EMF-Library Metamodel

To cater for the evolution of the metamodel, we also need to update the transformation in listing 1.1:

The first change of moving the properties along the inheritance hierarchy down to the

VideoCassette

entity does not affect the transformation at all, as the attributes were previously available by inheritance and are now available directly.

The second evolution step requires an update of the first transformation rule, as for every new

VideoCassette

that is created we now also need to create a new

Film

entity (or link to an existing one).

In the third step, properties are moved from the

VideoCassette

to the

Film

entity. Here the first rule needs to be updated again so that the correct values are set on

Film

instead of

VideoCassette.

The updated transformation is given in listing 1.2. When the transformation is updated, it is valid again and performs the same task as before. Further improvements for the metamodel are possible, like performing the same kind of differentiation between the novel and the actual physical copies (books) in stock. These would require further updates to the accompaning transformations, depending on the nature and impact of the change.

1.3. Contribution

The central contribution of this work is made in addressing the co-evolution problem for metamodels and model transformations. It consists of the following parts:

An approach for the co-evolution of metamodels and model transformations. The approach is aimed to support software architects in evolving dependent artefacts of the Model Driven System (MDS) in stepwise fashion by applying predefined operators of common evolution steps on metamodels and detecting and resolving the possibly occurring impacts on model transformations.

A Set of Co-evolution Operators for the co-evolution of metamodels and model transformations. The operators are based on the Unified Modeling Language (UML) EMOF metamodel and are formalised as relations using the Object Management Group (OMG) standard QVT Relations (QVT-R) graphical notation.

A Set of Impact Resolutions that address the impact on ATL transformations that depend on evolved metamodels. The impact resolutions are formalized as QVT-R relations for the set of operators. The impact resolutions capture the type of impact possible for the different operators and provide semi- or fully automated resolution of the impact to restore consistency between metamodel and model transformation.

A Prototypical Implementation of the approach, the operators and the impact detection and resolution. The implementation is integrated into common MDE tooling for the creation and editing of metamodels and model transformations. The implementation provides support to the software architect when applying an operator to a metamodel, in determining the resulting impact on dependent model transformations and by providing and performing available resolutions.

This work provides support for co-evolution in MDE. It addresses the problem of complexity and the tight-coupling of dependent artefacts in the context of software evolution and reduces the effort needed to prevent the occurrence of inconsistencies due to software evolution tasks for metamodels and model transformations.

1.4. Outline

This thesis consists of three main parts. In part I the foundations for this work are laid out. It is structured as follows:

Chapter 2 introduces the foundations concerning MDE: Section 2.1 introduces the concept of the ‘model’ and Section 2.2 that of the ‘metamodel’. Section 2.3 covers the Meta-Object Facility (MOF), being the standardised metamodelling framework of the UML and Section 2.4 covers Ecore, an implementation of MOF for the Eclipse IDE. In Section 2.5 the concept of model transformation is discussed.

Chapter 3 provides the concepts and languages available for creating model transformation used in this work. Section 3.1 introduces the general features of model transformation languages. Section 3.2 covers the transformation language ATL and Section 3.3 the Meta Object Facility (MOF) 2.0 Query/View/Transformation (QVT). As the Object Constraint Language (OCL) plays an important part in both languages, it is introduced in Section 3.4.

Chapter 4 covers software evolution in the context of MDE. To this end, Section 4.1 relates the co-evolution problem to the MDS and Section 4.2 introduces the related concepts in the area of model refactoring.

Part II covers the central contributions of this thesis. It contains:

Chapter 5 covers the approach presented in this thesis. It provides a problem description in Section 5.1 and details the goal pursued by our approach in Section 5.2. The requirements for the approach are detailed in Section 5.3 after which an overview of the approach is presented in Section 5.4. Sections 5.5 through 5.7 discuss the details of the three phases that make up the approach, after which a summary is provided in Section 5.8.

Chapter 6 provides the formalisation of the operators of our approach for EMOF as QVT-R relations and provides a discussion of the use and effect of each operator.

Chapter 7 covers the impacts of the operators from the previous chapter on ATL model transformations. Each operator is discussed and the proposed impact resolutions for ATL are formalised as QVT-R relations.

Chapter 8 discusses work related to our approach. Section 8.1 covers approaches dealing with the co-evolution of metamodels and models, Section 8.2 those that handle co-evolution of models and linked OCL constraints and Section 8.3 approaches that compete in the co-evolution of metamodels and model transformations.

Finally, part III discusses the evaluation of the approach with the implementation and concludes this thesis. It is structured as follows:

Chapter 9 covers the evaluation of our approach. Section 9.1 discusses aspects of completeness of the operators both on the metamodel and the transformation level. In Section 9.2 the use of operators in a coevaluation scenario containing a stepwise metamodel evolution and the resolution of impacts on a dependent transformation is presented. Section 9.3 summarises the chapter.

Chapter 10 contains the prototypical implementation of our approach. Section 10.1 provides an overview of the prototype and Section 10.2 covers the considerations made in the implementation. In Section 10.3 the details of the implementation for ATL are covered. The implementation of the operators and the integration into a graphical metamodel editor are discussed in sections 10.5 and 10.4 and the implementation of the impact resolutions in Section 10.6.

Chapter 11 concludes this thesis. Section 11.1 provides an overall summary. In Section 11.2, the benefits seen in this approach are recapitulated. Finally, Section 11.3 concludes with an outlook on future work.

1Trace models specify which input model element was transformed into which output model element and allow further aspects of model transformations like traceability and incremental transformations which are not relevant to this work.

2http://www.imdb.com

PART I

Foundations

CHAPTER 2

Model Driven Engineering

Model Driven Engineering (MDE) is a software engineering approach that aims to alleviate the complexity of software development and maintenance. It supports software engineers with suitable methods and tooling to handle the complexity of modern software systems. The complexity of a software system is broken down into manageable abstractions, each embodied by a suitable type of artefact. The most prominent artefact type is the model, along with transformations, (modelling) languages, code generators and many others. Together the artefacts constitute a Model Driven System (MDS), which serves as a representation of the software system of interest - from a software engineering perspective. In MDE, models and model engineering are utilized to raise the level of abstraction of primary artefacts and generative technologies to automate the production of secondary artefacts.

The concept of ‘model’ plays a central role in MDE. In this vein, Bézivin coined the principle ‘Everything is a model’ as the common principle behind the many different techniques and technologies used in MDE [12]. It is meant to play the same role that the principle ‘Everything is an object’ does in object technology and is an attempt to unify the different technologies and understandings of MDE and thus better define what is and what is not a part of MDE. Bézivin sees a step beyond object technology in MDE in which models take up the significance of objects and model transformation that of object composition:

‘Very differently [to object technology], what seem to be important now is that a particular view (or aspect) of a system can be captured by a model and that each model is written in the language of its metamodel. [12]

Although Bézivin does not attribute a single unique goal to MDE, he sees MDE as a result of the necessity for

‘a complete new rise in abstraction’ in dealing with ‘increasingly complex and rapidly evolving systems we are building today.’ [12]

Atkinson and Kühne follow this sentiment in that MDE is a further step in the need to handle growing and more complex systems, as

‘Model driven development (MDD) can be regarded as the natural continuation of [the trend to] ... raise the level of abstraction at which the activity [to program computers] takes place.’ [4]

Models are used by programmers to specify what functionality is required of a system and what architecture is to be used. This holds the potential to reduce the complexity of problems and achieve a higher degree of automation in software development. The underlying goal of MDE is thus to improve productivity or maintain productivity when systems grow and become more complex. Atkinson and Kühne name two areas of improvement [4]:

improving

short-term productivity,

by increasing the amount of functionality that can be derived from a software artefact. The main mechanism to achieve this goal is the automated generation of source code from visual models.

improving

long-term productivity

can be achieved by increasing the life-span of the value of artefacts.

Kühne further highlights the role of formal modelling for MDE:

‘It is one of the primary goals of model driven engineering to shift the emphasis from informal, non-binding models to rigorous, binding models.’ [56]

To achieve these goals for MDE in practice, a variety of artefacts and artefact types are used to capture the different aspects of the development process and a variety of tools to mange the different artefacts, both for the initial development and during the maintenance of the system [51]. These artefacts are tightly coupled by the different dependencies that exist between them and need to be managed along with the software system itself. Therefore, the artefacts used during development together with the dependencies between them form a complex system themselves [9]. We use the term Model Driven System (MDS) to refer to this system in this work:

Definition 1 (Model Driven System): A Model Driven System (MDS) is the collection of artefacts and tools used for the development of a software system in MDE and the dependencies between them.

Artefacts that are usually part of the model driven system are models and metamodels, but also transformations, transformation languages and codegenerators. In the next sections we look at models and metamodels in more detail (2.1, 2.2) and discuss the technologies provided by the UML and the Eclipse Modeling Framework (EMF) project to facilitate metamodelling activities (2.3, 2.4) and discuss model transformations in Section 2.5. Chapter 3 is dedicated to the different transformation languages relevant to this work.

2.1. Model

Stachowiak provides a general definition for the concept model for model theory. He associates three features with the term ‘model’: a mapping feature (Abbildungsmerkmal), as a model is always a representation of something, a reduction feature (Verkürzungsmerkmal), as the model omits attributes that are deemed irrelevant by the model’s creator or user and a pragmatic feature (Pragmatisches Merkmal), as model and original may only be matchable under certain conditions. [91, pp. 131-133]

While many different uses of the term ‘model’ exist in different contexts [30], models in software engineering are commonly made of hard- or softwarebased, real or logical systems; as representations with the purpose of reasoning about or to perform analysis on some properties of the systems.

Kühne provides a definition of ‘model’ along these lines:

‘A model is an abstraction of a (real or language-based) system allowing predictions or inferences to be made.’ [56]

This narrows down Stachowiak’s definition to the notion of a model in the context of MDE: The original that a model represents is considered to be a real or abstract system, the reduction feature is an abstraction and the purpose for reduction and the pragmatic feature is to reason about the system (instead of the system).

This directly corresponds to Bézivins and Gerbés definition of ‘model’:

‘A model is a simplification of a system built with an intended goal in mind. [...] The model should be able to answer questions in place of the actual system.’ [13]

When using the term ‘model’ in this work we further refer to the models commonly used in software engineering, which are abstract and languagebased (as opposed to for example mathematical or scale models) and are abstract systems themselves. As such, the concept of a model relates to that of a system. The ISO/IEC/IEEE 12207:2008 standard defines the term system as follows:

Definition 2 (system): A system is the ‘combination of interacting elements organized to achieve one or more stated purposes.’[47]

It further limits its scope to man-made systems, that ‘may be configured with one or more of the following: hardware, software, data, humans, processes (e.g., processes for providing service to users), procedures (e.g., operator instructions), facilities, materials and naturally occurring entities.’ [47]

Although many other types of systems exist and broader definitions of the term also cover e.g. biological systems, we deem this definition sufficient for the remainder of this work and take no further position as to what constitutes a system. We assume that models represent systems in general and that the nature of the system is left to the user or creator of the model (unless otherwise noted).

We can therefore summarize the definition of model as follows:

Definition 3 (model): An abstract system is a model of another system, if it is a simplification of the other system, created for a given purpose. The relationship between the model and the system it represents is namedrepresentationOf.

According to Kühne [56], two classes of models are relevant to software engineering, token models and type models. Token models ‘capture singular (as opposed to universal) aspects of the original’s elements, i.e., they model individual properties of the elements in the system.’ Type models instead ‘capture the universal aspects of a system’s elements by means of classification.’

Whether or not the relation between system and model holds; i.e. the question whether a model correctly represents a system depends on the purpose for which the relation is observed. This provides a context under which this relation between two systems is that of one being a representation of the other; i.e. one system has the role of a model in the given context (Stachowiak’s pragmatic feature). This allows for the treatment of models as systems and the other way around depending on the context. Nevertheless, we presume it is safe to use the term model as short hand for ‘a system in the role of a model in context X’ if the context is deducible.

2.2. Metamodel