Single Underlying Models for Projectional, Multi-View Environments

Johannes Meier

, Heiko Klare

, Christian Tunjic

Colin Atkinson

, Erik Burger

, Ralf Reussner

and Andreas Winter

Software Engineering Group, University of Oldenburg, Germany

Software Design and Quality Group, Karlsruhe Institute of Technology, Germany

Software Engineering Group, University of Mannheim, Germany

Keywords:

Projectional, SUM, Model Consistency, Integration, Metamodeling.

Abstract:

Multi-view environments provide different views of software systems optimized for different stakeholders.

One way of ensuring consistency of overlapping and inter-dependent information contained in such views is

to project them “on demand” from a Single Underlying Model (SUM). However, there are various ways of

building and evolving such SUMs. This paper presents criteria to distinguish them, describes three archety-

pical approaches for building SUMs, and analyzes their advantages and disadvantages. From these criteria,

guidelines for choosing which approach to use in speciﬁc application areas are derived.

1 INTRODUCTION

Due to the ever growing complexity of modern

software-intensive systems single developers are no

longer able to understand all aspects of a system as

a whole. View-based development methods are there-

fore needed to separate system descriptions into in-

dividual parts that are relevant to the concerns and

responsibilities of single developers. However, the

resulting fragmentation of system descriptions leads

to redundancies and dependencies between the infor-

mation shown in different views, which are difﬁcult

and time consuming to manage manually. Automa-

ted approaches for ensuring the holistic consistency

of multi-view system descriptions are therefore nee-

ded.

View-based approaches can be synthetic or pro-

jective (ISO/IEC/IEEE, 2011), depending on where

information is stored. In synthetic approaches, the

description of the system is spread over all the indi-

vidual views, whereas in projective approaches, the

description is contained in a Single Underlying Mo-

del (SUM) (Atkinson et al., 2010), and views are pro-

jected from this central store of information as nee-

ded. As with all models in model-driven develop-

ment, a SUM conforms to its metamodel, the Single

Underlying MetaModel (SUMM).

The goal of this paper is to illuminate diffe-

rent strategies for supporting projective approaches

to view-based software engineering and to highlight

their pros and cons. The common underlying property

of all projective approaches is that views are conside-

red to be correct by construction and thus inherently

consistent with each other as long as they are consis-

tent with the SUM. The problem of maintaining inter-

view consistency therefore becomes the problem of

maintaining the internal consistency of the SUM and

the correctness of SUM-to-view projections. To des-

cribe the different approaches in a uniform way and

analyze their pros and cons systematically, this pa-

per classiﬁes the different fundamental strategies for

constructing SUMs and their corresponding SUMMs,

and identiﬁes criteria for evaluating them. More spe-

ciﬁcally, three existing approaches for constructing

SUM(M)s are compared in terms of how they fulﬁll

the identiﬁed criteria. Finally, we analyze how the

fulﬁllment of the identiﬁed criteria by the different

approaches affects their suitability for speciﬁc situ-

ations.

The insights presented in this paper will allow

researchers to classify new approaches for SUM(M)

constructions and help developers to choose projecti-

onal view-based approaches for their speciﬁc project

situations using the identiﬁed selection criteria.

After introducing a running example and termino-

logy used in this paper in Section 2, classiﬁcation cri-

teria for SUM approaches are described in Section 3.

The three SUM approaches OSM (Section 4), VI-

TRUVIUS (Section 5), and MOCONSEMI (Section 6)

are presented subsequently and are classiﬁed using

Meier, J., Klare, H., Tunjic, C., Atkinson, C., Burger, E., Reussner, R. and Winter, A.

Single Underlying Models for Projectional, Multi-View Environments.

DOI: 10.5220/0007396401170128

In Proceedings of the 7th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2019), pages 117-128

ISBN: 978-989-758-358-2

117

the criteria in Section 7. From this classiﬁcation, gui-

delines for deciding which approach to choose when

are derived in Section 8. After discussing related

work in Section 9, Section 10 summarizes the ﬁndings

of this paper.

2 TERMINOLOGY & RUNNING

EXAMPLE

To motivate the use of several interconnected views in

the development of a system, we introduce a highly

simpliﬁed running example describing the require-

ments, architecture and implementation of a system.

These three views are expressed in languages based

on metamodels that deﬁne the elements (e.g., classes,

attributes etc.) that can appear in models. We depict

those metamodels in Figure 1. This section also clari-

ﬁes the terminology used in this paper.

Requirements are represented by natural language

sentences (package Req). Each Requirement within

a RequirementsSpecification is identiﬁed by a

unique id, which contains the requirement’s sentence

as simple text, and is written by an author.

The architecture is described by simpliﬁed class

diagrams, which represent system modules as classes

(package UML). ClassDiagrams contain Classes with

their className and unidirectional Associations.

The implementation realizing the architecture and

requirements is represented by source code develo-

ped in simpliﬁed Java (package Java). The JavaASG

contains ClassTypes, which in turn contain Methods

with their caller/callee relations.

These three languages describe different (not ne-

cessarily all) facets of the system under development

and thus represent three overlapping viewtypes. Ac-

cording to Goldschmidt et al. (2012), a viewtype is

the metamodel of a view, while a view is a model

that projects information from another model (here:

the SUM) for a speciﬁc purpose. Since all views

share information about the system under develop-

ment, they are semantically interconnected and con-

tain dependent information, which requires updates of

other views if one is changed. The interdependence of

information can be explicitly deﬁned in consistency

rules, which deﬁne the relations that have to hold be-

tween instances of metamodels.

We deﬁne two exemplary consistency rules for the

running example: While Consistency Rule 1 covers a

situation where existing redundant information needs

to be kept consistent, Consistency Rule 2 addresses

a different problem of introducing additional infor-

mation depending on other information. We consi-

der these consistency rules representative, since inte-

grating different views usually refers to merging con-

cepts or introducing additional associations.

Consistency Rule 1: Classes can be deﬁned in the ar-

chitecture view and in the implementation view: One

concrete class can be deﬁned either only in the im-

plementation (Java.ClassType), or in both imple-

mentation and the architecture (UML.Class) if it re-

presents a module. In the latter case, this class has

to be kept consistent in the implementation and archi-

tecture, e.g., in the case of renaming this class. The-

refore, the implementation and architecture are only

consistent if the architecture contains a subset of the

classes in the implementation.

Consistency Rule 2: Since requirements deﬁne

goals that the implementation should fulﬁll, the de-

velopment progress can be measured by counting the

requirements that are supported by the current imple-

mentation. Therefore, Requirements must be lin-

ked to the implementing Methods. We thus require

that each Method has to be automatically linked to

those Requirements that contain the Method’s name

in their text. This additional information between re-

quirements and implementation has to be stored and

kept consistent. Since this is a simpliﬁed example for

this paper, different rules can be speciﬁed instead.

These two consistency rules and three languages

are used to motivate criteria for SUM approaches in

Section 3. SUM approaches deﬁne how SUMs as well

as their SUMMs are constructed and are designed by

platform specialists, who develop platforms that sup-

port SUM-based development. Three such platforms

are presented in Sections 4–6 and applied to this run-

ning example by a methodologist, who uses a SUM

platform to deﬁne a concrete SUMM to support a par-

ticular view-based method (Atkinson et al., 2010).

Depending on the approach, to create the SUMM

the methodologist either reuses the existing metamo-

RequirementsSpeciﬁcation

Requirement

id : EString [0..1]

author : EString [0..1]

text : EString [0..1]

JavaASG

ClassType

name : EString [1]

Method

name : EString [1]

ClassDiagram

Class

className : EString [1]

Association

name : EString [1]

lowerBound : EInt [0..1]

upperBound : EInt [0..1]

container [1]

content [∗]

asg [1]

classes [∗]

class [1]

methods [∗]

calledBy [∗] calling [∗]

diagram [1]

classes [∗]

class [1]

associations [∗]

type [1]

usedBy [∗]

Req

Java

UML

Figure 1: Simpliﬁed Metamodels for Requirements (left), Class Diagrams (middle), and Java Source Code (right).

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

118

dels in Figure 1 or deﬁnes a new metamodel for the

described concepts. After that, the developer instan-

tiates that SUMM deﬁned by the methodologist to

develop a software system through views projected

from the SUM. The methodologist can also specify

new viewtypes to provide new views corresponding to

the speciﬁc concerns of the developer.

3 CLASSIFICATION CRITERIA

In this section, we identify two groups of criteria for

classifying SUM approaches according to how they

can be designed once (i.e., the nature of the con-

struction process and resulting SUM(M)) and how

they should be selected for various applications (i.e.,

which approach is best in which context). This list

of criteria is the ﬁrst contribution of this paper. By

applying them to different SUM approaches, we eva-

luate indicators for their appropriateness in Section 7.

3.1 Design Criteria

Design criteria distinguish SUM approaches from

each other at conceptual level regarding the structure

of created SUM(M)s and their construction process.

These criteria are independent from technical design

decisions. The goal of this set of criteria is to span the

complete solution space of possible SUM approaches.

The criteria are not evaluative but rather distinguis-

hing. In other words, the fulﬁllment of a criterion by

an approach does not have implications on whether it

is favorable over another approach. They inform plat-

form specialists about the possible conceptual degrees

of freedom when designing a SUM approach.

Criterion C1 (Construction Process) covers the

process of creating a SUM(M) depending on the star-

ting situation. In a top-down development approach, a

new SUM, and especially its SUMM, is created from

scratch. A bottom-up approach starts with already ex-

isting models and metamodels, which have to be com-

bined into a SUMM and initial SUM.

Criterion C2 (Pureness) relates to the absence of

internal redundancy in the SUM under construction.

An essential SUM is “completely free of any internal

redundancy” (Atkinson et al., 2015) and dependen-

cies by design. A pragmatic SUM contains redundant

information (e.g., because it contains different meta-

models that deﬁne concepts more than once) that has

to be interrelated and kept consistent, and thus only

behave as if it was free of dependencies due to inter-

nal consistency preservation mechanisms. Pragmatic

SUMs require additional information to wire the in-

ternal models together and thus involve more complex

consistency rules than equivalent essential SUMs.

While C1 focuses on the starting point of the

SUM construction process, C2 focuses on the results.

Together they allow SUM approaches to be compared

at conceptual level.

3.2 Selection Criteria

Selection criteria support the selection of the most ap-

propriate SUM approach for a particular project. This

set of criteria addresses the conceptual preconditions

and requirements that favor one SUM approach over

another in a speciﬁc situation. These criteria help met-

hodologists to compare different SUM approaches for

the same application scenario. For example, if exis-

ting metamodels need to be reused, it is best to select

and apply a SUM approach that simpliﬁes the reuse

of existing metamodels. The fulﬁllment of those cri-

teria by a speciﬁc SUM approach is affected by the

allocation of design criteria for that approach.

Criterion E1 (Metamodel Reusability) determi-

nes whether concepts to be represented in the SUMM

are already available within predeﬁned metamodels

and should be reused in the new SUMM. If so, the

SUM approach has to accommodate these legacy me-

tamodels by combining them into an initial SUMM.

This can either be done directly without additional

work or indirectly by providing strategies for migra-

ting the legacy metamodels into the SUMM. Since

lots of languages, metamodels and tools with ﬁxed

viewtypes are usually already available, approaches

fulﬁlling this criterion support their reuse. Reusing

metamodels usually implies a bottom-up approach ac-

cording to C1.

Criterion E2 (Model Reusability) establishes

whether already existing artifacts (i.e., existing in-

stances of the metamodels to be integrated) need to

be incorporated in an initial version of the SUM. If

so, the SUM approach has to import these models.

This can be done either directly without additional

work or indirectly by providing a strategy for migra-

ting the legacy models into views of the SUM or di-

rectly into the SUM by some kind of model-to-model

transformations. It requires the reuse of the corre-

sponding initial metamodels according to E1 and usu-

ally requires a bottom-up strategy according to C1.

Reusing models may require that models have to be

consistent according to the consistency relations be-

tween the integrated metamodels before they are in-

tegrated into the SUM. This requires additional ma-

nual effort to ensure consistency beforehand, in con-

trast to SUM approaches which offer strategies to

handle inconsistent information during their integra-

tion into the SUM. Existing artifacts developed wit-

Single Underlying Models for Projectional, Multi-View Environments

119

hout a consistency-preserving SUM approach usually

do not initially fulﬁll the consistency relations, which

is why this criterion also checks whether those incon-

sistencies can be handled automatically during inte-

gration.

Criterion E3 (Viewtype Deﬁnability) focuses

on the task of specifying new types of views on a

SUMM. This involves the creation of new viewtype

deﬁnitions, focused on speciﬁc concerns (e.g., mana-

ging the traceability links from Consistency Rule 2)

whose instances can be used by developers to change

the related information in the SUM. Supporting the

deﬁnition of customized, role-speciﬁc viewtypes is

an essential capability of view-based development ap-

proaches, so the level of difﬁculty involved has a

strong impact on the usability of an approach.

Criterion E4 (Language Evolvability) focuses

on the task of maintaining the SUMM in the face of

evolved language concepts represented in their me-

tamodels, changed consistency rules, and the integra-

tion of new viewtypes. Changes in the metamodel can

require corresponding changes in the model (i.e., mo-

del co-evolution (Herrmannsdoerfer et al., 2011)) as

well as the creation or adaptation of consistency ru-

les. Since languages are subject to change (e.g., new

version of Java are regularly introduced) the difﬁculty

of updating the SUMM and its instances after evolu-

tion of the integration languages is a relevant crite-

rion, whose importance depends on the probability of

languages to evolve in a concrete setup.

Criterion E5 (SUMM Reusability) focuses on

the question of whether only a subset of the integra-

ted metamodels and their consistency rules from one

project can be reused to construct a SUMM for other

projects, or if a SUMM can only be reused as a whole.

Additionally, this criterion addresses the amount of

effort involved in adding new metamodels to an alre-

ady existing SUMM. Although this criterion does not

target reuse at the model level, it is important since,

for example, there are many software development

projects that use slightly different languages or con-

sistency rules, which need to be managed.

4 ORTHOGRAPHIC SOFTWARE

MODELING

Orthographic Software Modeling (OSM) is a view-

based approach, initially developed to support multi-

perspective software development (Atkinson et al.,

2010) but can be applied to other domains like en-

terprise architecture modeling (Tunjic et al., 2018) to

support methods like Zachman (Zachman, 1987).

ClassUseClass

name : EString [1]

lowerBound : EInt [0..1]

upperBound : EInt [0..1]

Class

name : EString [1]

Method

name : EString [1]

Requirement

id : EString [0..1]

author : EString [0..1]

text : EString [0..1]

fullﬁlls [∗]

fulﬁlledBy [∗]

class [1]

methods [∗]

class [1]

classUseClass [∗]

type [1]

usedBy [∗]

calling [∗]calledBy [∗]

SUMM

Figure 2: Exemplary Metamodel for SUM in OSM.

4.1 Main Ideas

The OSM approach is inspired by the orthographic

projection technique used to visualize physical ob-

jects in CAD systems. OSM utilizes this principle

to deﬁne “orthogonal” views on a system under de-

velopment that present each stakeholder, such as soft-

ware engineers, with the data he needs in a domain-

speciﬁc notation. Although stakeholders can only

see and manipulate the system via views, the actual

description of the system is stored in a SUM. The

views are deﬁned to be as “orthogonal” as possible

through independent dimensions (i.e., concerns) ran-

ging from behavioral properties and feature speciﬁ-

cations to architectural composition. Ultimately, the

system description in the SUM can be made formal

enough to be automatically deployed and executed on

appropriate platforms, thus allowing automatic rede-

ployment when changes occur. In order to support

the complete life-cycle of a system, ranging from re-

quirements analysis to deployment, the internal struc-

ture of the SUM must be able to store all required

data in a clean and uniform way. The data in the

SUM should thus be free from dependencies and cap-

ture all relationships between its inner elements in a

redundancy-free way using approaches like Informa-

tion Compression and Information Expansion (Atkin-

son et al., 2015).

Figure 2 shows an example of an OSM-oriented

SUMM corresponding to the information presented

in Figure 1. Since a fundamental tenet of the OSM

approach is to have a pure and optimized SUMM, it

is usually created manually from scratch based on the

needed viewtypes and concerns of the involved stake-

holders. Figure 2 is a reduced version of Figure 1 in

which all redundant information, and thus the corre-

spondences that connect duplicate stores of data, have

been manually removed. Thus, for example, the two

equivalent elements ClassType and Class have been

compressed into one concept Class in Figure 2. This

is possible because although the two concepts deﬁne

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

120

their own properties for their own contexts, and use

different names (i.e., name and className), they are

in fact equivalent and can be combined. Both attribu-

tes are therefore mapped to the single attribute name in

the SUMM. The two dependencies are distinct, howe-

ver, and are hence both added to the Class element:

The ﬁrst enables Classes to have Methods, while the

second describes dependencies between two Class

elements (Consistency Rule 1).

Consistency Rule 2 is modelled through a relati-

onship between Requirement and Method, denoting

that the requirement is being fulﬁlled by the method.

In order to allow developers to create instances of the

relationship, a new view can be deﬁned, which at le-

ast contains the concepts Requirement, Method and

the relationship between these two.

The data structure shown in Figure 2 is simpler

and more optimized than the disparate representation

in Figure 1. This is achieved by the uniﬁed names

for dependent concepts (ClassType vs. Class) and

usage of names with more meaning (Association

vs. ClassUseClass). Although the SUMM is built

from scratch in the presented example, in principle it

is possible to import existing artifacts into the envi-

ronment using model-to-model transformations.

4.2 Process of Application

In order to make use of OSM, an environment has

to be developed which realizes its goals and princi-

ples. Both steps, i.e., the deﬁnition of the approach

and the implementation of a framework which sup-

ports the concepts of the approach, are performed

by a platform specialist. The work involves the de-

velopment of a framework which can be customi-

zed for the used methodology (e.g., KobrA (Atkin-

son, 2002), MEMO (Frank, 2002), ArchiMate (Iacob

et al., 2012)) and targeted domain (e.g., software en-

gineering, enterprise architecture modeling). The dif-

ferent conﬁgurations can be reused for projects in the

same domain and the same methodology. Tunjic et

al. (2018) present a metamodel which is used by the

current prototype implementation to support the con-

ﬁguration of OSM environments. In particular, it faci-

lities the conﬁguration of the SUMM and viewtypes,

and their integration in a dimension-based view navi-

gation approach using hyper-cubes of the kind used in

OLAP (Codd et al., 1993) systems.

The customization of the environment for a speci-

ﬁc domain and methodology is performed by a soft-

ware engineer playing the role of a methodologist. In

order to be able to conﬁgure and customize the envi-

ronment according to the requirements, the methodo-

logist must have knowledge of the involved domain

and the OSM environment. In particular, he is re-

sponsible for deﬁning the SUMM and the viewtypes

in a way that adheres to the principles of redundancy-

freeness and minimality. Deﬁning a viewtype invol-

ves the deﬁnition of a suitable metamodel as well as a

model transformation that maps the concepts from the

SUM to those in a view and vice versa. The resulting

conﬁguration can be stored in the tooling environment

in order to be reused in other projects.

Once a complete conﬁguration of an OSM envi-

ronment has been deﬁned by the methodologist, one

or more developers can use it to develop a speciﬁc sy-

stem speciﬁcation. To this end, either an empty SUM

is created to start a project from scratch, or existing

content is imported into the SUM using model-to-

model transformations from external artifacts. When

using the OSM platform to develop a system, deve-

lopers are able to access views using the dimension-

based view navigation approach and use them to see

and update information from the SUM.

5 VITRUVIUS

The VITRUVIUS approach (Kramer et al., 2013) assu-

mes the existence of metamodels that are reused and

integrated into a so called virtual SUMM (V-SUMM)

rather than the development of a new SUMM from

scratch. In other words, it focuses on building a prag-

matic SUMM in a bottom-up fashion.

5.1 Main Ideas

The VITRUVIUS approach is based on the projectio-

nal SUM idea of the OSM approach. The whole sy-

stem description is encapsulated in a SUM and only

projectional views can be used to modify informa-

tion in the SUM. Instead of creating a completely

new SUMM without dependent information, howe-

ver, VITRUVIUS follows a pragmatic approach by

coupling existing metamodels using consistency pre-

servation rules (CPRs), which deﬁne how consistency

is preserved after modiﬁcations. The CPRs use and

modify correspondences, which reference model ele-

ments that represent dependent information and can

be seen as a trace model. The set of metamodels

with their CPRs deﬁnes a virtual SUMM (V-SUMM),

while instances of them with an actual model of cor-

respondences are denoted as V-SUMs. These CPRs

make dependencies between metamodels explicit and

ensure that after modiﬁcations in one model, all ot-

her dependent models are updated consistently. As

a consequence, a V-SUM behaves completely like an

Single Underlying Models for Projectional, Multi-View Environments

121

Req

UML

Java

CPR

metamodel

CPR

consistency

preservation

rule

viewtype

view trans-

formation

Figure 3: Example V-SUMM in VITRUVIUS.

ordinary SUM since it provides the same guarantees

regarding information consistency.

An exemplary V-SUMM for the metamodels from

Figure 1 is depicted in Figure 3. It consists of the

reused metamodels with CPRs deﬁned between them.

For Consistency Rule 1, a CPR deﬁnes the creation of

a Java class ClassType in reaction to the creation of

a UML class Class. It is up to the methodologist to

specify the behavior in the other direction, i.e., whet-

her a UML class is created for a Java class or if the

developer shall be asked what to do. Additionally,

it propagates all changes on the name or className

to the respective other model. The additional requi-

rements traces in Consistency Rule 2 can be expres-

sed by identifying matching requirements and met-

hods after adding or modifying methods as well as

requirements, and by storing them as appropriate cor-

respondences in the existing trace model. Alternati-

vely it is possible to deﬁne an additional metamodel

that deﬁnes links between requirements and methods,

which is modiﬁed whenever they are changed.

Two types of projectional viewtypes can be deﬁ-

ned on a V-SUMM. First, the original viewtypes de-

ﬁned for the existing metamodels, such as a textual

editor for Java or a graphical editor for UML, can be

reused. In Figure 3, these viewtypes are V T

, V T

and

V T

, which represent the original metamodels from

Figure 1. Second, it is also possible to deﬁne addi-

tional viewtypes that may combine information from

different metamodels and their relations deﬁned in the

CPRs. Figure 3 contains V T

, which displays the trace

information for Consistency Rule 2 by extracting in-

formation from the Java and the requirements model,

as well as from the correspondences generated by the

CPR. Concretely, this viewtype could, for example,

show the Java code with annotations attached to the

methods that show the requirements they fulﬁll. Ne-

vertheless, for deﬁning such viewtypes, specialized

languages that support the projection from, and com-

bination of, different metamodels is required. In VI-

TRUVIUS, those can be expressed with the ModelJoin

language (Burger et al., 2014).

Consistency preservation in VITRUVIUS is perfor-

med in a delta-based manner. In contrast to state-

based consistency preservation, edit operations are

tracked instead of comparing two model states, which

results in less information loss (Diskin et al., 2011).

For example, a state-based approach can distinguish

the deletion and creation of an element from its rena-

ming only using heuristics, whereas delta-based ap-

proaches track the correct operations. To deﬁne such

delta-based consistency preservation, speciﬁc consis-

tency preservation languages have been developed

(Kramer, 2017). Initial investigations into consistency

preservation in VITRUVIUS have been made on a case

study of component-based architectures, Java code

and code contracts (Kramer et al., 2015).

5.2 Process of Application

The development of frameworks such as VITRUVIUS

ﬁrst involves a platform specialist who deﬁnes an

abstraction representing the interface of a V-SUM,

implements the logic for executing CPRs and deﬁ-

nes or selects speciﬁc languages or at least an inter-

face to deﬁne CPRs. The current implementation of

the VITRUVIUS approach (http://vitruv.tools)

uses Ecore and contains a Java-based deﬁnition of V-

SUMs and provides two languages for deﬁning con-

sistency preservation on different abstraction levels.

The methodologist then selects a set of metamo-

dels and deﬁnes or reuses existing CPRs for the se-

lected metamodel to deﬁne a V-SUMM of these ar-

tifacts. Finally, the developer can instantiate the V-

SUMM, derive views according to existing or ne-

wly deﬁned viewtypes, and perform modiﬁcations of

them. Modiﬁcations in a view are recorded as sequen-

ces of atomic change events (creation, deletion, inser-

tion, removal and replacement) and then sequentially

applied to the V-SUM. For each of these changes, the

responsible CPRs are executed to restore consistency

after each modiﬁcation, which results in an inducti-

vely consistent V-SUM.

6 MOCONSEMI

MOCONSEMI (MOdel CONSistency Ensured by

Metamodel Integration, (Meier and Winter, 2018))

combines major features of the other two SUM ap-

proaches, i.e., creating one SUM by operator-based

transformations with reusing existing (meta)models

as starting point.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

122

6.1 Main Ideas

MOCONSEMI is a SUM approach which starts

with existing initial models and conforming metamo-

dels (exemplarily shown in Figure 1) and creates a

SUM(M) suggested by Atkinson et al. (2010). In

practice, many models and metamodels already

exist in form of DSLs and tools with ﬁxed data sche-

mas. To reuse them even in integrated form, these

initial models and metamodels are reused for the inte-

gration and the models are kept in sync as views.

The integration of initial (meta)models from the

running example in Figure 1 into a SUM(M) resulting

in Figure 5 is described by a chain of operators, as

depicted in Figure 4. To form the SUM(M) out of

the initial (meta)models, theses operators change the

current (meta)model in a step-wise way. Starting

with the initial model and metamodel representing

Requirements , the initial (meta)models for Java and

ClassDiagrams are included technically at 1 and

3 , which require ProjectData and its compositions

as container without any contentwise integration.

The ﬁrst operator AddAssociation is used to ful-

ﬁll Consistency Rule 2. To enable the desired tracea-

bility links between requirements and methods, a new

association between Requirement and Method is re-

quired and created by the operator. In the model, links

can be added for this new association. This is also

done by the operator corresponding to a decision to

control this model change. This ensures that a met-

hod is linked with those requirements that contain the

name of the method in their requirements text.

Consistency Rule 1 is realized in MergeClasses

5 → 6 after the operator ChangeMultiplicity is

applied twice 5 as preparation, because the two clas-

ses Class (from UML) and ClassType (from Java)

are merged into one single class representing data

classes both in UML and Java at the same time.

The instances are merged in the same way suppor-

ted by the model decision that the same instances are

identiﬁed by same values for Class.className and

ClassType.name speciﬁed by the methodologist. As

a result of this merge, redundant information is re-

moved from the current (meta)model. The opera-

tor MergeAttributes is a follow-up treatment, af-

ter which the methodologist decided that the integra-

tion is done. The last stable model and metamodel

are used as the SUM(M) , for which Figure 5 marks

the contentwise changes in red compared to the initial

metamodels in Figure 1.

Summarizing, each operator performs small chan-

ges on the current metamodel (e.g., adds a new associ-

ation) controlled by metamodel decisions (e.g., mul-

tiplicities, source and target class of the new associa-

tion). The operator also changes the current model to

keep it consistent to the changed metamodel for mo-

del co-evolution (Herrmannsdoerfer et al., 2011). De-

grees of freedom of this change are inﬂuenced by mo-

del decisions, which allow consistency rules to be ful-

ﬁlled (e.g., specify, when new links should be added).

Result is one valid intermediate model conforming to

one valid metamodel represented by i . To keep the

initial models up-to-date, changes in the SUM have

to be propagated back to them, which requires ope-

rators to be executed backwards. Therefore, each

operator is combined with an inverse operator, e.g.,

DeleteAssociation for AddAssociation.

In the end, the same operator chain describes the

SUMM by collecting the metamodel changes, creates

the initial SUM by executing the operators at model

level reusing the initial models, and ensures consis-

tency between all models by executing operators in

both directions. The SUM and SUMM both exist and

the SUM is directly usable as a ﬁrst new view for de-

velopers. The SUM is used as a single point-of-truth,

from which all initial and new views can be generated.

6.2 Process of Application

The approach and a supporting framework are deve-

loped once by the platform specialist. This includes

the design and the implementation of the operators

(currently 20 including inverse ones). The frame-

work is under development using Java and a subset

of Ecore, reusing parts of Eclipse EDapt (Herrmanns-

doerfer, 2010), and extending some coupled opera-

tors (Herrmannsdoerfer et al., 2011).

After that, the methodologist creates a chain of

operators like in Figure 4 individually for each pro-

ject by reusing the provided operators and conﬁguring

them regarding the speciﬁc consistency rules. Additi-

onally, the operators can be used to deﬁne new view-

types on top of the SUMM.

Since the initial (meta)models are “migrated”

to view(type)s on the SUM(M), the developer can

change them as well as the SUM and the newly de-

ﬁned views. These changes are propagated automa-

tically to all other models by executing the operator

chain in forward and backward directions, which en-

sures consistency to the developer’s model decisions.

7 CLASSIFICATION OF

APPROACHES

This section classiﬁes the three presented SUM ap-

proaches regarding the criteria presented in Section 3

Single Underlying Models for Projectional, Multi-View Environments

123

Requirements

Java

Add As-

sociation

ClassDiagram

Change

Multiplicity

Merge Classes

SUM(M)

Merge At-

tributes

Figure 4: Chain of Conﬁgured Operators for Integrating Textual Requirements, Class Diagrams, and Java into a SUM(M).

RequirementsSpeciﬁcation

Requirement

id : EString [0..1]

author : EString [0..1]

text : EString [0..1]

JavaASG

ClassType

name : EString [1]

Method

name : EString [1]

ProjectData

ClassDiagram

Association

name : EString [1]

lowerBound : EInt [0..1]

upperBound : EInt [0..1]

container [1]

content [∗]

asg [0..1]

classes [∗]

class [1]

methods [∗]

calledBy [∗] calling [∗]

containsRequirementsSpeciﬁcation [∗]

integrator [0..1]

containsJavaASG [∗]

integrator [0..1]

fulﬁlled [∗]

fulﬁlledBy [∗]

integrator [0..1]

containsClassDiagram [∗]

classes [∗]

diagram [0..1]

class [1]

associations [∗]

type [1]

usedBy [∗]

SUMM

Figure 5: SUMM with Integrated Textual Requirements, Class Diagrams and Java.

as second contribution of this paper. The classiﬁca-

tion serves both as a comparison of the three appro-

aches, as well as an indicator of the appropriateness

of the developed criteria to distinguish SUM approa-

ches. Table 1 summarizes the classiﬁcation.

7.1 Design Criteria

The overall development strategy, top-down vs.

bottom-up (C1), relates to whether existing models

and metamodels are used as starting point. OSM

works top-down by creating an essential SUM(M),

which, although technically independent, may be con-

ceptually based on existing (meta)models. VITRU-

VIUS and MOCONSEMI, on the other hand, operate

bottom-up, because they are able to reuse initial mo-

dels and metamodels. While VITRUVIUS keeps them

unchanged inside the modular SUM(M), MOCON-

SEMI transforms them into an essential SUM(M).

All approaches can lead to either an essential or

pragmatic SUM(M) in terms of C2. OSM is desig-

ned to have an essential SUM(M) without any internal

dependencies. VITRUVIUS is designed to use a prag-

matic SUM(M), since it incorporates all initial models

with overlapping and, in general, dependent informa-

tion. MOCONSEMI starts pragmatically, combining

all initial models into one, but gradually moves to-

wards an essential SUM(M) by removing dependent

information or keeping them consistent through ope-

rator application. In special cases, this can lead to an

essential SUM(M) without dependent information.

7.2 Selection Criteria

Metamodel Reusability (E1) requires that a preex-

isting set of metamodels and tools is reused to ge-

nerate the SUMM. OSM supports this feature only

conceptually (“hard”), because engineers can always

informally draw upon the information contained in

existing metamodels when constructing the essential

SUMM, either manually or by model-to-model trans-

formations, but this is not a formal part of the ap-

proach. VITRUVIUS supports this feature directly

(“easy”), because it reuses and keeps the initial meta-

models as internal parts of the modular SUMM, but

depends on additional logic that builds the consis-

tency preservation mechanisms. MOCONSEMI sup-

ports this feature by using the initial metamodels as

the starting point for the subsequent transformati-

ons into a purer SUMM (“easy”). In general, only

bottom-up approaches (C1) can easily fulﬁll E1, be-

cause in top-down approaches a new metamodel has

to be deﬁned, which hampers metamodel reuse.

Model Reusability (E2) requires preexisting mo-

dels to be incorporated into the initial SUM. OSM

supports this feature in a semi-automatic way (“hard”)

by importing data from existing models into the ne-

wly constructed SUM using model transformations.

Although models do not need to be initially consis-

tent, the transformations have to be deﬁned such that

they generate consistent output. VITRUVIUS supports

this feature partially (“middle”), because it reuses and

keeps the initial models as internal parts of the modu-

lar SUM. Nevertheless, this requires the reused mo-

dels to be consistent according to the consistency ru-

les between the metamodels. This can require high

manual effort for the initial integration. MOCON-

SEMI supports this feature by using the initial mo-

dels as the starting point for subsequent transformati-

ons that create a purer SUM (“easy”). Even if models

are not consistent before, the application of operators

to integrate the models can handle and ﬁx inconsis-

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

124

Table 1: Comparison of the three Approaches regarding Design Criteria and Selection Criteria.

Criterion OSM VITRUVIUS MOCONSEMI

C1 Construction Process top-down bottom-up bottom-up

C2 Pureness essential pragmatic pragmatic → essential

E1 Metamodel Reusability hard easy easy

E2 Model Reusability hard middle easy

E3 Viewtype Deﬁnability easy hard middle

E4 Language Evolvability middle easy middle

E5 SUMM Reusability middle easy middle

tencies. In general, only bottom-up approaches (C1)

can easily fulﬁll E2, but the effort for reuse highly

depends on the necessity to have initially consistent

models.

Viewtype Deﬁnability (E3) deals with the speci-

ﬁcation of new viewtypes for the SUMM by metho-

dologists. OSM eases viewtype deﬁnition (“easy”),

because it provides an essential SUMM containing

all concepts in an integrated, redundancy-free way.

VITRUVIUS makes viewtype deﬁnition more difﬁcult

(“hard”), because information is spread across meta-

models and has to be combined referring to the de-

ﬁned consistency relations or using specialized lan-

guages. MOCONSEMI eases viewtype deﬁnition in

contrast to VITRUVIUS, but requires slightly more ef-

fort than OSM, especially if the SUMM is not essen-

tial (“middle”). Rather than arbitrary transformations

usable in the OSM approach, the operators for inte-

gration are also used for specifying new viewtypes.

In general, E3 is directly inﬂuenced by the pureness

of an approach (C2), as pragmatic approaches always

have to deal with the problem of fragmented informa-

tion, whereas essential approaches provide the neces-

sary information in a minimalistic way.

Language Evolvability (E4) deals with maintai-

ning the SUMM in the face of changes to the inte-

grated metamodel elements or the consistency rules.

OSM simpliﬁes SUMM evolution, since it is free of

redundant information, but has to check that the chan-

ges keep the SUMM essential. However, the trans-

formations that generate views to the SUM have to

be updated manually to stay up-to-date with SUMM

changes (“middle”). VITRUVIUS simpliﬁes metamo-

del evolution, since the initial metamodels are kept

unchanged as sub-parts of the modular SUMM. The-

refore, metamodels can evolve directly (“easy”). Ad-

ditionally, the consistency preservation rules targeting

the changed metamodel have to be checked and ﬁxed

if required, as well as the deﬁned viewtypes which

depend on the effected metamodels. MOCONSEMI

supports metamodel evolution, but the effort depends

strongly on the kind of change (“middle”), which is

true also for the other approaches to some less degree.

If changes in the initial metamodels can be realized

by describing the difference between the old and new

metamodel version by a chain of operators, the exis-

ting operator chain must only be extended by them.

The same applies for changed consistency rules. In

all other cases, some of the existing operators have

to be changed. In general, metamodel evolution is ea-

sier to realize in pragmatic approaches (C2), since the

SUMM is constructed out of existing metamodels, le-

ading to a formal relation between them. A drawback

of having dependencies is that their consistency must

be preserved after language evolution. On the other

hand, in essential approaches the relations between

the existing artifacts and the SUMM only exist con-

ceptually. Thus, changes in existing languages must

be manually transferred to the SUMM ensuring its

redundancy-freeness and minimality, leading to high

effort and error potential.

SUMM Reusability (E5) addresses the challenge

of adding new metamodel elements to or removing

some of the already integrated metamodels from the

existing SUMM to reuse the SUMM in a different

context. Therefore, no models are reused and model-

co-evolution is not needed here. OSM makes it easy

to add new concepts to an existing SUMM, since

they can be inserted directly into the existing struc-

ture where they are needed. However, redundancy-

freeness must be preserved and removing parts of the

SUMM requires related concepts to be checked to en-

sure consistency (“middle”). VITRUVIUS makes it

easy to add a new metamodel “as is” by adding it to

the modular SUMM and specifying its consistency to

the already integrated metamodels (“easy”). Remo-

ving an integrated metamodel works vice versa. Reu-

sing subsets of a SUMM (i.e., a subset of the used

metamodels) is easy, since selected parts of metamo-

dels along with their consistency preservation rules

can simply be reused. MOCONSEMI makes it easy

to add new metamodels by deﬁning a new operator

chain that starts with the current SUMM and reuses

all existing operators. Removing an already integra-

ted metamodel requires all operators between the me-

tamodel in question and the SUMM to be removed

Single Underlying Models for Projectional, Multi-View Environments

125

or ﬁxed (“middle”). Generally, pragmatic approaches

(C2) allow to easily add or remove metamodels, since

these operations are performed on the level of the me-

tamodel as a whole. Additionally, they tend to lead

to SUMMs that reﬂect the structure of the original

metamodels, making them easier to remove later. On

the other hand, essential approaches can easily ﬁne-

tune metamodels to the needs of the project, since the

SUMM can be manipulated at the level of individual

model elements. However, the absence of dependen-

cies intertwines information and makes the bounda-

ries between the different metamodels less clear.

The application of the classiﬁcation criteria to the

three approaches has shown that all criteria distin-

guish different properties of SUM approaches, be-

cause none of the criteria is fulﬁlled by all approaches

in the same way. Nevertheless, correlations between

the reusability of metamodels and models, as well as

between the evolution of languages and the reusabi-

lity of SUMM can be seen, as they all arise from the

same conceptual criteria regarding pureness and con-

struction process. From this application of the crite-

ria, it cannot be said that the list of criteria is complete

and especially it is unclear whether those presented

criteria are the most relevant for selecting an appro-

priate SUM approach. Nevertheless, we have argued

that all these criteria are relevant for certain situati-

ons (e.g., whether metamodels shall be reused or not,

whether languages can be expected to evolve), which

gives an initial indicator for the appropriateness of the

criteria.

8 GUIDELINE FOR APPROACH

SELECTION

We deﬁned criteria for selecting a SUM appro-

ach that is most suitable for a speciﬁc situation in

Section 3.2, which are derived from the design criteria

in Section 3.1. Since the three presented approaches

fulﬁll these selection criteria differently, each ﬁts well

for different situations as discussed in the following as

third contribution of this paper.

If there are no legacy tools or metamodels descri-

bing the system under development to be reused (E1

and E2), the OSM approach is the most suitable. As

there is no pressure to reuse existing metamodels, mo-

dels or tools, deﬁning a new metamodel that is free

of implicit dependencies provides the purest solution

for describing the system. This makes it most easy to

deﬁne new viewtypes for speciﬁc roles (E3). The ap-

proach is also the most attractive when dependencies

to external tool vendors should be avoided.

If, on the other hand, existing metamodels and

tooling are available for reuse, the top-down OSM

approach is less suitable in contrast to bottom-up ap-

proaches (C1) like VITRUVIUS and MOCONSEMI,

because they preserve existing viewtypes, compatibi-

lity to existing tooling and potentially complete deve-

lopment environments including all instances. More-

over, they achieve this without the need to remodel all

dependency-free information and without the corre-

sponding loss of compatibility to existing viewtypes

and tooling. VITRUVIUS is the most suitable appro-

ach if there are no existing models to be integrated

for reuse, because it provides the highest reusability

of SUMMs (E5) and the best support for evolution

(E4), since the initial (meta)models are contained in

the SUM(M) as separated artifacts. This also allows

the modular speciﬁcation of CPRs by domain experts,

their reuse across projects, and the project-speciﬁc se-

lection of used metamodels and CPRs.

However, VITRUVIUS is less suitable than MO-

CONSEMI when existing models need to be reused,

for example, in a re-engineering case, as it requires

the reused models to be consistent according to the

consistency rules (E2). When models do not follow

these consistency rules, which is especially the case

when they are less obvious than those between Java

and UML, they have to be adapted initially. The MO-

CONSEMI approach is most suitable in this case, be-

cause it is able to handle inconsistencies in the exis-

ting models and resolves them during integration.

Summarizing, if the reuse of existing tools and

metamodels is not required, creating an essential

SUM(M), as in OSM, is the most suitable solution.

If metamodels are to be reused, pragmatic approaches

are more suitable. Depending on whether existing in-

stances shall be reused, VITRUVIUS or a combined

approach such as MOCONSEMI should be taken. Ta-

ble 2 summarizes the main advantages and applica-

tion areas of the different approaches.

9 RELATED WORK

The explicit use of views or perspectives in software

engineering can be traced back to the VOSE method

in the early 1990s (Finkelstein et al., 1992), which

strongly advocated a synthetic approach to views gi-

ven the state-of-the-art at the time. Most “view-

based” software engineering methods that have emer-

ged since then, such as by Kruchten (1995) or the

Uniﬁed Process (Larman, 2004), assume that views

are supported in a synthetic way, although this is usu-

ally not stated explicitly (the actual distinction bet-

ween synthetic and projective approaches to views

was ﬁrst clearly articulated in the ISO 42010 stan-

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

126

Table 2: Main Advantages and Disadvantages of the three Approaches with Exemplary Application Areas.

dard (ISO/IEC/IEEE, 2011)). To our knowledge, no

general purpose software engineering method availa-

ble today is based exclusively on the notion of pro-

jective views driven by a SUM. However, there are

approaches that address the more speciﬁc problem of

keeping multiple views on a database consistent (Da-

yal and Bernstein, 1982), or that support a synthetic

approach to modeling in a limited context like multi-

paradigm modeling (Vangheluwe et al., 2002).

The discipline in which the idea of using views to

provide different perspectives on large, complex sy-

stems is the most mature is Enterprise Architecture

(EA) modeling, characterized by approaches such

as Zachman (Zachman, 1987) and TOGAF (Haren,

2011). These all deﬁne some kind of “viewpoint fra-

mework” deﬁning the constellation of views available

to stakeholders and the kind of “models” that should

be used to portray them. Some of these, like RM-ODP

(Linington et al., 2011), adopt an explicitly synthe-

tic approach, while others such as ArchiMate (Iacob

et al., 2012) and MEMO (Frank, 2002) make no com-

mitment. However, again no EA modeling platform

available today explicitly advocates, or is oriented to-

wards the use of projective views.

Therefore, the criteria presented in this paper help

to design and select appropriate SUM construction

approaches. Additionally, the three sketched SUM

approaches under development show the feasibility of

projectional, multi-view environments.

10 CONCLUSION

Ensuring holistic consistency in system development

is a growing challenge as systems become larger and

more complex. In this paper, we introduced a uni-

fying terminology and developed criteria for classi-

fying approaches that allow to construct single under-

lying models (SUMs) as solutions to that consistency

problem. Based on those criteria, we identiﬁed the

main conceptual differences between possible solu-

tions, which are the construction process to build a

SUM and its metamodel, and their pureness, i.e., the

absence of redundancy. We derived ﬁve selection cri-

teria, which help to select an appropriate approach

for a speciﬁc situation, depending on the necessity to

reuse existing metamodels and models, the expected

evolution of integrated languages, the need for deﬁ-

ning new viewtypes, as well as the required reusabi-

lity.

We presented three existing approaches, which are

OSM, VITRUVIUS and MOCONSEMI, which cover

the conceptual solution space for SUM approaches

spanned by the criteria construction process and pu-

reness. On the one hand, OSM creates a pure SUM

in a top-down way, while on the other hand, VITRU-

VIUS leads to a pragmatic SUM by bottom-up reuse

of existing (meta)models explicitly keeping depen-

dent information consistent. Between these two ends

of the spectrum, MOCONSEMI operates in a bottom-

up way like VITRUVIUS, but removes redundant in-

formation leading to an improved, possibly essential

SUM. There is no known top-down approach that uses

pragmatic SUMs. By applying the identiﬁed crite-

ria to these different approaches, we were able to give

a reasonable indicator for the appropriateness of those

criteria, as they are distinguishing for the approaches.

OSM especially replaced the paradigm of reﬁne-

ment of models by model transformation chains by

the new paradigm to project models only as views on

the complete interconnected information of the whole

system. It is the initiator for the idea of constructing

SUM that are only deﬁned via projectional views.

Based on that idea, VITRUVIUS and MOCONSEMI

contribute concrete pragmatic strategies for building

SUMs according to this paradigm.

An interesting possibility is to combine the appro-

aches by nesting SUMs developed with different ap-

proaches, so that one SUM contains other SUMs by

using their provided viewtypes. This, for example,

would allow an essential SUM deﬁned for a speciﬁc

concern of a system to be combined with existing me-

tamodels in a pragmatic SUM using VITRUVIUS or

MOCONSEMI. Finally, it also offers the construction

of pragmatic SUMs, which can easily become com-

plex when they contain lots of metamodels, to be hier-

Single Underlying Models for Projectional, Multi-View Environments

127

archically decomposed (i.e. nested).

As future work, we plan to deﬁne a community

case study that describes metamodels, models, and

consistency rules in the application area of software

development. Its realization by the three approaches

will help to evaluate, compare and improve the appro-

aches, their technical realizations and provided tool-

ing using technical criteria to be proposed.

These criteria and derived evaluations of the three

SUM approaches are developed by three groups of

SUM researchers. This paper results from that col-

laboration including discussions from three internal

workshops and will be continued with developing the

community case study and its application to all three

SUM approaches for evaluation in practice.

REFERENCES

Atkinson, C. (2002). Component-based Product Line En-

gineering with UML. Addison-Wesley object techno-

logy series. Addison-Wesley.

Atkinson, C., Stoll, D., and Bostan, P. (2010). Ort-

hographic Software Modeling: A Practical Appro-

ach to View-Based Development. In Maciaszek, L.,

Gonz

alez-P

erez, C., and Jablonski, S., editors, Eva-

luation of Novel Approaches to Software Engineer-

ing, volume 69 of Communications in Computer and

Information Science, pages 206–219. Springer, Ber-

lin/Heidelberg.

Atkinson, C., Tunjic, C., and Moller, T. (2015). Fundamen-

tal Realization Strategies for Multi-View Speciﬁcation

Environments. In 19th International Enterprise Dis-

tributed Object Computing Conference, volume 2015-

Nov, pages 40–49. IEEE.

Burger, E., Henß, J., K

uster, M., Kruse, S., and Happe, L.

(2014). View-Based Model-Driven Software Deve-

lopment with ModelJoin. Software & Systems Mo-

deling, 15(2):472–496.

Codd, E., Codd, S., and Salley, C. (1993). Providing OLAP

(On-line Analytical Processing) to User-Analysts: An

IT Mandate. Codd & Associates.

Dayal, U. and Bernstein, P. A. (1982). On the updatability

of network views—extending relational view theory

to the network model. Information Systems, 7(1):29 –

46.

Diskin, Z., Xiong, Y., Czarnecki, K., Ehrig, H., Hermann,

F., and Orejas, F. (2011). From state- to delta-based

bidirectional model transformations: The symmetric

case. Model Driven Engineering Languages and Sys-

tems, LNCS 6981:304–318.

Finkelstein, A., Kramer, J., Nuseibeh, B., Finkelstein, L.,

and Goedicke, M. (1992). Viewpoints: A framework

for integrating multiple perspectives in system deve-

lopment. International Journal of Software Engineer-

ing and Knowledge Engineering, 2(1):31–57.

Frank, U. (2002). Multi-perspective Enterprise Modeling

(MEMO) – Conceptual Framework and Modeling

Languages. In Hawaii International Conference on

System Sciences (HICSS), pages 72–81.

Haren, V. (2011). TOGAF Version 9.1. Van Haren Publis-

hing, 10th edition.

Herrmannsdoerfer, M. (2010). COPE - A workbench for the

coupled evolution of metamodels and models. Lecture

Notes in Computer Science, 6563:286–295.

Herrmannsdoerfer, M., Vermolen, S. D., and Wachsmuth,

G. (2011). An Extensive Catalog of Operators for the

Coupled Evolution of Metamodels and Models. SLE,

LNCS 6563:163–182.

Iacob, M., Jonkers, D. H., Lankhorst, M., Proper, E., and

Quartel, D. D. (2012). Archimate 2.0 speciﬁcation:

The open group.

ISO/IEC/IEEE (2011). ISO/IEC/IEEE 42010:2011(E): Sys-

tems and software engineering – Architecture descrip-

tion. International Organization for Standardization,

Geneva, Switzerland.

Kramer, M. E. (2017). Speciﬁcation Languages for Pre-

serving Consistency between Models of Different Lan-

guages. PhD thesis, Karlsruhe Institute of Technology

(KIT), Karlsruhe, Germany.

Kramer, M. E., Burger, E., and Langhammer, M. (2013).

View-centric engineering with synchronized hetero-

geneous models. In Proceedings of the 1st Workshop

on View-Based, Aspect-Oriented and Orthographic

Software Modelling, VAO ’13, pages 5:1–5:6, New

York, NY, USA. ACM.

Kramer, M. E., Langhammer, M., Messinger, D., Seifer-

mann, S., and Burger, E. (2015). Change-driven con-

sistency for component code, architectural models,

and contracts. In Proceedings of the 18th Internatio-

nal ACM SIGSOFT Symposium on Component-Based

Software Engineering, CBSE ’15, pages 21–26, New

York, NY, USA. ACM.

Larman, C. (2004). Applying UML and Patterns: An Intro-

duction to Object-Oriented Analysis and Design and

Iterative Development (3rd Edition). Prentice Hall,

Upper Saddle River, NJ, USA, 3rd edition.

Linington, P. F., Milosvic, Z., Tanaka, A., and Vallecillo,

A. (2011). Building Enterprise Systems with ODP.

Chapman and Hall, NY, USA.

Meier, J. and Winter, A. (2018). Model Consistency en-

sured by Metamodel Integration. 6th International

Workshop on The Globalization of Modeling Langua-

ges, co-located with MODELS 2018.

Tunjic, C., Atkinson, C., and Draheim, D. (2018). Suppor-

ting the Model-Driven Organization Vision through

Deep, Orthographic Modeling. Enterprise Modelling

and Information Systems Architectures-an Internatio-

nal Journal, 13(SI):1–39.

Vangheluwe, H., de Lara, J., and Mosterman, P. J. (2002).

An introduction to multi-paradigm modelling and si-

mulation. In Barros, F. and Giambiasi, N., editors,

Proceedings of the AIS’2002 Conference, pages 9–20.

Zachman, J. A. (1987). A framework for information sys-

tems architecture. IBM Systems Journal, 26(3):276–

292.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

128