Conference PaperPDF Available

Single Underlying Models for Projectional, Multi-View Environments



Content may be subject to copyright.
Single Underlying Models for Projectional, Multi-View Environments
Johannes Meier1, Heiko Klare2, Christian Tunjic3
Colin Atkinson3, Erik Burger2, Ralf Reussner2, Andreas Winter1
1Software Engineering Group, University of Oldenburg, Germany
2Software Design and Quality Group, Karlsruhe Institute of Technology, Germany
3Software Engineering Group, University of Mannheim, Germany
1{meier,winter}, 2{klare,burger,reussner}, 3{tunjic,atkinson}
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 archetyp-
ical approaches for building SUMs, and analyzes their advantages and disadvantages. From these criteria,
guidelines for choosing which approach to use in specific 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 difficult
and time consuming to manage manually. Automated
approaches for ensuring the holistic consistency of
multi-view system descriptions are therefore needed.
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 in-
dividual views, whereas in projective approaches,
the description is contained in a Single Underlying
Model (SUM) (Atkinson et al., 2010), and views are
projected from this central store of information as
needed. 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 differ-
ent strategies for supporting projective approaches
to view-based software engineering and to highlight
their pros and cons. The common underlying prop-
erty of all projective approaches is that views are
considered to be correct by construction and thus in-
herently consistent with each other as long as they
are consistent with the SUM. The problem of main-
taining inter-view consistency therefore becomes the
problem of maintaining the internal consistency of
the SUM and the correctness of SUM-to-view pro-
jections. To describe the different approaches in a
uniform way and analyze their pros and cons system-
atically, this paper classifies the different fundamen-
tal strategies for constructing SUMs and their corre-
sponding SUMMs, and identifies criteria for evaluat-
ing them. More specifically, three existing approaches
for constructing SUM(M)s are compared in terms of
how they fulfill the identified criteria. Finally, we
analyze how the fulfillment of the identified criteria
by the different approaches affects their suitability for
specific situations.
The insights presented in this paper will allow
researchers to classify new approaches for SUM(M)
constructions and help developers to choose projec-
tional view-based approaches for their specific project
situations using the identified selection criteria.
After introducing a running example and termi-
nology used in this paper in Section 2, classifica-
tion criteria for SUM approaches are described in
Section 3. The three SUM approaches OSM (Sec-
tion 4), VIT RUV IU S (Section 5), and M OCON SE MI
(Section 6) are presented subsequently and are clas-
sified using the criteria in Section 7. From this clas-
sification, guidelines for deciding which approach to
choose when are derived in Section 8. After dis-
cussing related work in Section 9, Section 10 sum-
marizes the findings 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 simplified running example describing the re-
quirements, architecture and implementation of a sys-
tem. These three views are expressed in languages
based on metamodels that define the elements (e.g.,
classes, attributes etc.) that can appear in models. We
depict those metamodels in Figure 1. This section
also clarifies the terminology used in this paper.
Requirements are represented by natural language
sentences (package Req). Each Requirement within
aRequirementsSpecification is identified by a
unique id, which contains the requirement’s sentence
as simple text, and is written by an author.
The architecture is described by simplified 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 devel-
oped in simplified Java (package Java). The JavaASG
contains ClassTypes, which in turn contain Methods
with their caller/callee relations.
These three languages describe different (not nec-
essarily 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 specific 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 defined in consistency
rules, which define the relations that have to hold be-
tween instances of metamodels.
We define 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 consider
these consistency rules representative, since integrat-
ing different views usually refers to merging concepts
or introducing additional associations.
Consistency Rule 1: Classes can be defined in
the architecture view and in the implementation view:
One concrete class can be defined either only in the
implementation (Java.ClassType), or in both im-
plementation and the architecture (UML.Class) if it
represents a module. In the latter case, this class has
to be kept consistent in the implementation and ar-
chitecture, e.g., in the case of renaming this class.
Therefore, the implementation and architecture are
only consistent if the architecture contains a subset
of the classes in the implementation.
Consistency Rule 2: Since requirements define
goals that the implementation should fulfill, the de-
velopment progress can be measured by counting the
requirements that are supported by the current imple-
mentation. Therefore, Requirements must be linked
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 simplified example for
this paper, different rules can be specified instead.
These two consistency rules and three languages
are used to motivate criteria for SUM approaches in
Section 3. SUM approaches define 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 define 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 metamod-
id : EString [0..1]
author : EString [0..1]
text : EString [0..1]
name : EString [1]
name : EString [1]
className : EString [1]
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
Figure 1: Simplified Metamodels for Requirements (left), Class Diagrams (middle), and Java Source Code (right)
els in Figure 1 or defines a new metamodel for the
described concepts. After that, the developer instan-
tiates that SUMM defined 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 specific concerns of the developer.
3 Classification Criteria
In this section, we identify two groups of crite-
ria 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 first contribution of this paper. By
applying them to different SUM approaches, we eval-
uate 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 distinguish-
ing. In other words, the fulfillment 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 start-
ing 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 define 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 specific situation. These criteria help
methodologists to compare different SUM approaches
for the same application scenario. For example, if ex-
isting metamodels need to be reused, it is best to select
and apply a SUM approach that simplifies the reuse of
existing metamodels. The fulfillment of those criteria
by a specific SUM approach is affected by the alloca-
tion of design criteria for that approach.
Criterion E1 (Metamodel Reusability) deter-
mines whether concepts to be represented in the
SUMM are already available within predefined meta-
models and should be reused in the new SUMM. If
so, the SUM approach has to accommodate these
legacy metamodels by combining them into an ini-
tial SUMM. This can either be done directly with-
out additional work or indirectly by providing strate-
gies for migrating the legacy metamodels into the
SUMM. Since lots of languages, metamodels and
tools with fixed viewtypes are usually already avail-
able, approaches fulfilling this criterion support their
reuse. Reusing metamodels usually implies a bottom-
up approach according 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 migrat-
ing 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 inte-
grated into the SUM. This requires additional manual
effort to ensure consistency beforehand, in contrast
to SUM approaches which offer strategies to han-
dle inconsistent information during their integration
into the SUM. Existing artifacts developed without a
consistency-preserving SUM approach usually do not
initially fulfill the consistency relations, which is why
this criterion also checks whether those inconsisten-
cies can be handled automatically during integration.
Criterion E3 (Viewtype Definability) focuses
on the task of specifying new types of views on a
SUMM. This involves the creation of new viewtype
definitions, focused on specific concerns (e.g., man-
aging the traceability links from Consistency Rule 2)
whose instances can be used by developers to change
the related information in the SUM. Supporting the
definition of customized, role-specific viewtypes is
an essential capability of view-based development ap-
proaches, so the level of difficulty 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 meta-
models, changed consistency rules, and the integra-
tion of new viewtypes. Changes in the metamodel
can require corresponding changes in the model (i.e.,
model co-evolution (Herrmannsdoerfer et al., 2011))
as well as the creation or adaptation of consistency
rules. Since languages are subject to change (e.g.,
new version of Java are regularly introduced) the dif-
ficulty of updating the SUMM and its instances after
evolution of the integration languages is a relevant cri-
terion, 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 inte-
grated 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 already existing SUMM. Although this criterion
does not target reuse at the model level, it is important
since, for example, there are many software develop-
ment projects that use slightly different languages or
consistency 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).
name : EString [1]
lowerBound : EInt [0..1]
upperBound : EInt [0..1]
name : EString [1]
name : EString [1]
id : EString [0..1]
author : EString [0..1]
text : EString [0..1]
fullfills []
fulfilledBy []
class [1]
methods []
class [1]
classUseClass []
type [1]
usedBy []
calling []calledBy []
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 define “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-
specific notation. Although stakeholders can only see
and manipulate the system via views, the actual de-
scription of the system is stored in a SUM. The views
are defined to be as “orthogonal” as possible through
independent dimensions (i.e., concerns) ranging from
behavioral properties and feature specifications to ar-
chitectural composition. Ultimately, the system de-
scription in the SUM can be made formal enough to
be automatically deployed and executed on appropri-
ate platforms, thus allowing automatic redeployment
when changes occur. In order to support the complete
life-cycle of a system, ranging from requirements
analysis to deployment, the internal structure 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 capture all relation-
ships between its inner elements in a redundancy-free
way using approaches like Information Compression
and Information Expansion (Atkinson 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 define
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 at-
tributes are therefore mapped to the single attribute
name in the SUMM. The two dependencies are dis-
tinct, however, and are hence both added to the Class
element: The first enables Classes to have Methods,
while the second describes dependencies between two
Class elements (Consistency Rule 1).
Consistency Rule 2 is modelled through a re-
lationship between Requirement and Method, de-
noting that the requirement is being fulfilled by the
method. In order to allow developers to create in-
stances of the relationship, a new view can be defined,
which at least 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 unified names for
dependent concepts (ClassType vs. Class) and us-
age of names with more meaning (Association vs.
ClassUseClass). Although the SUMM is built from
scratch in the presented example, in principle it is pos-
sible to import existing artifacts into the environment
using model-to-model transformations.
4.2 Process of Application
In order to make use of OS M, an environment has
to be developed which realizes its goals and princi-
ples. Both steps, i.e., the definition 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 customized
for the used methodology (e.g., KobrA (Atkinson,
2002), MEMO (Frank, 2002), ArchiMate (Iacob et
al., 2012)) and targeted domain (e.g., software engi-
neering, enterprise architecture modeling). The dif-
ferent configurations 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 cur-
rent prototype implementation to support the config-
uration of OSM environments. In particular, it facil-
ities the configuration of the SUMM and viewtypes,
and their integration in a dimension-based view nav-
igation approach using hyper-cubes of the kind used
in OLAP (Codd et al., 1993) systems.
The customization of the environment for a spe-
cific domain and methodology is performed by a soft-
ware engineer playing the role of a methodologist. In
order to be able to configure and customize the envi-
ronment according to the requirements, the method-
ologist must have knowledge of the involved domain
and the OSM environment. In particular, he is respon-
sible for defining the SUMM and the viewtypes in
a way that adheres to the principles of redundancy-
freeness and minimality. Defining a viewtype in-
volves the definition 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 configuration can be stored in the tooling en-
vironment in order to be reused in other projects.
Once a complete configuration of an OSM en-
vironment has been defined by the methodologist,
one or more developers can use it to develop a spe-
cific system specification. 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 arti-
facts. When using the OSM platform to develop a
system, developers are able to access views using the
dimension-based view navigation approach and use
them to see and update information from the SUM.
The VI TRU VI US approach (Kramer et al., 2013)
assumes 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
pragmatic SUMM in a bottom-up fashion.
5.1 Main Ideas
The VI TRU VI US approach is based on the projec-
tional SUM idea of the OSM approach. The whole
system description is encapsulated in a SUM and
only projectional views can be used to modify in-
formation in the SUM. Instead of creating a com-
pletely new SUMM without dependent information,
however, VI TRUVIUS follows a pragmatic approach
by coupling existing metamodels using consistency
preservation rules (CPRs), which define how consis-
tency is preserved after modifications. The CPRs use
and modify correspondences, which reference model
elements that represent dependent information and
can be seen as a trace model. The set of metamodels
with their CPRs defines 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 modifications in one model, all other
dependent models are updated consistently. As a con-
sequence, a V-SUM behaves completely like an ordi-
nary SUM since it provides the same guarantees re-
garding information consistency.
MM metamodel
VT viewtype
view trans-
Figure 3: Example V-SUMM in VITRUVIUS
An exemplary V-SUMM for the metamodels from
Figure 1 is depicted in Figure 3. It consists of the
reused metamodels with CPRs defined between them.
For Consistency Rule 1, a CPR defines the creation
of a Java class ClassType in reaction to the creation
of a UML class Class. It is up to the methodolo-
gist to specify the behavior in the other direction, i.e.,
whether 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 require-
ments traces in Consistency Rule 2 can be expressed
by identifying matching requirements and methods
after adding or modifying methods as well as require-
ments, and by storing them as appropriate correspon-
dences in the existing trace model. Alternatively it
is possible to define an additional metamodel that de-
fines links between requirements and methods, which
is modified whenever they are changed.
Two types of projectional viewtypes can be de-
fined on a V-SUMM. First, the original viewtypes de-
fined 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 T1,V T2and
V T3, which represent the original metamodels from
Figure 1. Second, it is also possible to define addi-
tional viewtypes that may combine information from
different metamodels and their relations defined in
the CPRs. Figure 3 contains V T4, which displays the
trace information for Consistency Rule 2 by extract-
ing information from the Java and the requirements
model, as well as from the correspondences generated
by the CPR. Concretely, this viewtype could, for ex-
ample, show the Java code with annotations attached
to the methods that show the requirements they ful-
fill. Nevertheless, for defining such viewtypes, spe-
cialized languages that support the projection from,
and combination of, different metamodels is required.
In VI TRU VI US , those can be expressed with the Mod-
elJoin language (Burger et al., 2014).
Consistency preservation in VITRU VI US is per-
formed 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 re-
naming only using heuristics, whereas delta-based ap-
proaches track the correct operations. To define such
delta-based consistency preservation, specific consis-
tency preservation languages have been developed
(Kramer, 2017). Initial investigations into consis-
tency preservation in VITRU VI US 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 V IT RUVIUS
first involves a platform specialist who defines an ab-
straction representing the interface of a V-SUM, im-
plements the logic for executing CPRs and defines or
selects specific languages or at least an interface to
define CPRs. The current implementation of the VI T-
RUV IU S approach ( uses Ecore and
contains a Java-based definition of V-SUMs and pro-
vides two languages for defining consistency preser-
vation on different abstraction levels.
The methodologist then selects a set of metamod-
els and defines or reuses existing CPRs for the se-
lected metamodel to define a V-SUMM of these ar-
tifacts. Finally, the developer can instantiate the
V-SUMM, derive views according to existing or
newly defined viewtypes, and perform modifications
of them. Modifications in a view are recorded as
sequences of atomic change events (creation, dele-
tion, insertion, removal and replacement) and then se-
quentially applied to the V-SUM. For each of these
changes, the responsible CPRs are executed to restore
consistency after each modification, which results in
an inductively consistent V-SUM.
MOCON SE MI (MOdel CONSistency Ensured by
Metamodel Integration, (Meier & 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.
Requirements 1
Add As-
2x 6
Merge Classes SUM(M)
Merge At-
Figure 4: Chain of Configured Operators for Integrating Textual Requirements, Class Diagrams, and Java into a SUM(M)
6.1 Main Ideas
MOCON SE MI is a SUM approach which starts with
existing initial models and conforming metamod-
els (exemplarily shown in Figure 1) and creates a
SUM(M) as suggested by Atkinson et al. (2010). In
practice, many models and metamodels already exist
in form of DSLs and tools with fixed data schemas.
To reuse them even in integrated form, these initial
models and metamodels are reused for the integration
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) result-
ing 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. Start-
ing with the initial model and metamodel representing
Requirements , the initial (meta)models for Java and
ClassDiagrams are included technically at 1and
3, which require ProjectData and its compositions
as container without any contentwise integration.
The first operator AddAssociation is used to ful-
fill Consistency Rule 2. To enable the desired trace-
ability links between requirements and methods, a
new association between Requirement and Method
is required 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 deci-
sion to control this model change. This ensures that a
method is linked with those requirements that contain
the name of the method in their requirements text.
Consistency Rule 1 is realized in MergeClasses
56after the operator ChangeMultiplicity is
applied twice 5as preparation, because the two
classes 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 supported
by the model decision that the same instances are
identified by same values for Class.className and specified 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
changes on the current metamodel (e.g., adds a new
association) controlled by metamodel decisions (e.g.,
multiplicities, source and target class of the new asso-
ciation). The operator also changes the current model
to keep it consistent to the changed metamodel for
model co-evolution (Herrmannsdoerfer et al., 2011).
Degrees of freedom of this change are influenced by
model decisions, which allow consistency rules to
be fulfilled (e.g., specify, when new links should be
added). Result is one valid intermediate model con-
forming 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 re-
quires operators to be executed backwards. There-
fore, each operator is combined with an inverse opera-
tor, 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
id : EString [0..1]
author : EString [0..1]
text : EString [0..1]
name : EString [1]
name : EString [1]
name : EString [1]
lowerBound : EInt [0..1]
upperBound : EInt [0..1]
container [1]
content []
asg [0..1]
classes []
class [1]
methods []
calledBy []calling []
containsRequirementsSpecification []
integrator [0..1]
containsJavaASG []
integrator [0..1]
fulfilled []
fulfilledBy []
integrator [0..1]
containsClassDiagram []
classes []
diagram [0..1]
class [1]
associations []
type [1]
usedBy []
Figure 5: SUMM with Integrated Textual Requirements, Class Diagrams and Java
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 first 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 devel-
oped 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 op-
erators like in Figure 4 individually for each project
by reusing the provided operators and configuring
them regarding the specific consistency rules. Addi-
tionally, the operators can be used to define 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-
fined views. These changes are propagated automat-
ically 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 classifies the three presented SUM
approaches regarding the criteria presented in Sec-
tion 3 as second contribution of this paper. The clas-
sification serves both as a comparison of the three ap-
proaches, as well as an indicator of the appropriate-
ness of the developed criteria to distinguish SUM ap-
proaches. Table 1 summarizes the classification.
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. VI TRU -
VI US and MOCON SE MI, on the other hand, operate
bottom-up, because they are able to reuse initial mod-
els and metamodels. While VIT RUV IU S keeps them
unchanged inside the modular SUM(M), MOCO N-
SE MI transforms them into an essential SUM(M).
All approaches can lead to either an essential or
pragmatic SUM(M) in terms of C2. O SM is designed
to have an essential SUM(M) without any internal de-
pendencies. VI TRU VI US is designed to use a prag-
matic SUM(M), since it incorporates all initial models
with overlapping and, in general, dependent informa-
tion. MOCO NS EMI 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 oper-
ator 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 gen-
erate 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. MOCO NS EMI sup-
ports this feature by using the initial metamodels
as the starting point for the subsequent transforma-
tions into a purer SUMM (“easy”). In general, only
bottom-up approaches (C1) can easily fulfill E1, be-
cause in top-down approaches a new metamodel has
to be defined, which hampers metamodel reuse.
Model Reusability (E2) requires preexisting
models to be incorporated into the initial SUM. OS M
supports this feature in a semi-automatic way (“hard”)
by importing data from existing models into the newly
constructed SUM using model transformations. Al-
though models do not need to be initially consis-
tent, the transformations have to be defined 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 mod-
els to be consistent according to the consistency rules
between the metamodels. This can require high man-
ual effort for the initial integration. MOCONSEMI
supports this feature by using the initial models as the
starting point for subsequent transformations that cre-
ate a purer SUM (“easy”). Even if models are not
consistent before, the application of operators to inte-
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 Definability easy hard middle
E4 Language Evolvability middle easy middle
E5 SUMM Reusability middle easy middle
Table 1: Comparison of the three Approaches regarding Design Criteria and Selection Criteria
grate the models can handle and fix inconsistencies.
In general, only bottom-up approaches (C1) can eas-
ily fulfill E2, but the effort for reuse highly depends
on the necessity to have initially consistent models.
Viewtype Definability (E3) deals with the speci-
fication of new viewtypes for the SUMM by method-
ologists. OSM eases viewtype definition (“easy”),
because it provides an essential SUMM containing
all concepts in an integrated, redundancy-free way.
VIT RUV IU S makes viewtype definition more difficult
(“hard”), because information is spread across meta-
models and has to be combined referring to the de-
fined consistency relations or using specialized lan-
guages. MOCO NS EMI eases viewtype definition in
contrast to VITRUVIUS, but requires slightly more ef-
fort than OS M, 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 influenced 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 maintain-
ing the SUMM in the face of changes to the integrated
metamodel elements or the consistency rules. OSM
simplifies SUMM evolution, since it is free of redun-
dant information, but has to check that the changes
keep the SUMM essential. However, the transfor-
mations that generate views to the SUM have to be
updated manually to stay up-to-date with SUMM
changes (“middle”). VITRUVIUS simplifies meta-
model evolution, since the initial metamodels are
kept unchanged as sub-parts of the modular SUMM.
Therefore, metamodels can evolve directly (“easy”).
Additionally, the consistency preservation rules tar-
geting the changed metamodel have to be checked
and fixed if required, as well as the defined viewtypes
which depend on the effected metamodels. M OCON -
SE MI 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 oper-
ators, the existing operator chain must only be ex-
tended by them. The same applies for changed con-
sistency rules. In all other cases, some of the existing
operators have to be changed. In general, metamodel
evolution is easier to realize in pragmatic approaches
(C2), since the SUMM is constructed out of exist-
ing metamodels, leading 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 conceptually. Thus, changes in ex-
isting languages must be manually transferred to the
SUMM ensuring its redundancy-freeness and mini-
mality, 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”). VIT RUVIUS 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”). Re-
moving an integrated metamodel works vice versa.
Reusing subsets of a SUMM (i.e., a subset of the used
metamodels) is easy, since selected parts of metamod-
els along with their consistency preservation rules
can simply be reused. MOCO NS EMI makes it easy
to add new metamodels by defining a new operator
chain that starts with the current SUMM and reuses all
existing operators. Removing an already integrated
metamodel requires all operators between the meta-
model in question and the SUMM to be removed or
fixed (“middle”). Generally, pragmatic approaches
(C2) allow to easily add or remove metamodels, since
these operations are performed on the level of the
metamodel as a whole. Additionally, they tend to lead
to SUMMs that reflect the structure of the original
metamodels, making them easier to remove later. On
the other hand, essential approaches can easily fine-
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 bound-
aries between the different metamodels less clear.
The application of the classification criteria to the
three approaches has shown that all criteria distin-
guish different properties of SUM approaches, be-
cause none of the criteria is fulfilled 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 reusability
of SUMM can be seen, as they all arise from the same
conceptual criteria regarding pureness and construc-
tion process. From this application of the criteria, it
cannot be said that the list of criteria is complete and
especially it is unclear whether those presented crite-
ria are the most relevant for selecting an appropriate
SUM approach. Nevertheless, we have argued that all
these criteria are relevant for certain situations (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 defined criteria for selecting a SUM approach
that is most suitable for a specific situation in Sec-
tion 3.2, which are derived from the design criteria in
Section 3.1. Since the three presented approaches ful-
fill these selection criteria differently, each fits well
for different situations as discussed in the following
as third contribution of this paper.
If there are no legacy tools or metamodels de-
scribing the system under development to be reused
(E1 and E2), the OS M approach is the most suitable.
As there is no pressure to reuse existing metamodels,
models or tools, defining a new metamodel that is free
of implicit dependencies provides the purest solution
for describing the system. This makes it most easy to
define new viewtypes for specific 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 VI TRUVIUS and MOCO NS EMI,
because they preserve existing viewtypes, compatibil-
ity to existing tooling and potentially complete devel-
opment 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 ap-
proach 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 specification of CPRs by domain experts,
their reuse across projects, and the project-specific se-
lection of used metamodels and CPRs.
However, VI TRUVIUS is less suitable than MO-
CON SE MI 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-
CON SE MI approach is most suitable in this case, be-
cause it is able to handle inconsistencies in the exist-
ing 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 OS M, 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, VIT RUVIUS 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 soft-
ware 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 given the state-of-the-art at the time. Most
“view-based” software engineering methods that have
emerged since then, such as by Kruchten (1995) or the
Unified Process (Larman, 2004), assume that views
are supported in a synthetic way, although this is usu-
ally not stated explicitly (the actual distinction be-
tween synthetic and projective approaches to views
was first clearly articulated in the ISO 42010 stan-
dard (ISO/IEC/IEEE, 2011)). To our knowledge, no
general purpose software engineering method avail-
Advantages Easy Viewtype Definition
No Dependencies to Legacy Tools
Reuse of Metamodels / Tools
Modular Views
Reuse of Metamodels / Tools
Easy Integration of Models
Disadvantages No Support for Existing Artifacts Difficult Reuse of Models No Modularity
No Reuse of (Meta-)Models
New Domain Description Language
Reuse of Metamodels
Combination of Existing
Standards for new Projects
Reuse of (Meta-)Models
Software Re-Engineering
Table 2: Main Advantages and Disadvantages of the three Approaches with Exemplary Application Areas
able today is based exclusively on the notion of pro-
jective views driven by a SUM. However, there are
approaches that address the more specific problem
of keeping multiple views on a database consistent
(Dayal & 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
systems is the most mature is Enterprise Architecture
(EA) modeling, characterized by approaches such
as Zachman (Zachman, 1987) and TOGAF (Haren,
2011). These all define some kind of “viewpoint
framework” defining the constellation of views avail-
able 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 explic-
itly synthetic approach, while others such as Archi-
Mate (Iacob et al., 2012) and MEMO (Frank, 2002)
make no commitment. However, again no EA mod-
eling platform available today explicitly advocates, or
is oriented towards 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 develop-
ment is a growing challenge as systems become larger
and more complex. In this paper, we introduced a
unifying terminology and developed criteria for clas-
sifying approaches that allow to construct single un-
derlying models (SUMs) as solutions to that consis-
tency problem. Based on those criteria, we identified
the main conceptual differences between possible so-
lutions, which are the construction process to build
a SUM and its metamodel, and their pureness, i.e.,
the absence of redundancy. We derived five selection
criteria, which help to select an appropriate approach
for a specific situation, depending on the necessity to
reuse existing metamodels and models, the expected
evolution of integrated languages, the need for defin-
ing new viewtypes, as well as the required reusability.
We presented three existing approaches, which are
OSM, VITRUV IU S and MOCO NS EMI, which cover
the conceptual solution space for SUM approaches
spanned by the criteria construction process and pure-
ness. On the one hand, OSM creates a pure SUM
in a top-down way, while on the other hand, VIT RU-
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 identified 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 refine-
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 construct-
ing SUM that are only defined via projectional views.
Based on that idea, VITRUVIUS and MOCON SE MI
contribute concrete pragmatic strategies for building
SUMs according to this paradigm.
An interesting possibility is to combine the ap-
proaches by nesting SUMs developed with different
approaches, so that one SUM contains other SUMs
by using their provided viewtypes. This, for exam-
ple, would allow an essential SUM defined for a spe-
cific concern of a system to be combined with existing
metamodels in a pragmatic SUM using VI TR UV IU S
or MOCO NS EMI. Finally, it also offers the construc-
tion of pragmatic SUMs, which can easily become
complex when they contain lots of metamodels, to be
hierarchically decomposed (i.e. nested).
As future work, we plan to define 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 ap-
proaches, their technical realizations and provided
tooling 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.
Atkinson, C. (2002). Component-based product line engi-
neering with uml. Addison-Wesley object technol-
ogy series. Addison-Wesley.
Atkinson, C., Stoll, D., & Bostan, P. (2010). “Ortho-
graphic Software Modeling: A Practical Approach
to View-Based Development.” In L. Maciaszek, C.
erez, & S. Jablonski (Eds.), Evaluation of
Novel Approaches to Software Engineering (Vol. 69,
pp. 206–219). Communications in Computer and In-
formation Science. Springer.
Atkinson, C., Tunjic, C., & Moller, T. (2015). Fundamen-
tal Realization Strategies for Multi-View Specifica-
tion Environments. In 19th international enterprise
distributed object computing conference (Vol. 2015-
Nov, pp. 40–49). IEEE.
Burger, E., Henß, J., K¨
uster, M., Kruse, S., & Happe, L.
(2014). “View-Based Model-Driven Software De-
velopment with ModelJoin.Software & Systems
Modeling,15(2), 472–496.
Codd, E., Codd, S., & Salley, C. (1993). Providing OLAP
(On-line Analytical Processing) to User-Analysts:
An IT Mandate. Codd & Associates.
Dayal, U. & Bernstein, P. A. (1982). “On the updatability of
network views—extending relational view theory to
the network model.” Information Systems,7(1), 29–
Diskin, Z., Xiong, Y., Czarnecki, K., Ehrig, H., Hermann,
F., & Orejas, F. (2011). “From state- to delta-based
bidirectional model transformations: The symmet-
ric case.” Model Driven Engineering Languages and
Systems,LNCS 6981, 304–318.
Finkelstein, A., Kramer, J., Nuseibeh, B., Finkelstein, L., &
Goedicke, M. (1992). “Viewpoints: A framework for
integrating multiple perspectives in system develop-
ment.” 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) (pp. 72–81).
Goldschmidt, T., Becker, S., & Burger, E. (2012). Towards
a tool-oriented taxonomy of view-based modelling.
In E. J. Sinz & A. Sch¨
urr (Eds.), Proceedings of
the modellierung 2012 (Vol. P-201, pp. 59–74). GI-
Edition – Lecture Notes in Informatics (LNI). GI e.V.
Haren, V. (2011). TOGAF version 9.1 (10th). Van Haren
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., & 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., &
Quartel, D. D. (2012). Archimate 2.0 specification:
The open group. Van Haren Publishing.
ISO/IEC/IEEE. (2011). ISO/IEC/IEEE 42010:2011(E):
Systems and software engineering – architecture de-
scription. International Organization for Standard-
ization, Geneva, Switzerland.
Kramer, M. E. (2017). Specification languages for pre-
serving consistency between models of different lan-
guages (Doctoral dissertation, Karlsruhe Institute of
Technology (KIT)).
Kramer, M. E., Burger, E., & 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 (5:1–5:6). VAO ’13. ACM.
Kramer, M. E., Langhammer, M., Messinger, D., Seifer-
mann, S., & Burger, E. (2015). Change-driven con-
sistency for component code, architectural models,
and contracts. In Proceedings of the 18th interna-
tional acm sigsoft symposium on component-based
software engineering (pp. 21–26). CBSE ’15. ACM.
Kruchten, P. B. (1995). “The 4+1 View Model of architec-
ture.” IEEE Software,12(6), 42–50.
Larman, C. (2004). Applying uml and patterns: An intro-
duction to object-oriented analysis and design and
iterative development (3rd edition) (3rd). Prentice
Linington, P. F., Milosvic, Z., Tanaka, A., & Vallecillo, A.
(2011). Building enterprise systems with odp. Chap-
man and Hall.
Meier, J. & Winter, A. (2018). “Model Consistency ensured
by Metamodel Integration.6th International Work-
shop on The Globalization of Modeling Languages,
co-located with MODELS 2018.
Tunjic, C., Atkinson, C., & Draheim, D. (2018). “Support-
ing the Model-Driven Organization Vision through
Deep, Orthographic Modeling.” Enterprise Mod-
elling and Information Systems Architectures-an In-
ternational Journal,13(SI), 1–39.
Vangheluwe, H., de Lara, J., & Mosterman, P. J. (2002). An
introduction to multi-paradigm modelling and simu-
lation. In F. Barros & N. Giambiasi (Eds.), Proceed-
ings of the AIS’2002 Conference (pp. 9–20).
Zachman, J. A. (1987). “A framework for information
systems architecture.” IBM Systems Journal,26(3),
... In the following, we demonstrate that language interleaving and the definition of consistency constraints can be easily realized in formalized conceptual modeling languages. Depending on the initial situation we can distinguish top-down approaches, where a newly defined or existing language is segmented in several sublanguages or views, and bottom-up approaches, where existing languages are interleaved and their metamodels are amalgamated and equipped with additional constraints [49]. We will discuss the first approach briefly and exemplify the second one in a case study. ...
... This means all information is captured in the model at all points in time and at the same time kept consistent due to the newly introduced constraints. This conforms to the idea of the single underlying model as proposed by Burger et al. [49]. ...
Full-text available
Enterprise modeling deals with the increasing complexity of processes and systems by operationalizing model content and by linking complementary models and languages, thus amplifying the model value beyond mere comprehensible pictures. To enable this amplification and turn models into computer-processable structures, a comprehensive formalization is needed. This paper presents the formalism MetaMorph based on typed first-order logic and provides a perspective on the potential and benefits of formalization that arise for a variety of research issues in conceptual modeling. MetaMorph defines modeling languages as formal languages with a signature $$\varSigma $$ Σ —comprising object types, relation types, and attributes through types and function symbols—and a set of constraints. Four case studies are included to show the effectiveness of this approach. Applying the MetaMorph formalism to the next level in the hierarchy of models, we create , a formal modeling language for metamodels. We show that is self-describing and therefore complete the formalization of the full four-layer metamodeling stack. On the basis of our generic formalism applicable to arbitrary modeling languages, we examine four current research topics—modeling with power types, language interleaving & consistency, operations on models, and automatic translation of formalizations to platform-specific code—and how to approach them with the MetaMorph formalism. This shows that the rich knowledge stack on formal languages in logic offers new tools for old problems.
... This analysis aims to ascertain the impacts of perspective actions on those language actions aiming to maintain consistency conditions in the requirement multilanguage modelling environment. In this multi-language perspective, there are 11,22,43,20, and 17 language actions for the environment model, use case diagrams, class diagrams, use case maps, and operation model, respectively. The distribution of the types of perspective action (re-exposed action, simple redefined action, complex redefined action, and hidden action) across the five languages is shown in Fig. 20. ...
... Removing or adding a new language may require an understanding of the whole system and all its languages and hence substantial manual efforts. Meier et al. [20] compare OSM, MoConseMI, and Vitruvius [17]. MoConseMI is a SUM approach that comes with a set of operators to transform initially separate metamodels into a single metamodel. ...
Full-text available
In modern software systems, software modellers often use different modelling languages and multiple views to describe the characteristics of a complex system. This multi-language system allows modellers to express a specific system characteristic with the most appropriate modelling languages and notations. With the proliferation of independently developed and continually evolving modelling languages, it becomes more challenging to reuse or combine multiple languages in a multi-language modelling environment. In this paper, we present a framework for the specification and development of multi-language systems based on perspectives to promote modularity in language reuse, inter-language consistency, and combination of languages. A perspective groups different languages for a modelling purpose and defines the role of each participating language. Furthermore, a perspective defines composite actions for building a consistent multi-model system and maintaining the links between different model elements. These actions are specified by re-exposing, combining, or redefining existing language actions (e.g. create an operation in a class diagram model) offered by the languages that the perspective reuses. The aim of this framework is to streamline the combination of multiple languages in a system and allow the perspective designer to focus only on specifying relationships between different languages. A generative approach then ensures appropriate language registration and model consistencies, hence freeing the perspective designer from the error-prone implementation of the consistency mechanism and simplifying the modular combination of different languages. We illustrate our approach with a perspective aimed at requirement elicitation and specification that combines five different languages, i.e. class diagrams, use case diagrams, collaboration diagrams, use case maps, and a domain-specific modelling language.
... In the following we demonstrate that language interleaving and the definition of consistency constraints can be easily realized in formalized conceptual modeling languages. Depending on the initial situation we can distinguish top-down approaches, where a newly defined or existing language is segmented in several sublanguages or views, and bottom-up approaches, where existing languages are interleaved and their metamodels are amalgamated and equipped with additional constraints [47]. We will discuss the first approach briefly and exemplify the second one in a case study. ...
... This means all information is captured in the model at all points in time and at the same time kept consistent due to the newly introduced postulates. This conforms to the idea of the single underlying model as proposed by Burger et al. [37,47]. ...
Enterprise modeling deals with the increasing complexity of processes and systems by operationalizing model content and by linking complementary models and languages, thus amplifying the model-value beyond mere comprehensible pictures. To enable this amplification and turn models into computer-processable structures a comprehensive formalization is needed. This paper presents a generic formalism based on typed first-order logic and provides a perspective on the potential and benefits arising for a variety of research issues in conceptual modeling. We define modeling languages as formal languages with a signature $\Sigma$ - comprising object types, relation types, and attributes through types and function symbols - and a set of constraints. Three cases studies are included to show the effectiveness of the approach. Applying the formalism to the next level in the hierarchy of models we create M2FOL, a formal modeling language for metamodels. We show that M2FOL is self-describing and therefore complete the formalization of the full four-layer metamodeling stack. On the basis of our generic formalism applicable to arbitrary modeling languages we examine three current research topics - language interleaving & consistency, operations on models, and automatic translation of formalizations to platform-specific code - and how to approach them with the proposed formalism. This shows that the rich knowledge stack on formal languages in logic offers new tools for old problems.
... This prevents further updates on the same element and as a result the recursion stops eventually. The template further iterates over all the MEMs of the model element (lines [10][11][12][13][14][15][16]. For each mapping, we get the corresponding mapped element (line 11) and then check if the mapped element has already been updated at line 13, otherwise, the template recursively calls updateElements with the mapped model element. ...
... Removing or adding a new language may require an understanding of the whole system and all its languages and hence substantial manual efforts. Meier et al. [16] compare OSM, MoConseMI, and Vitruvius [13]. MoConseMI is a SUM approach that comes with a set of operators to transform initially separate metamodels into a single metamodel. ...
... In particular, this means that none of the VPTs should involve mappings with cardinalities greater that one or which do not include the containment context of 1) Pragmatic SUMS: The first reason stems from the fact that, at least for the foreseeable future, most PVMEs will not be based on essential SUMs (i.e. monolithic SUMs that are 100% redundancy free [16]), but rather on pragmatic or virtual SUMs (V-SUMs) of the kind supported by VITRUVIUS [17], in which the SUM is organized internally into several semiindependent models. When this is the case most, if not all, views tend to focus on portraying information from just one internal model, and do this in a direct way which uses few, if any, of the problematic mappings outlined in the previous section. ...
Conference Paper
Full-text available
In projection-based modeling environments, users work with views of the modelled system or enterprise that are generated dynamically, on demand, from a Single Underling Model (SUM). Moreover, they usually cannot change the SUM directly, but can only influence its contents indirectly via views. This means that at least some of the views need to be editable so that they can be used to evolve the SUM to a new state. However, this is not always possible when the transformations used to project SUM content into view content do not provide the information needed to unambiguously map view changes into SUM changes. Therefore, mechanisms are needed to identify and take appropriate measures to ensure that the integrity of the SUM is not comprised, and it is not updated in unintended ways, when insufficient information is available. This paper illuminates the basic nature of the problem, categorizes the different kinds of situations in which editing ambiguities can arise and discusses potential strategies for dealing with them. These techniques contribute to the creation of user-friendly, yet dependable, projection-based modeling environments. Index Terms-multi-view specification, enterprise architecture modeling, model-driven development, views, viewpoints.
... CPPS quality managers want to effectively and efficiently identify factors potentially leading to specific quality risks. However, knowledge on causes and impact relationships may come from different disciplines with their views on the system [Meier et al., 2019]. Traditionally, quality managers do not use multi-view models for conducting risk assessments, making the results hard to validate, use in advanced analyses, replicate, and improve. ...
... Vitruvius is based on the OSM paradigm (see Section 3.2). It provides a solution to the problem of how SUM metamodels should be constructed, since defining a SUM metamodel according to Definition 2, which has no redundancies or implicit dependencies, is hard to achieve (Meier et al., 2019(Meier et al., , 2020: We propose the concept of a virtual SUM metamodel (V-SUM metamodel), which has an internal structure of modularized, coupled metamodels, but, externally, appears and can be used as if it were a single, monolithic (i.e., non-modularized) metamodel. This especially means that its instances are also free of inconsistencies, like ordinary SUMs according to Definition 1. ...
Full-text available
During the development of large software-intensive systems, developers use several modeling languages and tools to describe a system from different viewpoints. Model-driven and view-based technologies have made it easier to define domain-specific languages and transformations. Nevertheless, using several languages leads to fragmentation of information, to redundancies in the system description, and eventually to inconsistencies. Inconsistencies have negative impacts on the system’s quality and are costly to fix. Often, there is no support for consistency management across multiple languages. Using a single language is no practicable solution either, as it is overly complex to define, use, and evolve such a language. View-based development is a suitable approach to deal with complex systems, and is widely used in other engineering disciplines. Still, we need to cope with the problems of fragmentation and consistency. In this paper, we present the Vitruvius approach for consistency in view-based modeling. We describe the approach by formalizing the notion of consistency, presenting languages for consistency preservation, and defining a model-driven development process. Furthermore, we show how existing models can be integrated. We have evaluated our approach at two case studies from component-based and embedded automotive software development, using our prototypical implementation based on the Eclipse Modeling Framework.
... Meier et al. [8] compare OSM, MoConseMI, and Vitruvius [3]. MoConseMI is a SUM approach that comes with a set of operators to transform initially separate metamodels into a single metamodel. ...
Multi-view environments for software development allow different views of a software system to be defined to cover the requirements of different stakeholders. One way of ensuring consistency of overlapping information often contained in such views is to project them “on demand” from a Single Underlying Model (SUM). However, there are several ways to construct and adapt such SUMs. This paper presents four archetypal approaches and analyses their advantages and disadvantages based on several new criteria. In addition, guidelines are presented for selecting a suitable SUM construction approach for a specific project.
Full-text available
Domain-specic modeling promises to increase productivity by oering modeling languages tailored to a problem domain. Such mod- eling languages are typically dened by a metamodel. In consequence of changing requirements and technological progress, the problem domains and thus the metamodels are subject to change. Manually migrating models to a new version of their corresponding metamodel is costly, te- dious and error-prone and heavily hampers cost-ecient model-based development in practice. The coupled evolution of a metamodel and its models is a sequence of metamodel changes and their correspond- ing model migrations. These coupled changes are either metamodel- specic or metamodel-independent. Metamodel-independent changes can be reused to evolve dierent metamodels and their models, thus reducing migration eort. However, tool support is necessary in order to exploit these reuse opportunities. We propose a language that allows for decom- position of a migration into manageable, modular coupled changes. It provides a reuse mechanism for metamodel-independent changes, but is at the same time expressive enough to cater for complex, metamodel- specic changes.
Conference Paper
All Enterprise Architecture Modeling (EAM) approaches revolve around the use of multiple, inter-related views to describe the properties of a system and its surrounding environment - that is, they are multi-view specification (MVS) approaches. However, there is still little consensus on how such modeling environments should be realized and on the pros and cons of the different fundamental design choices involved in building them. In this paper we identify the different design choices put forward in the literature, evaluate their mutual compatibility, and discuss the extent to which they scale up to large enterprise systems. Finally we present some additional choices and outline some of the key features that future multi-view modeling environments should ideally support.
Conference Paper
During the development of component-based software systems, it is often impractical or even impossible to include all development information into the source code. Instead, specialized languages are used to describe components and systems on different levels of abstraction or from different viewpoints: Component-based architecture models and contracts, for example, can be used to describe the system on a high level of abstraction, and to formally specify component constraints. Because models, contracts, and code contain redundant information, inconsistencies can occur if they are modified independently. Keeping this information consistent manually can require considerable effort, and can lead to costly errors, for example, when security-relevant components are verified against inconsistent contracts. In this paper, we present an approach for keeping component-based architecture models and contracts specified in the Java Modeling Language (JML) consistent with Java source code. We use change-driven incremental transformations and the \vitruvius framework to automate the consistency preservation where this is possible. Using two case studies, we demonstrate how to detect and propagate changes and refactoring operations to keep models and contracts consistent with the source code.
The separation of view and model is one of the key concepts of Model-Driven Engineering (MDE). Having different views on a central model helps modellers to focus on specific aspects. Approaches for the creation of Domain-Specific Modelling Languages (DSML) allow language engineers to define languages tailored for specific problems. To be able to build DSMLs that also benefit from view-based modelling a common understanding of the properties of both paradigms is required. However, research has not yet considered the combination of both paradigms, namely view-based domain specific modelling to a larger extent. Especially, a comprehensive analysis of a view's properties (e.g., partial, overlapping, editable, persistent, etc.) has not been conducted. Thus, it is also still unclear to which extent view-based modelling is understood by current DSML approaches and what a common understanding if this paradigm is. In this paper, we explore view-based modelling in a tool-oriented way. Furthermore, we analyse the properties of the view-based domain-specific modelling concept and provide a feature-based classification of these properties.
This paper outlines a framework which supports the use of multiple perspectives in system development, and provides a means for developing and applying systems design methods. The framework uses “viewpoints ” to partition the system specification, the development method and the formal representations used to express the system specifications. This VOSE (viewpoint-oriented systems engineering) framework can be used to support the design of heterogeneous and composite systems. We illustrate the use of the framework with a small example drawn from composite system development and give an account of prototype automated tools based on the framework. Key Words: composite and heterogeneous systems; perspectives; view; agents; specification method; CASE tools; software development environments; process modelling.
Fragmentation of information across instances of different metamodels poses a significant problem for software developers and leads to a major increase in effort of transformation development. Moreover, compositions of metamodels tend to be incomplete, imprecise, and erroneous, making it impossible to present it to users or use it directly as input for applications. Customized views satisfy information needs by focusing on a particular concern, and filtering out information that is not relevant to this concern. For a broad establishment of view-based approaches, an automated solution to deal with separate metamodels and the high complexity of model transformations is necessary. In this paper, we present the ModelJoin approach for the rapid creation of views. Using a human-readable textual DSL, developers can define custom views declaratively without having to write model transformations or define a bridging metamodel. Instead, a metamodel generator and higher-order transformations create annotated target metamodels and the appropriate transformations on-the-fly. The resulting views, which are based on these metamodels, contain joined instances and can effectively express concerns unforseen during metamodel design. We have applied the ModelJoin approach and validated the textual DSL in a case study using the Palladio Component Model.
Conference Paper
Model-Driven Engineering provides an abstract representation of systems through the use of models and views. For complex systems, however, finding a single model and a single view to represent all relevant information of the system is infeasible. Specialized models for specific subsystems, domains or abstractions are more concise and thus more efficient than monolithic models. Furthermore, different tasks and concerns often require different views on the same model. Sustaining the consistency between different views and models is hard, especially if new models and views are dynamically added. In this paper, we present an approach that supports flexible views that may involve multiple models conforming to different metamodels. The approach is based on Orthographic Software Modeling and synchronizes individual instances using model transformations. These transformations are generated from view type definitions, metamodel correspondence rules and invariants, which are defined in a domain-specific language. We illustrate our approach with an application that combines component-based architectures with object-oriented source code and class diagrams.
Algebraic frameworks are important for building semantic foundations of bidirectional model transformations (BX). Symmetric BX are those for which neither model in a pair of synchronized models fully determines the other. We build two algebraic frameworks for symmetric BXs, with one correctly implementing the other, and both being delta-based generalizations of previous state-based frameworks. We also identify two new algebraic laws---weak undoability and weak invertibility, which are important for both state- and delta-based setting.