Formalizing the Four-layer Metamodeling Stack - arXiv

Software and Systems Modeling manuscript No.(will be inserted by the editor)

Formalizing the Four-layer Metamodeling Stack – Potentialand Benefits

Victoria Doller

Received: date / Accepted: date

Abstract Enterprise modeling deals with the increas-

ing complexity of processes and systems by operational-

izing model content and by linking complementary mod-

els and languages, thus amplifying the model-value be-

yond mere comprehensible pictures. To enable this am-

plification 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 Σ – comprising ob-

ject 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 levelin the hierarchy of models we create M2FOL, a formal

modeling language for metamodels. We show that M2FOL

is self-describing and therefore complete the formaliza-

tion 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.

Victoria DollerResearch Group Knowledge Engineering,Faculty of Computer Science,University of Vienna, Vienna, AustriaE-mail: [email protected]

Keywords Conceptual Modeling, Metamodeling,

Modeling Language, Formal Language, Predicate

Logic

1 Introduction

Enterprise modeling has proven instrumental in fac-

ing the challenges of increasing complexity and inter-

dependences of processes and systems in the modern

world. Research on enterprise modeling has enhanced

modeling languages from mere instruments for pictures

supporting human understanding to highly specialized

tools with value adding mechanisms like information

querying, simulation, and transformation [5,24]. The

nature of models has evolved from a visual representa-

tion of information to an exploitable knowledge struc-

ture [11]. Nevertheless the European enterprise model-

ing community experiences that the potential of enter-

prise modeling is currently not fully utilized in practice

and modeling is employed only by a limited group of

experts. Therefore in [56,57] a research agenda is for-

mulated to establish “modeling for the masses” (MftM)

and broadcast its benefits also to non-experts.

1.1 A Need for Formalization

Although the initiators of the MftM movement men-

tion that the formality of model representation possi-

bly hampers understandability, we argue that the idea

behind MftM nevertheless requires an investigation of

the formal foundations of models and languages. This

is for three reasons: 1) According to the stakeholder di-

mension of challenges in enterprise modeling research

[56, p.234] computers also have to be seen as stakehold-

ers producing and consuming models. To make mod-

arX

iv:2

105.

0103

8v1

[cs

.SE

] 3

May

202

1

2 Victoria Doller

els computer-processable they have to be formalized,

because as computers do not understand semi-formal

or unstructured models and language specifications [6].

2) The vision of models being not autotelic but be-

ing a means to the operationalization of information

[56, p.229] calls for value-adding functionality beyond

mere graphics like reasoning, verification & validation

or simulation, which is formulated ideally computer-

understandably and implementation-independently, i.e.

formalized. 3) The vision of local modeling practices

which are globally integrative [56, p.229] calls for a com-

mon foundation of what models and modeling languages

are to enable the linking and merging of models in dif-

ferent domains with different semantics [29].

Formalization is also essential in the light of the

emergent importance of domain specific modeling lan-

guages (DSMLs) [23] as well as an increasing agility

in the advancement and extension of established lan-

guages and methods [34]. The lack of a common way

for formalizing DSMLs leads to divergent formal foun-

dations limiting the opportunities to compare or link

models. Frequently the big standards are extended for

a specific domain, e.g. the extension of i* with secu-

rity concepts constituting the modeling language Se-

cure Tropos [48,55]. Therefore a common way of spec-

ifying the base languages as well as the extensions or

modules is required. A silo like formalization of the big

standards is not sufficient as divergent base concepts of

models and different underlying formal structures can

impede a mutual interconnection and integration.

Another important building block for advancing the

science of conceptual modeling is an exact and com-

monly applied method for specifying modeling

languages. A survey conducted by Bork et al. showed

that the specification documents of the standardized

languages like UML and ArchiMate diverge in the con-

cepts they consider as well as in the techniques they

use to specify their visual metamodels [8]. Examples

from recent scientific publications indicate that also in

research on domain specific languages no common prac-

tice of metamodel specification is in use. Several contri-

butions specify metamodels with UML class diagrams,

declaring object types as classes and relation types as

classes or named association arrows, e.g. [33,44,53,58,

60]. Others simply define the object and relation types

with box-and-line models devoid of an underlying lan-

guage and rely on the intuitive understanding of the

reader, e.g. [43,51]. This shows that although meta-

models are models themselves and therefore subject of

interest for enterprise modeling research no language

for metamodels has been established yet. Nevertheless

when a language has to be implemented or executed a

precise and unambiguous definition of the metamodel

is crucial [6].

1.2 Goal and Requirements

According to the AMME framework of agile modeling

method engineering shown in Figure 1 the phase of for-

malization is pivotal in the lifecycle of a modeling lan-

guage. Yet there is no common procedure of how to

formalize arbitrary modeling languages. Often existing

formalization approaches restrict to a concrete applica-

tion, domain or language, thereby limiting the reusabil-

ity in other domains and languages. As the AMME life-

cycle is meant as a generic procedure model for gener-

ating arbitrary modeling languages and methods, we

need a formalism applicable to any domain and lan-

guage an engineer might come up with. The work at

hand intends to close this gap and aims at building a

bridge between the Design phase of collecting the rele-

vant concepts and the Develop phase of transferring the

final design to a metamodeling platform in the AMME

lifecycle. Such a formalism must be consistent with the

semantics and structure of a modeling language. For

this reason we have to consider the formal foundations

of modeling languages. We summarize the concrete re-

quirements for the formalism as follows: 1) it has to

be complete regarding the general building blocks of

a language, 2) it has to be faithful to the character of

modeling languages as such, and 3) it must be generic in

a way that it admits the formalization of any language.

In the work at hand we will demonstrate that in ac-

cordance with these requirements modeling languages

can be defined as as formal languages in the sense of

logic. This means they comprise a signature Σ for the

syntax and a set of constraints, for which we use first-

order predicate logic. This paper extends our prior work

[19] published at the PoEM 2020 conference about the

definition of modeling language, where we concretely

stated how the core concepts of modeling languages can

be expressed in logical terms. Predicate logic provides

the construct of a Σ-structure, i.e. an interpretation of

the signature, which is the canonical correspondent to

the model being an instantiation of a metamodel. Ap-

plying the definition to the meta language level results

in M2FOL, a formal modeling language for metamodels.

With M2FOL we are capable of modeling the syntax of

a language to be specified, to be more precise the sig-

nature of the language according to the definition. The

paper at hand extends the presented definition of for-

mal modeling languages as well as the language M2FOL

with the concept of multi-value attributes. We further-

more exemplify the potential and benefits inherent to

the proposed formalism on a diverse range of research

Formalizing the Four-layer Metamodeling Stack – Potential and Benefits 3

Fig. 1: The AMME lifecycle for agile modeling method engineering adapted from [34]

topics and demonstrate the opportunities established

methods from logic can provide for conceptual model-

ing.

The rest of this paper is structured as follows: In

Section 2 we give an overview of related work on for-

malization of metamodels and modeling languages. In

Section 3 we introduce the definition of formal model-

ing languages and models and concretize how the ba-

sic concepts of a language – object and relation types,

attributes, inheritance, and constraints – can be ex-

pressed in logical terms. We then use this definition in

Section 4 to create M2FOL – a formal modeling language

for metamodels – and outline its self-describing charac-

ter. Given a metamodel specified with M2FOL we show

how to algorithmically deduce the signature of the cor-

responding modeling language. After that we give in

Section 5 an outlook to the potential and benefits of

formal modeling languages. We present some ongoing

research and approaches on how to interleave modeling

languages, formally include operations on models into

the language specification, and use the formalization as

a single point of specification processable by machines.

In Section 6 we evaluate the formalism with respect to

the formulated goal and requirements and explain the

agenda for the empirical evaluation that is currently

being conducted.

2 Background and Related Work

2.1 Formalism vs. Formal Syntax

We begin by discussing the distinction between a for-

malism and a formal way of specifying a language. A

formalism always gives rise to a formal specification.

The converse, however, is not true. This can be com-

pared to the concept of a graph and the unique and

precise way of specifying a graph with an adjacent ma-

trix. Each graph can be represented as a matrix but a

matrix per se does not provide the semantics of graph

theory. The same applies to specification techniques

merely offering a formal syntax to describe modeling

languages. These techniques provide a unique way of

specification but lack the structure and semantics of

the underlying components of conceptual modeling. A

formal syntax may offer a notation for specifying inher-

itance of object types. Nevertheless, the notation does

not accomplish the inherent semantics, i.e. the transfer

of features of the supertype to the subtype. This be-

haviour must be added to the syntax system by hand

although a suitable underlying structure would entail

concepts for inheritance. For this simple case basic set

theory would suffice to capture inheritance via sets and

containment automatically extending functions defined

on the superset to all subsets.

In current research there is a consensus about a

proper underlying structure of modeling languages, that

is formal languages as defined in mathematical logic [16,

25,50,52,62]. Of course not every formal language is a

modeling language, but modeling languages form a sub-

class of all formal languages. In this paper we want to

concretize and work out this class of formal modeling

languages.

Our principal distinction between a formalism and

a formal syntax distinguishes our goal from existing ap-

proaches like the Meta-Object Facility (MOF) standard

which offers a concrete syntax or notation system for

specifying modeling languages but no inherent theory

and methods for the concepts to be described. Fur-

thermore MOF was developed with metamodels meant

as software structure specifications [59] which restricts

metamodeling only to one domain. In contrast to that,

our approach regards metamodeling as a generic instru-

ment applicable to a broad range of domains rather

than only software engineering. Also the language Z

or the lambda calculus differ from our endeavour in

a fundamental way as they are methods developed to

4 Victoria Doller

support the specification of computation, programming

and software development. Of course they also make

use of concepts from logic and may overlap with our

approach in some areas. Nevertheless, they do not in-

herit the semantics of modeling languages and provide

no explicit way of describing modeling languages.

2.2 Formalisms for Concrete Modeling Languages

According to the Characterizing Conceptual Model Re-

search (CCMR) framework we are interested in contri-

butions located in the dimension Formalize working on

the level of Conceptual Modeling Languages and Meta-

modeling Languages [17]. In this respect, we want to

delineate our approach from the various attempts ad-

dressing the formalization of a specific modeling lan-

guage. These attempts mostly aim at supporting a spe-

cific purpose or functionality and do not provide means

to define arbitrary metamodels and languages. An ex-

ample is the OSM-logic using typed predicate logic for

object-oriented systems modeling with a focus on time-

dependent system behaviour [15]. Another example is

the SAVE method for simulating IoT systems using the

δ-calculus [14]. These specific formalizations may of-

fer ideas suitable for being generalized to a generic ap-

proach but will not be comprehensively discussed here.

However, as soon as there is a common practice of for-

mally defining the ubiquitous concepts of modeling lan-

guages these specific approaches can be constructed as

reusable extensions and modules and be of value in a

broader field of application.

2.3 Formalisms for Ontologies and Concept Spaces

For a systematic positioning of our approach we use of

the triptych allegory proposed by Mayr and Thalheim

[45]. They define conceptual modeling as tripartite con-

sisting of an encyclopedic dimension for grounding the

semantics in an ontology or concept space, a language

dimension for the definition of language terms and valid

expressions, and the conceptual modeling dimension in

between as a link between term and concept space. We

are mainly interested in a formalization of the language

dimension and acknowledge that in the encyclopedic di-

mension there also exist various attempts to formaliza-

tion, like the KL-ONE family [9] and Description Logic

[2]. Also the formal system of a conceptualization of

domains as basis for truthful modeling languages pro-

posed by Guizzardi et al. [26,27] has to be located in the

encyclopedic dimension and has therefore to be distin-

guished from our goal. In this theory of ontologically-

driven conceptual modeling fruitful for the objective

of a domain-faithful grounding for modeling languages,

the language dimension is an a-posteriori concept im-

plicitly obtained from ontological considerations.

2.4 Formalisms for Languages

When focusing on formalizations in the language di-

mension the existing approaches can be categorized ac-

cording to the underlying theory they use, which is

mostly graph theory, set theory or logic. All three of

them offer concepts for the concrete structural behav-

iour of the elements to be described. In the following

we present examples illustrating the shortcomings of

the former two and argue why logic provides the most

canonical approach.

In the domain specific language KM3 presented by

Jouault and Bezivin models are defined as directed

multi-graphs conforming to another model, the meta-

model, itself a graph [32]. Using this formalism the au-

thors define a self-descriptive metametamodel and de-

duce a domain specific language to specify metamodels.

This approach puts an emphasis on the graph-like box-

and-line structure of models, rather than on the linguis-

tic aspects and similar to MOF has a narrow focus on

software structure specification.

A system based on set-theory is the formalization of

Ecore and EMOF proposed by Burger [12, 2.3.2] which

uses the formal description of concepts from the OCL

specification [49, A.1]. Set theory comprises very ba-

sic concepts describing structures, only admiting the

subsumption of elements in sets and set hierarchies. Itholds no further information about the semantics of the

elements.

Also the FDMM formalism introduced by Fill et al.

addressing conceptual modeling domains in a broader

variety uses set theory to specify metamodels and mod-

els [22]. The authors explicitly aim at a formalization

of metamodels realized with the metamodeling plat-

form ADOxx [4] and do not claim to be applicable for

platform-independent specifications.

Neither graph theory, basis of KM3, nor set theory,

basis of FDMM and the MOF formalization by Burger,

do justice to the linguistic character of modeling lan-

guages and provide canonical concepts for the defini-

tion of a set of terms and for instantiation, an essen-

tial characteristic of modeling languages. Therefore the

technique and semantics of this instantiation relation

between model and metamodel has to be constructed

ad-hoc and lacks the beneficial knowledge stack of es-

tablished theories dealing with linguistic structures.

Formalizing the Four-layer Metamodeling Stack – Potential and Benefits 5

2.5 Formalisms Based on Logic

Formal languages as defined in mathematical logic in-

herently comprise the concept of instantiation as inter-

pretation of the signature in logical terms, and they

provide a rich knowledge base about their properties.

Therefore, in current research the notion of modeling

languages as formal languages in the sense of mathe-

matical logic is receiving increasing attention [16,25,

50,52,62].

In their investigation of formal foundations of

domain-specific languages Jackson and Sztipanovits in-

troduce typed predicate logic to handle object types in

models [30,31]. They indeed treat modeling languages

as formal languages but they do not adopt the con-

cept of a language interpretation, i.e. instantiation for

model instances, but rather consider a model to be a set

of valid statements about the model. This is also true

for Telos [38], which builds on the premise that the con-

cepts of entities and relations are omitted and replaced

by propositions constituting the knowledge base. The

choice of typed first-order logic for the formalization of

these propositions is natural and explained in great de-

tail in [39]. Similar to Jackson and Sztipanovits knowl-

edge is represented solely as a set of sentences in the

formal language. In our approach on the other hand we

do not adopt the transformation of models into propo-

sitions but rather directly deal with the ubiquitous con-

cepts of objects and relations and an instantiation hi-

erarchy between models and metamodels. This leads

to a different view on models. In the attempts above

a model is constituted by statements, whereas in our

approach these statements are used as constraints re-

stricting valid expressions using the proposed signature.

In his work on the theory of conceptual models,

Thalheim describes modeling languages as being based

on a signature Σ comprising a set of postulates, i.e.

sentences expressed with elements of Σ [62]. Models

are defined as language structures satisfying the pos-

tulates, which canonically corresponds to the concept

of instantiation of a metamodel. We go one step fur-

ther and concretely point out how to capture the core

concepts of a modeling language in a signature Σ to

unify the method of formalizing a language. This then

enables us to investigate the class of formal modeling

languages, compare formalized languages, reuse compo-

nents and develop generic methods for language fusion,

model transformation etc. independent of a concrete

language.

In summary, the literature review suggests that the

structure of modeling languages including its linguistic

character can be grounded in the concepts of formal

languages. Therefore, in the work at hand we propose

a formal definition of modeling languages in which we

concretely specify the modeling concepts and their for-

mal equivalent in logical terms with the prospect of

successive elaboration.

3 Definition of Formal Modeling Languages

The intended definition shall serve as a cornerstone

for a common way of formalizing modeling languages,

which thereby become comparable, reusable and mod-

ularizable. A formal definition for modeling languages

in general enables an investigation of common features

of the resulting subclass of formal languages as well

as a sound mathematical foundation for their function-

ality. We build on a survey conducted by Kern et al.

[36] on common concepts in the meta2models of six es-

tablished metamodeling platforms. The definition be-

low incorporates all concepts identified in at least half

of the investigated platforms. These are object types,

relation types (binary), attributes (multi-value), inher-

itance (for object types, single), and a constraint lan-

guage. Other concepts identified in [36] which are not

yet included are roles, ports, inheritance of relations, n-

ary relations, and models in the sense of model types.

These concepts mainly coincide with the core con-

cepts introduced for conceptual modeling of informa-

tion systems by Olive [50]. Additional concepts men-

tioned in Olive’s work which are of high interest but not

yet included in our approach are derived types, generic

relation types, and powertypes.

3.1 A Definition based on Predicate Logic

We use typed (also called sorted) predicate logic in this

approach. The mathematical basics can be found in

textbooks on logic or mathematics for computer sci-

ence, e.g. [21,46]. Some remarks on notation: To ease

the differentiation between language and model level,

we use capital letters for the symbols of the language

and lowercase letters for the elements of the model.

Definition 1 A (formal) modeling language L consists

of a typed signature Σ = {S,F ,R, C} and a set C of

sentences in L for the constraints, where:

– S is a set of types, which can be further divided

into three disjoint subsets SO, SR, and SD for object

types, relation types and data types;

– the type set SO is strictly partially ordered with

order relation <O⊂ SO × SO to indicate the in-

heritance relation between the corresponding ob-

ject types;

6 Victoria Doller

– the type set SD can contain simple types T for

value domains of single value attributes, or prod-

uct types T ′ = T1 × T2 × · · · × Tn for value do-

mains of n-ary multi-value attributes (n > 1),

where the i-th value is of type Ti ∈ SD∪SO∪SR;

– F is a set of typed function symbols such that:

– for each relation type R in SR there exist two

function symbols FRs and FR

t with domain type

R ∈ SR and codomain type Os,Ot ∈ SO as-

signing the source and target object types to a

relation;

– for each single-value attribute A of an object or

relation type T there exists a function symbol

FA with domain type T and codomain type an

element in SD ∪ SO ∪ SR assigning the simple

data type or referenced object type or relation

type to the attribute;

– for each multi-value attribute A of an object or

relation type T there exists a function symbol

FA with domain type T and codomain type an

product type in SD;

– R is a set of typed relation symbols containing <O;

– C is a set of typed constants to specify the possible

values ci of a simple type T ∈ SD of the attributes;

– the set C is a set of sentences in L constraining the

possible models, also called the postulates of the

language.

This definition explicates the formalization of the essen-

tial modeling concepts of a language, i.e. object types

and inheritance, binary directed relation types and

single- or multi-value attributes. Note that the defini-

tion does not prohibit the existence of additional sym-

bols in the signature, so broader concepts like n-ary

relations can optionally be included and are topic of

further investigation. Also structures beyond the visual

elements of a model can be included, e.g. paths as tran-

sitive relations or substructures comprising several ele-

ments.

We want to point out, that relation types are defined

on the same level as object types, not subordinate to

them. This highlights their significance for a model be-

yond mere arrows and allows for defining attributes of

relations, multiple relations of the same type between

the same two objects, as well as for inheritance of rela-

tion types.

With the data types and constants we can define

attribute domains like integers via specifying a type

called N and constant symbols 0,1,2,3, ... in C of type

N for the numbers, or enumeration lists like a person’s

gender via specifying a type called gender and constant

symbols male, female, and else in C. The elements of

the simple or product types of SD are typically not

Fig. 2: Notation excerpt of the CoChaCo Method [35]

visible in graphical models. They are exclusively used

for specifying attribute domains.

Note that if we assume the set of constants for at-

tribute domains to be finite, models are always finite,

because by construction they contain only finitely many

objects and relations.

Definition 2 A model M of a language L with typed

signature Σ = {S,F ,R, C} is an L-structure conform-

ing to the language constraints C, i.e. M consists of

– a universe U of typed elements respecting the type

hierarchy, that is

– for each T in S there exists a set UT ⊂ U and

U =⋃

T∈S UT;

– all sets UT for T ∈ SO ∪ SR have to be pair-

wise disjoint except for sets UO1 and UO2 with

O1,O2 ∈ SO where O1 <O O2. In this case UO1

must be a subset of UO2, i.e. UO1

⊆ UO2;

– an interpretation of the function symbols in L, i.e.

for each function symbol F ∈ F with domain type

T1 × . . .×Tn and codomain type T a function f :

UT1 × . . .× UTn → UT;

– an interpretation of the relation symbols in L, i.e.

for each relation symbol R ∈ R with domain type

T1 × . . .×Tm a relation r ⊂ UT1× . . .× UTm

;

– for each simple type T ∈ SD and constant C ∈ C of

type T an interpretation c ∈ UT;

– for each constraint φ in C the model M satisfies φ,

i.e. M |= φ.

This definition of models as language structures goes

beyond a visualisation and considers models as knowl-

edge structures as described in [11]. Thereby we over-

come several shortcomings of graphical representations,

like the missing depiction of attributes and their do-

mains in models or the visual mixing of the metarela-

tion inheritance with the definition of relation types in

metamodels.

3.2 Running Example Petri Nets

We will now illustrate the definition on the example of

the Petri Net modeling language. For the visualization

of the metamodel we use the notation of CoChaCo,

a method to support the creative process of modeling

Formalizing the Four-layer Metamodeling Stack – Potential and Benefits 7

Fig. 3: A metamodel of Petri Nets

method design [35]. This method comprises concrete

syntax for most of the concepts contained in Definition

1 with a slightly different naming, see Figure 2.

Example 1 The Petri Net Modeling Language PNThe Petri Net metamodel depicted in Figure 3 com-

prises three object types Node (No), Place (Pl), and

Transition (Tr) constituting SO. Thereby Place and

Transition inherit from Node, i.e. Place <O Node

and Transition <O Node. Furthermore, the language

comprises only one relation type Arc element of SR.

For the attribute Tokens of object type Place we need

a type N with the usual addition + and order rela-

tion <N as well as constants in C = {0, 1, 2, ...} all

of type N. The set S of types is then the union S =

SO ∪ SR ∪ SD={Node, Place, Transition, Arc, N}.For the relation Arc we have to specify the source and

target object types by introducing two function symbols

FArcs and FArc

t both with domain Arc and codomain

Node. For the attribute Tokens we introduce a func-

tion symbol FTokens with domain Place and codomain

N assigning each place instance a number of tokens. Fi-

nally we have to define the constraints of the language.

These rules are not contained in a graphical metamodel.

In existing specifications they are mainly specified with

natural language or OCL. In the predicative formaliza-

tion at hand constraints are an integral part of the lan-

guage. Following four sentences written in the alphabet

of PN ensure Node to be abstract, i.e. any element in

Node lies either in Place or in Transition (1), as well

as the alternation of types of the elements connected

by an arc (2, 3) and the prohibition of multiple arcs

between the same two elements (4). For ease of read-

ability we abuse the notation ∀x ∈ T for x being of type

T instead of using the type specific quantifier ∀Tx.

∀x ∈ No ∃y ∈ Pl, z ∈ Tr (x = y ∨ x = z) (1)

@x, y ∈ Pl, u ∈ Arc (FArcs (u) = x ∧ FArct (u) = y) (2)

@x, y ∈ Tr, u ∈ Arc (FArcs (u) = x ∧ FArct (u) = y) (3)

∀u, v ∈ Arc ((FArcs (u) = FArcs (v)∧FArct (u) = FArct (v)) =⇒ u = v) (4)

Example 2 A Petri Net Model

A Petri Net model depicting a simple barber shop sce-

nario is shown in Figure 4. Its formalization, i.e. the

Fig. 4: A Petri Net model depicting a simple barber

shop scenario

corresponding PN -structure, looks as follows: The uni-

verse of places UP contains three elements UP= {w(ait),

b(usy), i(dle)}. The universe of transitions UT com-

prises three elements UT={e(nter), s(erve), d(one)}.Six arc elements exist in UA = {a1,a2,a3,a4,a5,a6}with source and target fArcs (a1) = e, fArct (a1) = w,

fArcs (a2) = w, fArct (a2) = s, fArcs (a3) = s, fArct (a3) =

b, fArcs (a4) = b, fArct (a4) = d, fArcs (a5) = d,

fArct (a5) = i, fArcs (a6) = i, and fArct (a6) = s. For

the attribute type and values the natural numbers Nare included in the model, UN = {0, 1, 2, ...}. The in-

stantiation of the attribute Tokens looks as follows:

fTokens(w) = 2, fTokens(b) = 0 and fTokens(i) = 1.

We can easily check that the formalized model satisfies

all postulates 1–4 of the language PN .

Notice that the formalized model in Example 2 and

the graphical model in Figure 4 represent the same

thing. They are merely alternative ways of describing a

system but with different merits. Whereas the graphical

model is easy and fast to comprehend, the formal model

is precise and complete, as attribute values are often not

legible from a pictoral model. This can be compared to

the different representation forms of a graph – once as

a graphical depiction and once as an adjacent matrix.

4 M2FOL – MetaModel 2 First Order Logic

A Formal Modeling Language for Metamodels

Metamodels are models themselves expressed in a meta-

modeling language. We propose a formal modeling lan-

guage in the sense of Definition 1 for metamodels called

M2FOL, i.e. a metamodeling language to be exact. This

language is capable of describing precisely the concepts

explicated in Definition 1. In general meta2models of

metamodeling languages are supposed to be self-de-

scribing, which results in a four-layer metamodeling

stack as depicted in Figure 5. We will show, that the

8 Victoria Doller

Fig. 5: The four-layer metamodeling stack based on [41]

metamodel of M2FOL, a meta2model by nature, also par-

takes of this property.

4.1 Definition of M2FOL

We stick to the notational convention of capital letters

for elements on the language level and lowercase letters

for elements on the model level. To indicate the met-

alevel of M2FOL and metamodels we use the typewriter

font for meta symbols and elements. For ease of read-

ability we write F : X → Y when F is a function with

domain type X and codomain type Y . Nevertheless, the

instantiation is then a function f : UX → UY defined

on universes of typed elements. To be consistent in the

naming of the symbols in M2FOL we distinguish between

an attribute type on meta level and an attribute as the

concrete assignment of a value to an element on model

level.

With M2FOL we want to model object types and in-

heritance relations between them, relation types con-

nected to their from and to object types, attribute

types and their data types, and possible data. Ac-

cording to Definition 1 all the bold concepts constitute

a type in SO in M2FOL, whereas all italic concepts make

up a type in SR in M2FOL. The types inheritance, from,

and to, furthermore require assignment functions for

source and target specification. Data types and data are

necessary for defining attribute domains and its values,

e.g. the domain N0..10 and values {0, 1, 2, ..., 9, 10} or an

enumeration list domain gender with values male, fe-

male, else. Attribute types need the assignment of own-

ing type and value domain.

Definition 3 The metalanguage M2FOL is a modeling

language with signature Σ = {S,F ,R, C} with the set

of types split in S = SO ∪ SR ∪ SD, where:

– SO consists of the types O(bject) T(ype), R(elation)

T(ype), A(ttribute) T(ype), D(ata) T(ype), and D(ata),

furthermore two supertypes: ORT(ype), and

DORT(ype) SO = {OT, RT, AT, DT, D, ORT, DORT};– The types OT, and RT, inherit from ORT, the types

ORT, and DT inherit from DORT: OT <O ORT, RT <OORT, ORT <O DORT, DT <O DORT;

– SR consists of the types Inh(eritance), Fr(om), and

To: SR = {Inh, Fr, To};– SD contains product types DORTn for all n > 1 as

well as a type TDORT for the union of all DORTn :

TDORT =⋃i DORT

i

– the set of function symbols consists of following el-

ements:

– two symbols FInhs and FInht assigning source and

target to Inh-typed relations: FInhs : Inh → OT,

FInht : Inh→ OT;

– two symbols FFrs and FFrt assigning source and

target to Fr-typed relations: FFrs : Fr→ RT, FFrt :

Fr→ OT;

– two symbols FTos and FTot assigning source and

target to To-typed relations: FTos : To→ RT, FTot :

To→ OT;

– two symbols Fval and Ftype assigning to an at-

tribute type its value domain and the object or

relation type it belongs to. The value assignment

can be a reference or a n-valued type in DORTn:

Fval : AT→⋃i(DORT)i, Ftype : AT→ ORT;

– a symbol FDT to assign a data type to a data

element: FDT : D→ DT;

– R consists of a symbol <OT transitively extending

the inheritance relation given by Inh to a strict par-

tial order on the set of object types R = {<OT ⊂OT× OT}.The postulates of the language (for brevity we use

the abbreviation xry for relation r of type T, x being

FTs (r) and y being FTt (r)):

∀x, y, z ∈ OT, v, w ∈ Inh (xvy, xwz =⇒y = z ∧ v = w) (5)

∀x, y ∈ OT, u ∈ Inh (xuy =⇒ x <OT y) (6)

∀x, y ∈ OT ∃z ∈ OT, u ∈ Inh (x <OT y =⇒xuy ∨ (xuz ∧ z <OT y)) (7)

∀x ∈ RT ∃y, z ∈ OT, u ∈ Fr, v ∈ To (xuy ∧ xvz) (8)

@u, v ∈ Fr (FFrs (u) = FFrs (v) ∧ u 6= v) (9)

@u, v ∈ To (FTos (u) = FTos (v) ∧ u 6= v) (10)

∀x ∈ ORT ∃y ∈ OT, z ∈ RT(x = y ∨ x = z) (11)

∀x ∈ DORT ∃y ∈ ORT, z ∈ DT(x = y ∨ x = z) (12)

Formalizing the Four-layer Metamodeling Stack – Potential and Benefits 9

For <OT we furthermore require to be a strict partial

order, i.e. <OT is transitive, irreflexive and antisymmet-

ric.

The constraints ensure single inheritance (5), <OT being

the transitive closure of Inh under the assumption that

all universes are finite (6–7), the existence and unique-

ness of to and from objects of a relation (8-10), and the

abstractness of the types ORT and DORT (11–12). The

absence of cyclic inheritance and self-inheritance follow

from the properties of <OT.

4.2 Running Example Petri Nets

With this language we now can transfer the graphical

metamodel of Figure 3 to a formal M2FOL-model.

Example 3 The Petri Net Metamodel MNPThe universe of object types UOT comprises three ele-

ments n(ode), p(lace), and tr(ansition). The universe

of relation types URT contains one element a(rc). One el-

ement tok(ens) is contained in the universe of attribute

types UAT. The universe UInh contains the instantiation

relations p n between p and n as well as tr n between

tr and n. UFr contains the relation a from of the source

element assignment to the relation type a. UTo contains

the relation a to of the target element assignment to

the relation type a. For these four elements the cor-

responding source and target elements have to be as-

signed: fInhs (p n) = p, fInht (p n) = n, fInhs (tr n) = tr,

fInht (tr n) = n, fFrs (a from) = a, fFrt (a from) = n,

fTos (a to) = a, fTot (a to) = n. From Inh the transitive

order relation <OT is deduced: <OT= {(p, n), (tr, n)}.Furthermore there are data values {0, 1, 2, ...} in UD all

of type N ∈ UDT, fDT (i) = N ∀i ∈ UD. These are needed

for the value domain of the attribute type tok, an at-

tribute assigned to p: ftype(tok) = p, fval(tok) = N. In

short this can be written as follows:

UOT = {n(ode), p(lace), tr(ansition)}, (13)

URT = {a(rc)}, UAT = {tok(en)}, (14)

UInh = {p n, tr n}, UFr = {a from}, (15)

UTo = {a to}, UDT = {N}, UD = {0, 1, 2, ...}, (16)

UORT = {n, p, tr, a},UDORT = {n, p, tr, a,N} (17)

<OT= {(p, n), (tr, n)} (18)

fInhs (p n) = p, fInht (p n) = n, (19)

fInhs (tr n) = tr, fInht (tr n) = n, (20)

fFrs (a from) = a, fFrt (a from) = n, (21)

fTos (a to) = a, fTot (a to) = n, (22)

ftype(tok) = p, fval(tok) = N, (23)

fDT (i) = N ∀i ∈ UD (24)

This formal metamodel MNP conforms to all constraints

5-12 and describes the formal language NP introduced

in Example 1. Their subordination prompts a generic

procedure on how to deduce the latter from the former.

In Table 1 we present this procedure as an algorithm.

In the right column the algorithm is exemplified on the

metamodel of Petri Nets. Compare the resulting lan-

guage to Example 1.

4.3 Meta-perspective on M2FOL

Finally we formalize the metamodel of M2FOL as M2FOL

model. The graphical metamodel is depicted in Figure

6.

Example 4 Metamodel of M2FOL

The M2FOL metamodel contains seven objects of type

OT={o(bject)t(ype), r(elation)t(ype), a(ttribute)t(ype),

d(ata)t(ype), d(ata), ort(ype), dort(ype)}, three ob-

jects of type RT={inh, fr(om), to}, three objects of

type AT= {val(ue) dom(ain), ass(igned) to, ass(igned)

d(ata)t(ype), many objects of type DT = {dorti∀i,⋃i(dort)i} (not visible in the graphical metamodel),

four relations of type Inh={ot < ort, rt < ort, ort <

dort, dt < dort}, three relations of type From=

{source inh, source to, source fr}, as well as three

relations in To={target inh, target to, target fr},furthermore 26 assignments of source and target ob-

jects, attribute owning types and attribute value types.

fs(target inh) = inh, ft(target inh) = ot, (25)

fs(source inh) = inh, ft(source inh) = ot, (26)

fs(target fr) = fr, ft(target fr) = ot, (27)

fs(source fr) = fr, ft(source fr) = rt, (28)

fs(target to) = to, ft(target to) = ot, (29)

fs(source to) = to, ft(source to) = rt, (30)

fs(ot < ort) = ot, ft(ot < ort) = ort, (31)

fs(rt < ort) = rt, ft(rt < ort) = ort, (32)

fs(ort < dort) = ort, ft(ort < dort) = dort, (33)

fs(dt < dort) = dt, ft(dt < dort) = dort, (34)

ftype(ass dt) = d, fval(ass dt) = dt (35)

ftype(ass to) = at, fval(ass to) = ort, (36)

ftype(val dom) = at, fval(val dom) =⋃i

(dort)i (37)

On the one hand the construct above is itself a model

expressed in the language M2FOL. On the other hand

this metamodel defines M2FOL as a meta2model. With

the algorithm presented above we deduce Definition 3

from Example 4. So we conclude that the proposed

modeling language M2FOL for metamodels is self-

10 Victoria Doller

M2FOL (Meta)Model to Language-Signature MappingApplication to the Petri NetMetamodel

1.

Each metamodel element o in the set UOT definesan object type O of the language. The inheritancerelation <OT⊂ UOT × UOT must be adopted to thetypes.

o ∈ UOT � O ∈ SO,<OT�<O

node ∈ UOT � Node ∈ SO,place ∈ UOT � Place ∈ SO,trans ∈ UOT � Trans ∈ SO

2.Each metamodel element r in the set URT defines arelation type R of the language.

r ∈ URT � R ∈ SR arc ∈ URT � Arc ∈ SR

3.

For each relation type r ∈ URT there exist an el-ement s of type From and an element t of typeTo and both relation elements have as source el-ement r, fFrs (s) = r, fFrs (t) = r. The assignmentfTot (s) = os indicates the source object type of R,fTot (t) = ot indicates the target object type of R.

r, s, os � FRs : R → Os;

r, t, ot � FRt : R→ Ot

arc, fFrt (a from) = n �FArcs : Arc → Node;

arc, fTot (a to) = n � FArct :

Arc→ Node

4.

Each metamodel element dt in UDT defines a datatype DT of the language. Each metamodel elementd in UD with fDT(d) = dt becomes a constant symbolCd in C of type DT.

dt ∈ UDT � DT ∈ SD;d ∈ UD � Cd ∈ C

N ∈ UDT � N ∈ SDT ;i ∈ UD, fDT (i) = N � i ∈ Cof type N

5.

Each metamodel element a in the set UAT definesa function symbol Fa of the language. The objector relation type a belongs to, i.e. the domain of Fa,is given by the assignment ftype(a) = tty ∈ UOT ∪URT, its value range, i.e. codomain, by fval(a) =(tv1

, . . . , tvn) ∈ (UOT ∪ URT ∪ UDT)n

a, tty, tv � F a : Tty → Tv

tok, ftype(tok) = place,fval(tok) = N � FTokens :Place→ N

6.The constraints of the language have to be addedmanually, because this information is not deter-mined by the metamodel.

Table 1: Algorithm to deduce a formal modeling language signature from its M2FOL metamodel specification

Fig. 6: The metamodel of M2FOL

describing and thereby complete the formalization of

the four-layer metamodeling stack.

In Figure 7 we do a wrap-up of all the presented def-

initions and examples on the language definition hierar-

chy proposed by Thalheim and Mayr [45]. The authors

make an explicit distinction between this hierarchy and

the model hierarchy. On the grammar definition level

they allocate the means of defining the language gram-

mars. Examples for elements on this level are EBNF

or in our case Definition 1 and Definition 2 concern-

ing the formal definitions of a modeling language and

a model. The grammars residing on this level are used

in the next lower level of language definition. Here we

can see not only model representation grammars but

also metamodel representation grammars. An example

for a model representation grammar is the formalized

Petri Net language from Example 1, an example for a

metamodel representation grammar is Definition 3 of

M2FOL both using the proposed formalism in Definition

Formalizing the Four-layer Metamodeling Stack – Potential and Benefits 11

1 as grammar definition tool. On the lowest level of lan-

guage usage we find instances of these languages: the

Petri Net model from Example 2 as a modeling lan-

guage representation and the metamodel of Petri Net

from Example 3 as a metamodeling language repre-

sentation defined by means of M2FOL. An example of

a meta2modeling language representation on this level

is the metamodel of M2FOL also defined by means of

M2FOL. This shows that M2FOL is a metamodel represen-

tation grammar as well as a meta2model representation

grammar. The algorithm presented in Table 1 allows for

the automatic derivation of the language syntax of a

model representation grammar on the language defini-

tion level from a metamodeling language representation

on the language usage level.

5 Potential and Benefits of Formalized

Conceptual Modeling Languages

In this section we give an outlook to several research

topics potentially benefiting from formalizing concep-

tual modeling languages with the proposed formalism

– these are language interleaving and consistency, op-

erations on models, and translators of platform inde-

pendent formalizations to platform specific code. For

this purpose, we make use of established concepts from

formal language theory. For reasons of brevity we will

not discuss all topics in detail and will restrict to an

extensive elaboration only for the first topic of interest:

5.1 Language Interleaving and Consistency

Models are means to manage information in highly com-

plex systems in business modeling, in software engineer-

ing and many other fields. The solution to cope with

complexity is often seen in the distribution and frag-

mentation of information between different models or

views possibly in different modeling languages, thereby

raising the issue of keeping the models consistent [1,13,

37].

In the following we demonstrate that language in-

terleaving and the definition of consistency constraints

can be easily realized in formalized conceptual mod-

eling languages. Depending on the initial situation we

can distinguish top-down approaches, where a newly de-

fined or existing language is segmented in several sub-

languages or views, and bottom-up approaches, where

existing languages are interleaved and their metamod-

els are amalgamated and equipped with additional con-

straints [47]. We will discuss the first approach briefly

and exemplify the second one in a case study.

5.1.1 Top-Down Approach

Expressed in our formalism the top-down approach

means to restrict the signature Σ of a given language

L to subsets Σ1 and Σ2 of the signature. When work-

ing in one view, i.e. with a sublanguage L|Σi , we are

restricted only to the types appearing in Σi. Note that

we also have to remove relation types, if their source or

target object type was excluded from the signature as

well as for attribute types, if their source type or value

type was excluded. All constraints considering unavail-

able types have to be removed. Note also that the signa-

tures Σi of the sublanguages do not have to be disjoint.

While restricting to a sublanguage L|Σiand thereby

restricting to a concrete view on a system under study

we are still interesting in the model as a whole. So we

assume that for each view of L|Σi there exist correlated

models in the other views L|Σjbeing dependent on each

other. Therefore we need pairwise constraints between

the possible views always considering the signatures of

the two relevant languages. If the signatures are not

disjoint these constraints contain isomorphisms of ele-

ments with a common type to keep the shared structure

consistent.

5.1.2 Bottom-Up Approach

Expressed in our formalism the bottom-up approach

means to fusion the signatures of two given languages

L1 and L2. The interleaving of models and their lan-

guage reaches from simply referencing to elements in

other models to a highly dependent content and struc-

ture of models in both directions. There exist different

techniques to link conceptual modeling languages [1].

There are also different techniques in the field of logic

on how to combine formal languages, e.g. [3,42]. The

presented attempt is mainly inspired by the former ref-

erence.

Uniting two given languages L1 and L2 requires

uniting their signatures Σ1 and Σ2. When doing so,

we have to take care for types T occurring in both

languages. To stay compatible with existing models we

keep both types and rename them to T1 and T2. Fur-

thermore we introduce new function symbols i : T1 →T2. These functions are required to be bijective as we

assume, that we want to depict the same situation with

both views, i.e. sublanguages.

With this union the sets of object types and rela-

tion types of the new language L are fixed. Also the

inheritance relations do not change and stay separated

for both initial languages. To create new references and

consistency constraints we may introduce new attributes

A with FA : Tdom → Tval, where attributed type Tdom

12 Victoria Doller

Fig. 7: Language Definition and Model Hierarchy adapted from [45]

and value domain Tval might stem from different ini-

tial languages. To define the attributes and constraints

as required we might also have to introduce new prod-

uct types in SD and additional function and relation

symbols in F and R respectively.

In summary, the newly obtained signature Σ for the

language L looks as follows:

– Σ = {S,F ,R, C} with S = SO ∪ SR ∪ SD;

– with SO = S1O ∪ S2O and SR = S1R ∪ S2R;

– the set of data types SD ⊃ S1D ∪ S2D furthermore

contains all newly defined product types T ∈ (SO ∪SR ∪ SD)i;

– the set F ⊃ F1 ∪ F2 additionally contains the new

function symbols;

– the set R ⊃ R1 ∪R2 in addition contains the newly

created relation symbols;

The constraints C are extended with the requirement

that the mappings of the coinciding types i : T1 →T2 are bijective, as well as further defined postulates

necessary for information consistency.

5.1.3 Case Study

We will demonstrate the procedure of interleaving on a

case study of UML Class Diagrams and Sequence Dia-

grams. First we have to formalize the initial languages

CD of Class Diagrams and SD of Sequence Diagrams.

For an easier comprehension the considered signatures

restrict to a subset of the original UML concepts rele-

vant for the connection of the two languages, see Figure

8.

Example 5 The UML Class Diagram Language CDFor our purpose it suffices to consider in the signature

ΣCD only one object type Class (Cl) and one rela-

tion type Association (As) connecting classes. Besides

the plain data types Visibility (V) and SimpleType

(ST), class diagrams also provide the construct of at-

tributes and operations of classes exhibiting a complex

structure themselves. We define a data type called At-

tribute (At) which is a tuple of an element of type

Visibility and the value of the attribute, i.e. an object

of ComplexType (CT) = SimpleType∪Class. Fur-

thermore we need a data type Operation (Op) which

is a tuple of an element of type Visibility, a return

type element in CT, and arbitrary many parameters

of type CT. For these parameters we use the union

of all product types (CT)i. For reasons of brevity we

skip the explicit definition of all intermediate product

types in the signature and just refer to⋃i(CT)i. As

classes can have several (distinct) attributes and op-

erations, the model attributes C(lass)At(tributes) and

C(lass)Op(erations) point to the powersets of types

℘(AT) and ℘(OP).

Formalizing the Four-layer Metamodeling Stack – Potential and Benefits 13

(a) (b)

Fig. 8: Simplified metamodels of the UML Class Diagram (a) and Sequence Diagrams (b)

The signature of CD looks as follows:

ΣCD = {S,F ,R, C},S = SO ∪ SR ∪ SD (38)

SO = {Class},SR = {Association}, (39)

SD = {Visibility,SimpleType,

ComplexType = ST ∪Cl,Attribute = V×CT,

Operation = V×⋃i

(CT)i ×CT}, (40)

F = {FAss : As→ Cl, FAs

t : As→ Cl,

FCAt : Cl→ ℘(At), FCOp : Cl→ ℘(Op)} (41)

C = {+,−,∼, String, Integer,Real, Boolean} (42)

Thereby, +,−,∼ are of type Visibility and String, In-

teger, Real, and Boolean are of type SimpleType.

We do not need any postulates on the language CD.

Example 6 The UML Sequence Diagram Language SDAlso in this example we restrict to the simplified case

of having only one object type Lifeline (Ll) and two

relation types Message (Msg) and Replymessage

(Rmsg) both connecting lifelines. The temporal se-

quence of messages usually captured in the graphical

order of arrows is defined in the attribute Sendtime

(MSt and RSt) with value domain N assigning a point

in time to the messages and replymessages. To be able

to compare sendtimes we need the usual order relation

<time⊂ N×N and the usual addition function +timein

the signature:

ΣSD = {S,F ,R, C}, S = SO ∪ SR ∪ SD (43)

SO = {Lifeline}, SD = {N}, (44)

SR = {Message,Replymessage}, (45)

F = {FMSt : Msg→ N, FRSt : Rmsg→ N,

FMsgs : Msg→ Ll, FMsg

t : Msg→ Ll,

FRmsgs : Rmsg→ Ll, FRmsg

t : Rmsg→ Ll

F+time: N× N→ N} (46)

R = {<time⊂ N× N}, C = {0, 1, 2, ...} of type N (47)

To ensure a reasonable temporal flow of messages

we need two language constraints:

∀x, y ∈Msg(FMSt(x) <time FMSt(y)∨

FMSt(y) <time FMSt(x)) ∨ x = y (48)

∀x ∈ Rmsg,∃y ∈Msg

(FMSt(y) +time 1 = FRSt(x)) (49)

Equation 48 restricts diagrams to be sequential, so no

two messages are sent at the same time. Equation 49

forces the message flow to be synchronous.

Example 7 The Interleaved Modeling Language CD ]SDIn the case of UML class diagrams and sequence dia-

grams we do not have to take care of identical types.

We define several new attributes to bind lifelines in a

sequence diagram to the classes in the corresponding

class diagram: a reference L(ife)l(ine)Cl(as), a refer-

ence Cal(led)Op(eration) of a message, and a reference

Re(turn)Ty(pe) of a replymessage.

FLlCl : Lifeline→ Class (50)

FCalOp : Message→ Operation (51)

FReTy : Replymessage→ ComplexType (52)

These references of course require some new constraints.

To formulate these we need a new relation symbol ∈Opand a new function symbol Fpr projecting an element

of type Operation to its returntype, i.e. the last value

of the tuple.

∈Op⊂ Operation× ℘(Operation), (53)

Fpr : Operation→ ComplexType (54)

∀x = (x1, . . . , xn) ∈ Operation Fpr(x) = xn (55)

14 Victoria Doller

With these symbols we can define the additional

constraints:

∀x ∈Msg

(FCalOp(x) ∈Op FCOp(F class(FMest (x)))) (56)

∀x ∈ Rmsg ∃y ∈Msg(FMSt(y) + 1 = FRSt(x)∧FReTy(x) = Fpr(F

CalOp(y))) (57)

Equation 56 ensures that a message can only call op-

erations of the addressed class. Equation 57 guarantees

that each replymessage follows a message and the re-

turntype is exactly the returntype of the called opera-

tion.

The complete language CD ] SD looks as follows:

ΣCD]SD = {S,F ,R, C},SO = {Class,Lifeline}, (58)

SR = {Association,Message,Replymessage} (59)

SD = {Visibility,SimpleType,ComplexType,

Attribute,Operation,N} (60)

F = {FAss : As→ Cl, FAs

t : As→ Cl,

FCAt : Cl→ ℘(At), FCOp : Cl→ ℘(Op),

FMsgs : Msg→ Ll, FMsg

t : Msg→ Ll,

FRmsgs : Rmsg→ Ll, FRmsg

t : Rmsg→ Ll,

FMSt : Msg→ N, FRSt : Rmsg→ N,FLlCl : Lifeline→ Class

FCalOp : Message→ Operation

FReTy : Replymessage→ ComplexType

Fpr : Operation→ ComplexType

F+time: N× N→ N} (61)

R = {<time⊂ N× N,∈Op⊂ Op× ℘(Op)} (62)

C = {+,−,∼, String, Integer,Real, Boolean,0, 1, 2, ...} (63)

With the newly generated language each model con-

tains all information of both views, the structural view

of class diagrams as well as the procedural view of se-

quence diagrams. Of course when viewing the model we

only consider the model restricted to a sublanguage, CDor SD but in the background all elements of both re-

side in the “supermodel”. 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 un-

derlying model as proposed by Burger et al. [37,47].

5.2 Operations on Models

Model functionality is a crucial point to amplify the

value of models beyond mere pictures [5]. One of the

most prominent examples is the firing mechanism on

Petri Nets [54]. Also many domain-specific languages

gain in value by the offered model operations. For ex-

ample, model operations in the sense of model to model

transformations play a crucial role in Model Driven

Software Engineering [10, chapter 8]. Nevertheless, op-

erations on models are often out of scope or simply

ignored in formalizations. An exception is the theory of

graph grammars and graph transformations [28]. For-

malisms based on logic are often critiqued for not being

able to capture the operational syntax of modeling lan-

guages. We argue that this is not an inevitable inabil-

ity of these approaches and show some ideas how op-

erations on models can also be supported by concepts

from logic.

5.2.1 Structural Events and Domain Events

We adopt the notion of Olive [50, chapter 11] who de-

fines domain events, i.e. semantically and syntactically

admissible operations on models, by decomposing them

into the smallest possible changes in a model, the so

called structural events. While Olive only names dele-

tion and insertion of objects and relations as structural

events, for our purpose in the formalism at hand we

also have to consider the change of attribute values as

a third variant.

Given a language L we define M as the set of valid

models, i.e. those language-structures fulfilling the con-

straints, and M− as the set of all possible language

constructs not necessarily complying to the postulates.

Domain events are therefore mappings de : M → Mwhereas structural events are functions on arbitrary

constructs:

CreateType :M− →M−

SetobjAttr[value] :M− →M−

Deleteobj :M− →M−

Consider again model M of example 2. A valid domain

event is the firing of the transition Serve. This event

is the concatenation of the three structural events of

changing the attribute values

SetWaittok [1] ◦ SetIdletok [0] ◦ SetBusytok [1](M) = M′.

None of these structural events alone is semantically

valid, but together they form a semantically and syn-

tactically admissible operation. This also shows, that

Formalizing the Four-layer Metamodeling Stack – Potential and Benefits 15

there are many structural events (we can set the at-

tribute tokens of each place to any number we like) but

much less domain events.

Another point to be considered are pre- and post-

conditions of domain events. To capture these in a gene-

ric way we can use concepts from temporal logic [40].

With the logical operators from temporal logic we are

able to formulate postulates considering both states of

a model, before and after the application of a domain

event, and define dependencies between both.

Concatenations of domain events form sequences of

valid models

M0 7→ M1 7→ M2 7→ · · · .

In Petri Nets for example the firing of a transition is

a domain event. Therefore these sequences are of spe-

cial interest as they reveal inaccessible states and final

markings in a net when starting from a concrete model.

This is closely related to the concept of marking graphs

in Petri Nets [54, Sec. 2.8].

5.3 Translators

Another salient benefit of having an unambiguous and

complete formalization of a modeling language is that

it can serve as a single point of platform independent

specification, thereby being precise enough to be auto-

matically processed by a machine. Of course a model-

ing language without a technical tool supporting the

creation and execution of models is very much useless

for the target audience. When implementing a language

many engineers have made the experience that available

metamodeling platforms differ heavily in available con-

cepts and functionality and thereby impose more or less

severe restrictions on the final product [36]. So the im-

plementation forces the engineer to think in the frame

of the used platform and to modify the language to fit to

the given meta2model and available model processing

algorithms. A further drawback of this current practice

is the fact, that each effort of implementation is lost,

whenever the language has to be transferred to another

platform, may it be caused by missing functionality for

new language features or a cessation of platform sup-

port.

With the formalization of a language as stipulated

by the AMME lifecylce of modeling methods we derive

a sort of platform independent code and close the gap

between the specification document and the final imple-

mentation. By using the proposed formalism the spec-

ification of the main concepts is unified and therefore

offers the possibility to be translated to any metamod-

eling platform. Thus, the language specification stays

on a platform-agnostic level and the complexity of the

platform-specificity can be outsourced to a platform-

specific translator. The feasibility of this endeavour has

been shown by Visic et al. [63,64]. When platforms

change only the translator has to be adapted but not

the platform-independent conceptualization of a lan-

guage.

While Visic et al. stay at the level of translators of

language syntax our attempt on the formalization of

model operations shown in Section 5.2 holds promise

to be able to integrate an automatic translation of the

functionality of modeling languages. The decomposi-

tion of domain events into the three types of structural

events allows for an automatization of translating the

modeling language specification to a concrete tool as

most platforms offer methods for creating or deleting

elements or changing attributes.

6 Evaluation

To evaluate the proposed formalism we recap the re-

quirements mentioned in the Section 1.2: 1) The for-

malism has to be complete regarding the general build-

ing blocks of a language, 2) it has to be faithful to the

character of modeling languages as such, and 3) it must

be generic in a way that it admits the formalization of

any language.

The proposed formalism comprises the core con-

cepts constituting a modeling language. These were cho-

sen based on a survey by Kern et al. [36] and the con-

cept discussion by Olive [50]. We restricted to the most

common concepts, i.e. those appearing in at least half

of the surveyed metamodeling platforms in [36]. In Sec-

tion 3 we also listed the concepts for future integration.

Regarding the first requirement we conclude that the

proposed definition of a modeling language is not yet

complete, but depicts the most relevant core. This is

also shown by the realizability of several case studies

depicted in this paper.

In current scientific literature there is a consensus

about modeling languages being formal languages by

nature [16,25,50,52,62]. This supports our choice of

using logic as basis for the formalism and underpins

the adherence to the linguistic character of languages

including the alphabet and the instantiation relation.

Additional affirmation is given by the multitude of prac-

tical constructs and methods of formal language theory

and its straightforward applicability to current research

issues, which was exemplarily shown in Section 5.

The generic realizability of arbitrary modeling lan-

guages is provided by construction, as the concepts in-

tegrated in the formalism stem from literature concern-

ing conceptual modeling in general. A realization of the

16 Victoria Doller

three divergent use cases in this paper and several more

unpublished use cases conducted by the authors fur-

thermore backs this claim.

The empirical evaluation of feasibility and usability

so far has been mainly conducted via the realization

of prototypical case studies of various domains (not all

published). Three of them were shown in this paper.

Other cases guiding the advancement of the formal-

ism are for example ER-diagrams starting in [18]. In

the light of language interleaving we formalized a lan-

guage for modeling smart cities [7] besides the UML

case study. To investigate the formalization of model

operations we formalized Petri Nets and ProVis, a tool

for math education providing sophisticated methods to

process statistical diagrams [20].

A proof of concept for the significance of the pre-

sented formalism can be given by an implementation

of translators to at least two different metamodeling

platforms especially if we are able to integrate a spec-

ification of model operations. Such a tool is currently

under design.

In parallel, a more outreaching empirical evaluation

is currently being designed. We will conduct a study

with around sixty business informatics students in a

university course about metamodeling. The students

will be asked to apply the proposed formalism to the

modeling language they develop during the course and

to evaluate complexity and limitations.

7 Conclusion

In this paper we presented a definition of modeling lan-

guages as formal languages L with a signature Σ in the

sense of logic. The concept of a L-structure canonically

corresponds to the instantiation relation between model

and language and led us to the definition of models as

L-structures. To illustrate the specification of formal

modeling languages we demonstrated the definition on

the Petri Net modeling language. We applied the defi-

nition also on the meta level and developed M2FOL – a

formal modeling language for metamodels. M2FOL mod-

els are precise and complete and therefore we were able

to show how to algorithmically derive a formal mod-

eling language signature from its metamodel. M2FOL is

self-describing, which can be seen by applying the algo-

rithm to its own metamodel.

After the introduction of the formalism we gave an

outlook to the potential and benefits of formalized mod-

eling languages using the approach at hand. We ad-

dressed the topic of language interleaving and consis-

tency. Established methods from formal language the-

ory provide methods to create an interleaved formal

language from existing ones. We illustrated the process

on a case study using UML Class Diagrams and Se-

quence Diagrams.

Another topic with high potential for the automati-

zation of language implementation is the formalization

of model operations. We outlined how to break down al-

gorithms on models in smallest possible building blocks

able to be formalized. This allows model operations to

become an integral part of the formal language specifi-

cation.

This formal specification – syntax as well as oper-

ations – precise enough to be processed by a machine

yet platform-independent, additionally allows us to de-

velop platform-specific translators, transferring the sin-

gle source of language specification to realizations on

different platforms.

With this common practice of defining metamod-

els and modeling languages, these languages become

comparable, reusable, and open to modularization. To

broaden the conceptual capabilities of our approach we

will further investigate more subtle concepts to be inte-

grated into the definition. These are for example pow-

ertypes [50, chapter 17.2], the concepts of mixins and

extenders for modular metamodels as proposed in [65],

or the structural types of relations identified in [61]. For

a practical application of the language M2FOL, a suitable

tool for transforming graphical metamodels into formal

ones will be developed.

Finally, by using a sophisticated mathematical the-

ory as grounding for the definition of modeling lan-

guages we can use this knowledge stack as resource to

further establish a formal foundation for modeling lan-

guages. We can investigate the subclass of conceptual

modeling languages in the class of formal languages and

approach old problems with new tools.

References

1. Awadid, A., Nurcan, S.: Consistency requirements inbusiness process modeling: a thorough overview. Soft-ware and Systems Modeling 18(2), 1097–1115 (apr 2019).https://doi.org/10.1007/s10270-017-0629-2

2. Baader, F., Calvanese, D., McGuinness, D.L., Nardi,D., Patel-Schneider, P.F. (eds.): The Description LogicHandbook. Cambridge University Press, Cambridge(2007). https://doi.org/10.1017/CBO9780511711787

3. Baader, F., Ghilardi, S.: Connecting many-sorted the-ories. The Journal of Symbolic Logic 72(2), 535–583(2007)

4. BOC: ADOxx Metamodelling Platform (2021), https:

//www.adoxx.org

5. Bork, D., Buchmann, R.A., Karagiannis, D., Lee, M.,Miron, E.T.: An Open Platform for Modeling MethodConceptualization: The OMiLAB Digital Ecosystem.Communications of the Association for Information Sys-tems 44(1), 673–679 (2019)

Formalizing the Four-layer Metamodeling Stack – Potential and Benefits 17

6. Bork, D., Fill, H.G.: Formal Aspects of Enterprise Model-ing Methods: A Comparison Framework. In: 47th HawaiiInternational Conference on System Sciences. pp. 3400–3409 (jan 2014)

7. Bork, D., Fill, H.G., Karagiannis, D., Miron, E.T., Tan-touris, N., Walch, M.: Conceptual Modelling for SmartCities: A Teaching Case. Interaction Design and Archi-tecture(s) pp. 10–28 (dec 2015)

8. Bork, D., Karagiannis, D., Pittl, B.: A Survey of Model-ing Language Specification Techniques. Information Sys-tems 87, 101425 (jan 2020)

9. Brachman, R.J., Schmolze, J.G.: An Overview ofthe KL-ONE Knowledge Representation System.In: Mylopolous, J., Brodie, M. (eds.) Readings inArtificial Intelligence and Databases, pp. 207–230.Morgan Kaufmann, San Francisco (CA) (1989).https://doi.org/https://doi.org/10.1016/B978-0-934613-53-8.50019-4

10. Brambilla, M., Cabot, J., Wimmer, M.: Model-Driven Software Engineering in Practice: Sec-ond Edition. Synthesis Lectures on Soft-ware Engineering 3(1), 1–207 (mar 2017).https://doi.org/10.2200/s00751ed2v01y201701swe004

11. Buchmann, R.A., Ghiran, A.M., Doller, V., Karagiannis,D.: Conceptual Modeling Education as a “Design Prob-lem”. Complex Systems Informatics and Modeling Quar-terly (21), 21–33 (dec 2019)

12. Burger, E.: Flexible views for view-based model-drivendevelopment. KIT Scientific Publishing (nov 2014).https://doi.org/10.5445/KSP/1000043437

13. Burger, E., Henss, J., Kuster, M., Kruse, S., Happe,L.: View-based model-driven software development withModelJoin. Software and Systems Modeling 15(2), 473–496 (may 2016). https://doi.org/10.1007/s10270-014-0413-5

14. Choe, Y., Lee, S., Lee, M.: SAVE: An Environment forVisual Specification and Verification of IoT. In: IEEE20th International Enterprise Distributed Object Com-puting Workshop, EDOCW. pp. 269–276 (2016)

15. Clyde, S.W., Embley, D.W., Liddle, S.W., Woodfield,S.N.: OSM-Logic: A Fact-Oriented, Time-DependentFormalization of Object-oriented Systems Modeling. In:Conceptual Modelling and Its Theoretical Foundations,pp. 151–172. Springer, Berlin, Heidelberg (2012)

16. Delcambre, L.M.L., Liddle, S.W., Pastor, O., Storey,V.C.: A reference framework for conceptual modeling. In:Trujillo, J.C., Davis, K.C., Du, X., Li, Z., Ling, T.W., Li,G., Lee, M.L. (eds.) Conceptual Modeling. ER 2018. Lec-ture Notes in Computer Science. vol. 11157 LNCS, pp.27–42. Springer, Cham (2018)

17. Delcambre, L.M.L., Liddle, S.W., Pastor, O., Storey,V.C.: Characterizing Conceptual Modeling Research.In: Panetto, H., Debruyne, C., Hepp, M., Lewis, D.,Ardagna, C.A., Meersman, R. (eds.) On the Move toMeaningful Internet Systems: OTM 2019 Conferences.pp. 40–57. Springer, Cham (2019)

18. Doller, V.: Formal Semantics for Conceptual ModelingLanguages based on Model Theory. In: Proceedings ofthe Doctoral Consortium Papers Presented at the 11thIFIP WG 8.1 Working Conference on the Practice ofEnterprise Modelling, PoEM 2018. vol. 2234, pp. 61–73.CEUR-WS (2018)

19. Doller, V.: M2FOL: A Formal Modeling Language forMetamodels. In: Bork, D., Grabis, J. (eds.) The Practiceof Enterprise Modeling. PoEM 2020. Springer (2020)

20. Doller, V.: ProVis - Probability Visualized: Ein Mod-ellierungswerkzeug fur den Stochastikunterricht (ProVis

- Probability Visualized: A Modeling Tool for TeachingStochastics). In: Michael, J., Bork, D., Fill, H.G., Fettke,P., Karagiannis, D., Kopke, J., Koschmider, A., Mayr,H.C., Rehse, J.R., Reimer, U., Striewe, M., Tropmann-Frick, M., Ullrich, M. (eds.) Companion Proceedings ofModellierung 2020 Short, Workshop and Tools & DemoPapers co-located with Modellierung 2020. CEUR Work-shop Proceedings, vol. 2542, pp. 222–226. CEUR-WS.org(2020), http://ceur-ws.org/Vol-2542/MOD20-TuD7.pdf

21. Enderton, H.B.: A Mathematical Introduction To Logic.Harcourt/Academic Press, San Diego, 2nd edn. (2001)

22. Fill, H.G., Redmond, T., Karagiannis, D.: FDMM: A for-malism for describing ADOxx meta models and models.In: ICEIS 2012 - Proceedings of the 14th InternationalConference on Enterprise Information Systems. vol. 3,pp. 133–144 (2012)

23. Frank, U.: Domain-specific modeling languages: Require-ments analysis and design guidelines. In: Reinhartz-Berger, I., Sturm, A., Clark, T., Cohen, S., Bettin, J.(eds.) Domain Engineering: Product Lines, Languages,and Conceptual Models, pp. 133–157. Springer BerlinHeidelberg (2013)

24. Frank, U., Strecker, S., Fettke, P., Vom Brocke, J.,Becker, J., Sinz, E.: The research field ”modeling businessinformation systems”: Current challenges and elements ofa future research agenda. Business and Information Sys-tems Engineering 6, 39–43 (2014)

25. Guarino, N., Guizzardi, G., Mylopoulos, J.: On the Philo-sophical Foundations of Conceptual Models. In: Proceed-ings of the 29th International Conference on InformationModelling and Knowledge Bases, EJC 2019. Frontiers inArtificial Intelligence and Applications, vol. 321, pp. 1–15. IOS Press (2019)

26. Guizzardi, G.: On ontology, ontologies, conceptualiza-tions, modeling languages, and (meta)models. In: Vasile-cas, O., Eder, J., Caplinskas, A. (eds.) Selected Pa-pers from the Seventh International Baltic Conference,DB&IS. pp. 18–39. IOS Press (2007)

27. Guizzardi, G.: Logical, ontological and cognitive aspectsof object types and cross-world identity with applicationsto the theory of conceptual spaces. In: Applications OfConceptual Spaces: The Case For Geometric KnowledgeRepresentation, pp. 165–186. Springer (jan 2015)

28. Heckel, R., Taentzer, G.: Graph Transformation for Soft-ware Engineers. Springer International Publishing, Cham(2020). https://doi.org/10.1007/978-3-030-43916-3

29. Herrmann, C., Krahn, H., Rumpe, B., Schindler, M.,Volkel, S.: An algebraic view on the semantics of modelcomposition. In: Model Driven Architecture-Foundationsand Applications (ECMDA-FA). pp. 99–113. Springer(2007)

30. Jackson, E., Sztipanovits, J.: Towards a Formal Founda-tion for Domain Specific Modeling Languages. In: Pro-ceedings of the 6th ACM & IEEE International Confer-ence on Embedded Software. pp. 53–62. EMSOFT ’06,ACM, New York, NY, USA (2006)

31. Jackson, E., Sztipanovits, J.: Formalizing the structuralsemantics of domain-specific modeling languages. Soft-ware and Systems Modeling 8(4), 451–478 (dec 2009).https://doi.org/10.1007/s10270-008-0105-0

32. Jouault, F., Bezivin, J.: KM3: a DSL for MetamodelSpecification. In: International Conference on FormalMethods for Open Object-Based Distributed Systems,FMOODS 2006. pp. 171–185. Springer, Berlin, Heidel-berg (2006)

33. Kampars, J., Zdravkovic, J., Stirna, J., Grabis, J.: Ex-tending organizational capabilities with Open Data to

18 Victoria Doller

support sustainable and dynamic business ecosystems.Software and Systems Modeling 19(2), 371–398 (mar2020). https://doi.org/10.1007/s10270-019-00756-7

34. Karagiannis, D.: Conceptual modelling methods: TheAMME agile engineering approach. In: Informatics inEconomy. IE 2016. Lecture Notes in Business InformationProcessing. vol. 273, pp. 3–19. Springer Verlag (2018)

35. Karagiannis, D., Burzynski, P., Utz, W., Buchmann,R.A.: A Metamodeling Approach to Support the En-gineering of Modeling Method Requirements. In: 27thIEEE International Requirements Engineering Confer-ence. pp. 199–210 (2019)

36. Kern, H., Hummel, A., Kuhne, S.: Towards a compar-ative analysis of meta-metamodels. In: Proceedings ofthe compilation of the co-located workshops on DSM’11,TMC’11, AGERE! 2011, AOOPES’11, NEAT’11, &VMIL’11. pp. 7–12. ACM (2011)

37. Klare, H., Kramer, M.E., Langhammer, M., Werle, D.,Burger, E., Reussner, R.: Enabling consistency in view-based system development — The VITRUVIUS ap-proach. Journal of Systems and Software 171, 110815(jan 2021). https://doi.org/10.1016/j.jss.2020.110815

38. Koubarakis, M., Borgida, A., Constantopoulos, P., Do-err, M., Jarke, M., Jeusfeld, M.A., Mylopoulos, J., Plex-ousakis, D.: A retrospective on Telos as a metamodelinglanguage for requirements engineering. Requirements En-gineering (2020)

39. Koubarakis, M., Mylopoulos, J., Stanley, M., Borgida, A.:Telos: Features and Formalization. Tech. rep., Technicalreport KRRTR- 89-4, Department of Computer Science,University of Toronto (1989)

40. Kroger, F.: Temporal Logic and State Systems. Springer-Verlag, Berlin Heidelberg, 1 edn. (2008)

41. Kuhne, T.: Matters of (meta-) modeling. Software andSystems Modeling 5(4), 369–385 (2006)

42. Kutz, O., Lutz, C., Wolter, F., Zakharyaschev,M.: ε-connections of abstract description systems.Artificial Intelligence 156(1), 1–73 (jun 2004).https://doi.org/10.1016/j.artint.2004.02.002

43. Lara, P., Sanchez, M., Villalobos, J.: Bridging the IT andOT Worlds using an extensible modeling language. In:Conceptual Modeling. ER 2016. Lecture Notes in Com-puter Science. vol. 9974, pp. 122–129. Springer, Cham(nov 2016)

44. Leroy, D., Bousse, E., Wimmer, M., Mayerhofer, T.,Combemale, B., Schwinger, W.: Behavioral interfaces forexecutable DSLs. Software and Systems Modeling 19(4),1015–1043 (jul 2020). https://doi.org/10.1007/s10270-020-00798-2

45. Mayr, H.C., Thalheim, B.: The triptych of conceptualmodeling. Software and Systems Modeling 2020 pp. 1–18(nov 2020). https://doi.org/10.1007/S10270-020-00836-Z

46. Mazzola, G., Milmeister, G., Weissmann, J.: Compre-hensive mathematics for computer scientists 1: Sets andnumbers, graphs and algebra, logic and machines, lin-ear geometry (second edition). Springer Berlin Heidel-berg (2006)

47. Meier, J., Klare, H., Tunjic, C., Atkinson, C., Burger,E., Reussner, R., Winter, A.: Single underlying mod-els for projectional, multi-view environments. In: MOD-ELSWARD 2019 - Proceedings of the 7th Interna-tional Conference on Model-Driven Engineering andSoftware Development. pp. 119–130. SciTePress (2019).https://doi.org/10.5220/0007396401190130

48. Mouratidis, H., Giorgini, P.: Secure Tropos: A security-oriented extension of the Tropos methodology. In: Inter-national Journal of Software Engineering and Knowledge

Engineering. vol. 17, pp. 285–309. World Scientific Pub-lishing Company (2007)

49. Object Management Group (OMG): Object ConstraintLanguage – Version 2.4. (2014), https://www.omg.org/

spec/OCL/2.4/PDF

50. Olive, A.: Conceptual modeling of information systems.Springer-Verlag, Berlin Heidelberg (2007)

51. Paczona, M., Mayr, H.C.: Model-Driven MechatronicSystem Development. In: IEEE 15th International Con-ference on Automation Science and Engineering (CASE).pp. 1730–1736. IEEE (aug 2019)

52. Partridge, C., Gonzalez-Perez, C., Henderson-Sellers, B.:Are Conceptual Models Concept Models? In: ConceptualModeling. ER 2013. Lecture Notes in Computer Science.vol. 8217, pp. 96–105. Springer, Berlin, Heidelberg (nov2013)

53. Ralyte, J., Leonard, M.: Evolution Models for Informa-tion Systems Evolution Steering. In: Poels, G., Gailly,F., Serral Asensio, E., Snoeck, M. (eds.) The Practice ofEnterprise Modeling, PoEM 2017. pp. 221–235. Springer,Cham (2017)

54. Reisig, W.: Understanding Petri Nets: ModelingTechniques, Analysis Methods, Case Studies, vol.9783642332. Springer-Verlag Berlin Heidelberg (jul2013). https://doi.org/10.1007/978-3-642-33278-4

55. Rrenja, A., Matulevicius, R.: Pattern-Based Security Re-quirements Derivation from Secure Tropos Models. In:Ralyte, J., Espana, S., Pastor, O. (eds.) The Practice ofEnterprise Modeling. PoEM 2015. vol. 235, pp. 59–74.Springer Verlag (2015)

56. Sandkuhl, K., Fill, H.G., Hoppenbrouwers, S., Krogstie,J., Leue, A., Matthes, F., Opdahl, A.L., Schwabe, G.,Uludag, O., Winter, R.: Enterprise Modelling for theMasses – From Elitist Discipline to Common Practice. In:Horkoff, J., Jeusfeld, M., Persson, A. (eds.) The Practiceof Enterprise Modeling. PoEM 2016. vol. 267, pp. 225–240. Springer Verlag (2016)

57. Sandkuhl, K., Fill, H.G., Hoppenbrouwers, S., Krogstie,J., Matthes, F., Opdahl, A., Schwabe, G., Uludag, O.,Winter, R.: From Expert Discipline to Common Prac-tice: A Vision and Research Agenda for Extending theReach of Enterprise Modeling. Business and InformationSystems Engineering 60, 69–80 (2018)

58. Schon, H., Zdravkovic, J., Stirna, J., Strahringer, S.: Arole-based capability modeling approach for adaptive in-formation systems. In: Gordijn, J., Guedria, W., Proper,H. (eds.) The Practice of Enterprise Modeling. PoEM2019. vol. 369, pp. 68–82. Springer (nov 2019)

59. Sprinkle, J., Rumpe, B., Vangheluwe, H., Karsai, G.:Metamodelling: State of the Art and Research Chal-lenges. In: Lecture Notes in Computer Science. vol. 6100LNCS, pp. 57–76 (2010)

60. Stirna, J., Zdravkovic, J., Grabis, J., Sandkuhl, K.: Devel-opment of Capability Driven Development Methodology:Experiences and Recommendations. In: Poels, G., Gailly,F., Serral Asensio, E., Snoeck, M. (eds.) The Practice ofEnterprise Modeling, PoEM 2017. pp. 251–266. Springer,Cham (2017)

61. Thalheim, B.: Towards a Theory of Conceptual Mod-elling. In: Conceptual Modeling. ER 2009. Lecture Notesin Computer Science. vol. 5833 LNCS, pp. 45–54.Springer, Berlin, Heidelberg (2009)

62. Thalheim, B.: The Theory of Conceptual Models, theTheory of Conceptual Modelling and Foundations ofConceptual Modelling. In: Handbook of ConceptualModeling, pp. 543–577. Springer Berlin Heidelberg (2011)

Formalizing the Four-layer Metamodeling Stack – Potential and Benefits 19

63. Visic, N.: Language-Oriented Modeling Method Engi-neering. Ph.D. thesis, University of Vienna (2016)

64. Visic, N., Fill, H.G., Buchmann, R.A., Karagiannis, D.: Adomain-specific language for modeling method definition:From requirements to grammar. In: Proceedings - Inter-national Conference on Research Challenges in Informa-tion Science. vol. 2015-June, pp. 286–297. IEEE Com-puter Society (jun 2015)

65. Zivkovic, S., Karagiannis, D.: Mixins and Extenders forModular Metamodel Customisation. In: Proceedings ofthe 18th International Conference on Enterprise Informa-tion Systems. pp. 259–270. Science and and TechnologyPublications (2016)