Multi-level Modeling without Classical Modeling Facilities

Ferenc A. Somogyi

1 a

, Zolt

an Theisz

2 b

, S

andor B

acsi

1 c

, Gergely Mezei

1 d

and D

aniel Palatinszky

1 e

Department of Automation and Applied Informatics, Budapest University of Technology and Economics,

Muegyetem rkp. 3., Budapest, Hungary

Evopro Systems Engineering Ltd., Budapest, Hungary

Keywords:

Multi-level Modeling, Multi-layer Modeling, Potency Notion.

Abstract:

Multi-level modeling is a modeling paradigm that has been becoming more and more popular in recent years.

The ultimate goal of multi-level modeling is to reduce accidental complexity that may arise from modeling

methodologies that are not suitable to describe multi-level models. However, currently, most multi-level mod-

eling approaches are dependent on classical modeling facilities, like OMG’s four-level modeling architecture.

The potency notion is one of the most widely-used enablers of multi-level modeling that governs the depth

model elements can be instantiated at. In this paper, we propose an alternative implementation to the ﬁrst in-

carnation of the potency notion, the so-called classic potency notion. Its multi-level nature is mapped into our

multi-layer modeling framework, which liberates it from direct dependence on classical modeling facilities.

We examine the proposed mapping in details and also demonstrate it via a simple case study. This work is

aimed as the ﬁrst step towards a generic multi-level modeling framework where researchers can freely exper-

iment with novel multi-level modeling ideas and can share and compare their results without worrying about

any sorts of tool dependence.

1 INTRODUCTION

Multi-level modeling (Atkinson and K

uhne, 2001) is

a well-established paradigm within the realm of mod-

ern modeling approaches based on the initial core

ideas of OMG’s Model Driven Architecture (MDA)

(MDA, 2001). Multi-level modeling had been origi-

nally conceived as a technical extension to go beyond

the strictly preset four-level meta-model layering pre-

scribed by OMG’s MDA blueprint and related techni-

cal documentation. OMG does not seem to fully em-

brace multi-level modeling and give its ofﬁcial recog-

nition to acknowledge full membership within the

standardized modeling facilities. Thus, it has mostly

remained and has been developed inside the model-

ing research community. Moreover, in recent years,

it has enjoyed a renaissance by the rediscovery of

some of its most successful techniques, such as the

potency notion (Atkinson and K

uhne, 2001; K

uhne*,

https://orcid.org/0000-0001-5491-4412

https://orcid.org/0000-0002-0222-867X

https://orcid.org/0000-0002-4814-6979

https://orcid.org/0000-0001-9464-7128

https://orcid.org/0000-0002-6168-3963

2018). Both theoretical and practical interest in ap-

plying multi-level modeling to real case studies has

been growing not only within, but also beyond the

modeling research community. Therefore, we believe

that the potential of thorough analysis in an effec-

tive research playground for multi-level modeling and

its foundations is beneﬁcial to the academic research

community and – in the longer term – for the industry

as well.

Our motivation of writing this paper has been

mostly inﬂuenced by our interest to look for alter-

natives of doing multi-level modeling in Orthogo-

nal Classiﬁcation Architecture (OCA) (de Lara et al.,

2014). In OCA, entites have two orthogonal classiﬁ-

cal dimensions: the ontological dimension deﬁned by

the modeled domain, and the linguistic dimension de-

ﬁned by the modeling structure. In our understand-

ing, multi-level modeling in OCA is mainly a model-

ing paradigm that is supposed to relax the constraints

of OMG’s four-level modeling stack by the introduc-

tion of additional modeling levels. Hence, as an add-

on supplement to legacy meta-modeling, multi-level

modeling requires every facility of OMG’s model-

ing infrastructure: (1) object-oriented modeling con-

cepts like inheritance and (2) standardized tool sup-

Somogyi, F., Theisz, Z., Bácsi, S., Mezei, G. and Palatinszky, D.

Multi-level Modeling without Classical Modeling Facilities.

DOI: 10.5220/0008973503930400

In Proceedings of the 8th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2020), pages 393-400

ISBN: 978-989-758-400-8; ISSN: 2184-4348

393

port for OMG-style modeling with predeﬁned meta-

levels. Therefore, OCA can be regarded as a pe-

culiarly constructed co-architecture to OMG’s MDA

stack. Namely, OCA integrates multi-level model-

ing into the standard linguistic meta-level setup of

OMG’s MDA framework by the presumption of the

so-called ontological instantiation concept. The main

reason of OCA’s success is the fact that its ontologi-

cal instantiation assumes or prescribes no implicit se-

mantics in OMG’s MDA design, which positions it

clearly against the linguistic instantiation that does re-

quire it. Hence, state-of-the-art MDA tools may be

capable of supporting OCA out-of-the-box. Never-

theless, the orthogonal coupling of the two instanti-

ations also has consequences: on the positive side,

OCA can easily provide smooth integration of multi-

level modeling into the standard modeling frame-

work; on the negative side, OCA’s particular inter-

pretation of multi-level modeling is not semantically

deﬁned within OMG’s MDA meta-modeling frame-

work. Thus, the semantics of ontological instantiation

must be encoded, mainly in an ad-hoc manner, inside

the various modeling tools. Therefore, OCA’s multi-

level modeling is by its very nature tool dependent

without offering any encompassing theory to reunite

the particular implementation ﬂavours of similar or

same multi-level modeling concepts. A good compar-

ison to observe the divergence in semantics of similar

concepts in ontological instantiation is to be found in

(Gerbig et al., 2016).

By analyzing some of the core concepts of OCA’s

multi-level modeling, it may seem almost as obvious

that the potency notion can be regarded as the princi-

pal holder of semantics for the deﬁnition of ontolog-

ical levels via deep instantiation. Indeed, the potency

notion introduces for example an abstract counter that

is to be attached to the core OMG meta-modeling

entities, that is, to nodes, ﬁelds, and edges. Thus,

the semantics of the potency notion deﬁnes thereby

the required layering of ontological levels. Based

on the orthogonal design, OCA only had to rely on

OMG’s linguistic instantiation for its compliant func-

tionality within MDA, which ultimately resulted in a

theoretical-practical hybrid solution. However, it also

meant that there was no purely abstract implementa-

tion of the potency notion semantics without it being

bundled to legacy modeling tools or languages.

In this paper, we intend to report on an alternative

implementation of the original (classic) potency no-

tion (Atkinson and K

uhne, 2001) speciﬁcation within

our multi-layer modeling framework not based on

OCA. The framework only plays the role of an ex-

ecutable playground for specifying the logic of the

potency notion without following a rigid speciﬁca-

tion hard-coded in a tool. Therefore, we think that

our re-implementation of the classic potency notion

clearly demonstrates how legacy tool-dependence can

be avoided. Namely, we relied only on our neutral in-

terpretation of deep instantiation, on its abstract math-

ematical level, our modeling tool is based on. Al-

though the existence of multiple modeling layers is

supported by our formalism, the semantics of those

modeling layers is neutral from the point of view of

the potency notion since it differs from that of the lev-

els potency notion does require. Thus, the potency no-

tion had to be encoded (modeled) through an explicit

semantics mapping between the underlying deep in-

stantiation by multi-layering and the speciﬁed con-

straints deﬁned on the functionality of the potency

notion. Although there is no explicitly required de-

pendency on classical modeling facilities in our pro-

posal, for the reason of practical model validation a

framework implementation has also been created

The paper is structured as follows. In Section 2 we

discuss the concept and brief history of the potency

notion. We also introduce our multi-layer modeling

framework. Section 3 contains an explicit speciﬁca-

tion of the classic potency notion. Section 4 presents

the mapping of multi-level concepts into our multi-

layer modeling framework in reasonable detail, and

also includes a case study. Finally, Section 5 con-

cludes the paper by highlighting future work in this

research ﬁeld.

2 BACKGROUND AND RELATED

WORK

2.1 The Potency Notion

The main goal of multi-level modeling is to reduce ac-

cidental complexity (Atkinson and K

uhne, 2008) by

using an unlimited number of meta-levels to assign

the right amount of abstraction details to every level.

Accidental complexity refers to parts of the solution

that are needed to express its multi-level nature, in-

stead of describing the domain in question. Using the

Item Description pattern to describe multiple domain

levels in object-oriented languages is an example of

such accidental complexity (Atkinson and K

uhne,

2008). Levels have been present for a long time in

modeling, dating back to the Uniﬁed Modeling Lan-

guage (UML) (Fowler and Scott, 2000). K

uhne ar-

gues that well-deﬁned levels ”safeguard against ill-

formed models” (K

uhne, 2018), which means that it is

easier to create valid, well-formed models. Atkinson

https://www.dmla.hu

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

394

and K

uhne compare this concept to strongly-typed

programming languages, while approaches that ”ig-

nore the fact that there are levels” are akin to weakly-

typed languages (Atkinson et al., 2014). They call the

former level-adjuvant, and the latter level-blind ap-

proaches.

The basic enablers of most level-adjuvant multi-

level modeling approaches are i) the notion of clab-

jects (Atkinson and K

uhne, 2000) and ii) the so-called

potency notion (Atkinson and K

uhne, 2001). Clab-

jects are entities that have a class and object facet at

the same time, thus, they can behave as either of the

two. This makes it possible to instantiate elements at

any level in the model. The potency notion is a mech-

anism responsible for governing deep instantiation,

which is the mechanism of instantiation across multi-

ple levels. In the context of this paper, we are mostly

focusing in the original version of potency (Atkinson

and K

uhne, 2001), often referred to as ”classic po-

tency” (K

uhne*, 2018). Our long-term goal is to im-

plement all the related concepts of the potency notion

in order to harmonize the different solutions by iden-

tifying their practical strengths and weaknesses.

In the interpretation of the classic potency notion,

the potency value is an integer number given to ev-

ery model element (nodes, edges, and ﬁelds) that de-

ﬁnes the depth to which a model element can be in-

stantiated (Atkinson and K

uhne, 2001). Every time a

model element is instantiated, its potency value (and

its level) is decreased by one. The potency value of a

model element must always be less or equal than its

level. This allows the creation of model elements that

reach their fully concretized state (a potency value of

0) at a level higher than 0. Elements with a potency

value of 0 cannot be instantiated further. Fields (fea-

tures of nodes) are differentiated based on whether

they can only get a value when their potency reaches

0 (called single ﬁelds), or they get a value every time

their potency decreases (called dual ﬁelds).

Inheritance is an important concept in both the

object-oriented and modeling world. While the pa-

per describing the classic potency notion (Atkinson

and K

uhne, 2001) does not elaborate on inheritance

much, we felt this was too important a concept to be

left out of our initial work. Therefore, we took inspi-

ration from later work in this regard (K

uhne*, 2018).

This extended classic potency notion (extended with

inheritance) is explicitly speciﬁed in Section 3.

Using the two main concepts of clabjects and the

potency notion, model elements can receive features

from more than one level above them, which is re-

ferred to as deep instantiation (Atkinson and K

uhne,

2001). This stands in contrast with the shallow instan-

tiation mechanism of UML and other MOF-based ar-

Figure 1: Online store domain as a multi-level model.

chitectures (MOF, 2005), as instantiation in this case

only covers two modeling levels at a time. Among

the main motivations of multi-level modeling are i)

the better expressive power of models, and ii) less-

ened complexity of models by eliminating accidental

complexity.

Figure 1 depicts a simple multi-level model using

the classic potency notion. The example was taken

from related work (K

uhne and Schreiber, 2007). The

domain in question is an online store that sells differ-

ent products: books and DVD-s. Product types have

a tax rate, and every instance of a product type has

a price. In this online store domain, we can see how

the potency notion governs deep instantiation. The

taxRate feature of the clabject ProductType receives a

value one level below (in clabjects Book and DVD),

while the price feature receives it two levels later.

The concept of clabjects and the potency notion

were introduced in many approaches, for example,

in DeepJava - an object-oriented language extended

to multiple levels - in order to support multi-level

programming (K

uhne and Schreiber, 2007). This is

one of the earliest applications of multi-level con-

cepts. DeepJava seemed to be a feasible solution to

multi-level programming, although being based on an

object-oriented language, there was still some acci-

dental complexity left that it aimed to avoid. There

were also some pitfalls with the original potency no-

tion that later variations aimed to improve upon. Var-

ious multi-level modeling approaches emerged in re-

cent years (Atkinson and Gerbig, 2016; de Lara and

Guerra, 2010; Clark and Willans, 2012), and the

potency notion received many alterations, variations

and interpretations over time (Neumayr et al., 2018;

Frank, 2014; Atkinson et al., 2012). These variations

were discussed in related work (Atkinson et al., 2014;

uhne*, 2018; K

uhne, 2018), and is not the scope of

this paper to elaborate upon.

Multi-level Modeling without Classical Modeling Facilities

395

2.2 Dynamic Multi-layer Algebra

In this section, we summarize the most important

features of Dynamic Multi-Layer Algebra (DMLA)

(Urb

an et al., 2018; Urb

an et al., 2017). DMLA is a

multi-layer modeling framework that consists of two

main parts: (i) the Core containing the formal def-

inition of modeling structures and its management

functions; (ii) the Bootstrap having a set of essential

reusable entities of any modeled domains in DMLA.

The Core contains the formal mathematical deﬁ-

nition how each model entity is deﬁned as a 4-tuple

(unique ID, meta-reference, attributes and concrete

values). Beyond giving the formal deﬁnition of the

tuples, the Core also declares some primitive func-

tions that directly manipulate the model, like adding

new model entities or select existing ones. These

mathematical constructs together deﬁne the Core of

DMLA, which is interpreted over an Abstract State

Machine (ASM) (B

orger and St

ark, 2003). The Boot-

strap (Mezei et al., 2019) is the initially deﬁned set of

tuples needed for meta-modeling constructs and built-

in model elements.

Instantiation in DMLA means gradual constrain-

ing (reﬁnement). Whenever a model entity claims

another entity as its meta, the framework automat-

ically validates if there is indeed a valid instantia-

tion between the two entities. The semantics of valid

instantiation are modeled by the Bootstrap entities.

When an entity is being instantiated, one can decide

which of the slots are being instantiated and which

are merely cloned, that is, being copied to the instance

without any modiﬁcations. Besides gradually narrow-

ing the constraints imposed on a slot, DMLA also en-

ables the division of a slot into several instances, thus

fragmenting a general concept into several, more spe-

ciﬁc ones. Moreover, it is also possible to omit a slot

completely during the instantiation if it does not vio-

late its cardinality constraint. Similarly to the relation

between an entity and its meta-entity, each slot origi-

nates from a meta-slot deﬁning the constraints it must

take into consideration. These include, but are not

limited to type and cardinality constraints.

The most important entity, ComplexEntity, has a

slot called Children. The cardinality of the slot Chil-

dren allows any number of instances (0..*) of any

practically available type. Since all slots in DMLA

must have a meta, it is not possible to add new fea-

tures to an entity, unless the meta-entity has an appro-

priate meta-slot. The Children slot allows us to extend

entities by adding new slots. If we omit the slot, we

can deny any further introduction of slots into the in-

stances of the given entity.

3 SPECIFICATION OF THE

CLASSIC POTENCY NOTION

In this section, we present the speciﬁcation of the

classic potency notion as discussed in Section 2. In

some cases, where the original work (Atkinson and

uhne, 2001) was not clear enough (like in the case of

handling inheritance), we borrowed ideas from later

work (K

uhne and Schreiber, 2007; K

uhne*, 2018).

These differences can be found when comparing Fig-

ures 1 and 3, and are explained later.

3.1 Level-related Requirements

L1 Levels serve as a logical separation between dif-

ferent model elements (K

uhne, 2018). Every

model element (nodes, edges and ﬁelds) is as-

signed a level value.

∀ME ∈ ELEMENT S : ∃ME.l (1)

L2 A level value is always greater than or equal to 0.

∀ME ∈ ELEMENT S : ME.l ≥ 0 (2)

L3 The level of a ﬁeld in a node is always equal to the

level of the node itself.

∀F

∈ f ields(N) : F

.l = N.l (3)

L4 When an instantiation occurs, the level of the

model element decreases by 1. This means that

the level of an instance is always less than the

level of its meta element by 1.

meta(ME

,ME

) : ME

.l = ME

.l − 1 (4)

L5 Cross-level references are not allowed. A cross-

level reference is an edge that runs between two

nodes that are on different levels.

∀E ∈ EDGES : E.N1.l = E.N2.l = E.l (5)

3.2 Potency-related Requirements

P1 Potency governs the depth a model element can be

instantiated. Every model element (nodes, edges

and ﬁelds) is assigned a potency value.

∀ME ∈ ELEMENT S : ∃ME.p (6)

P2 A potency value is always greater than or equal to

∀ME ∈ ELEMENT S : ME.p ≥ 0 (7)

P3 The potency of a ﬁeld in a node is always less

than or equal to the potency of the node except if

the node is an abstract node.

∀F

∈ f ields(N) : F

.p ≤ N.p;

N ∈ NODES − ABST RACT (8)

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

396

P4 When an instantiation occurs, the potency of the

model element decreases by 1. This means that

the potency of an instance is always less than the

potency of its meta element by 1.

meta(ME

,ME

) : ME

.p = ME

.p − 1 (9)

P5 If the potency of a model element is 0, then it can-

not be instantiated further.

.p = 0 : @ME

: meta(ME

,ME

) (10)

P6 Abstract nodes have a potency value of 0. There-

fore, they cannot be instantiated, they can only be

inherited from.

∈ ABST RACT : N

.p = 0 (11)

P7 Abstract nodes can only have ﬁelds with a po-

tency value greater than 0.

∀F

∈ f ields(N

) : F

.p > 0; N

∈ ABST RACT

(12)

P8 Single ﬁelds only get a value at potency 0. Dual

ﬁelds get a value every time their potency de-

creases.

F.p 6= 0,F ∈ SINGLE : @F.val and

F.p 6= 0,F ∈ DUAL : ∃F.val (13)

P9 When a ﬁeld gets a potency value of 0, it is omit-

ted from the instance node in the next instantiation

step.

∀F ∈ f ields(M),meta(I, M) : F /∈ f ields(I);

F.p = 0,I,M ∈ NODES (14)

P10 The potency of a model element is always less

than or equal to its level.

∀ME : ME.p ≤ ME.l (15)

P11 Inheritance is a special edge that always has a

potency of 0 and connects two nodes.

inh(N

).p = 0; N

∈ NODES (16)

P12 When inheriting from a node, the meta node of

the descendant has to be the meta node of the par-

ent.

inh(D,P), meta(D,M) : meta(P,M);

D,P,M ∈ NODES (17)

4 MAPPING OF THE CLASSIC

POTENCY NOTION

In this section, we discuss the mapping of the clas-

sic potency notion in our multi-layer modeling frame-

work, DMLA. First, we present the architecture of

the mapping, namely, where the mapping takes place

in the current architecture of DMLA. Next, we dis-

cuss how each of the requirements described in Sec-

tion 3 are satisﬁed, giving more details on cases where

the mapping is not trivial. Finally, we demonstrate

the mapping of the classic potency notion through a

simple case study. It is important to emphasize that

our mapping solution is devoid of any tool-imposed

limitations since we only rely on the mathematically

backed up validation mechanism of DMLA in order

to implement the semantics of the classic potency no-

tion.

4.1 Mapping Architecture

There were two theoretical options in DMLA on how

to map the classic potency notion onto it: i) by in-

troducing a new Bootstrap and build up a new set of

entities from the ground up, or ii) by introducing a

new stratum of entities that is responsible for the map-

ping between DMLA’s layer and the potency notion’s

level-based semantics. After thorough deliberation,

we decided on the second option, since by reusing the

entities already deﬁned in the standard Bootstrap, it

seemed sufﬁcient to only implement the mapping be-

tween the semantics. Thus, the model validation en-

coded in DMLA entities can also verify the interpre-

tation logic of the mapping itself. The mapping stra-

tum lies directly below the Core and the Bootstrap,

which means that it is only dependent on them. Do-

main models will be able to easily apply the classic

potency notion in DMLA as they are positioned be-

low the mapping stratum. Thus, our choice of map-

ping implementation allowed us to create an effective

mapping infrastructure that can be further extended

by other multi-level modeling concepts.

4.2 Mapping Details

In the following, we describe the mapping of the

classic potency notion based on the speciﬁcation de-

scribed in Section 3. Figure 2 visually depicts the

mapping from the concepts of the potency notion to

their implementation in DMLA. The top of the ﬁg-

ure depicts the elements of the classic potency notion,

while the bottom shows the structure of the mapping

in DMLA. The slots are shown embedded into the

entities. Meta-slot relationships are represented with

Multi-level Modeling without Classical Modeling Facilities

397

Figure 2: Mapping multi-level concepts in DMLA.

Slot:MetaSlot labels. The different constraints (type,

cardinality, potency, level, and ﬁeld) are expressed be-

tween curly brackets. As we can see, the basic con-

cepts of nodes and edges are mapped to separate enti-

ties, while ﬁelds are mapped to slots in DMLA. While

the internal technicalities of DMLA’s framework are

out of scope of this paper, we believe that we should

not totally disregard them for the sake of better under-

standing of the mapping logic. Thus, we describe the

main concepts of the mapping, but we omit low level

details, such as the syntax of DMLA’s operation lan-

guage. Nevertheless, the complete DMLA solution

can be found on our webpage

. In the following, we

explain the mapping, referencing Section 3 regarding

the satisﬁed requirements:

• PotencyEntity. The entry point to the mapping

layer, nodes and edges are instantiated from this

entity. Contains level and potency values as slots,

which are mandatory and is of a simple number

type. This partially satisﬁed requirements [L1,

P1]. Due to the nature of validation in DMLA, the

validation logic deﬁned in this entity validates ev-

ery entity instantiated from it, including nodes and

edges. The validation logic checks basic require-

ments regarding the level and potency values, i.e.,

the aforementioned values must be greater than 0,

or that they decrease by 1 when instantiating, and

so on [L2, L4, P2, P4, P5, P10]. In the valida-

tion code of the PotencyEntity, we also check if

there is a valid instantiation between two entities

regarding their potency values. Namely, we can-

not instantiate from a node with a potency value

of 0 (such as abstract nodes), and that ﬁelds with

https://www.dmla.hu

a potency value of 0 must be omitted from the in-

stance [P6, P9].

• PotencyNode. Maps the concept of nodes from

the classic potency notion. The Children slot is

the new entry point for deﬁning ﬁelds in domain

models. Fields are annotated with potency, level,

and the nature of the ﬁeld (single or dual). Ab-

stract nodes are marked by the IsAbstract ﬂag, and

they are checked to have a potency of 0 in the val-

idation logic [P6]. The validation logic checks i)

if an abstract node only has ﬁelds with potency

greater than 0 [P7], and ii) the relationship be-

tween ﬁeld and node level and potency [L3, P3].

• PotencyEdge. Edges are modeled as entities in

our mapping, since we can apply level and po-

tency to the edges, and we can more easily man-

age cross-level references. Also, it is possible to

model special edges like inheritance more accu-

rately this way, using the ﬂexible validation logic

of DMLA. The PotencyEdge entity has two con-

nected nodes as slots, and validates against cross-

level references (checking the level values of the

edge and its two connected nodes) [L5]. It also

checks if the connected nodes conform to the con-

nected nodes in the meta edge, if there are any.

• Inheritance is a special edge that has a potency

of 0 [P11]. Inheritance is instantiated from Po-

tencyEdge, thus, it behaves like an edge, but has

special constraints. The validation checks that ev-

ery ﬁeld in the parent must be present in the de-

scendant, and that the descendant must instantiate

the meta of the parent [P12], thus simulating the

concept of inheritance.

• PotencyConstraint. A potency value is assigned

to ﬁelds in the form of a constraint [P1]. The vali-

dation logic checks the basic rules for the potency

value, similarly to PotencyEntity [P2, P4, P10].

We also validate that the ﬁeld gets an assigned

value when it reaches potency 0 [P8].

• LevelConstraint. Behaves similarly to Potency-

Constraint, assigning a level value to ﬁelds [L1].

Validation is also similar, checking the basic rules

of level values [L2, L4].

• FieldConstraint contains a simple ﬂag that can

be used to mark a ﬁeld as single or dual [P8]. The

validation is responsible for checking the assigned

values as described by the classic potency notion

[P8]. It also ensures that once the nature of a ﬁeld

is deﬁned, it can never be overwritten. The con-

straints from Figure 2 can be found on the Chil-

dren ﬁeld in PotencyNode, from which every new

ﬁeld is created.

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

398

Figure 3: The extended online store model.

4.3 Case Study

The case study was inspired by examples found in re-

lated work (K

uhne and Schreiber, 2007). Figure 3

depicts the online store domain previously seen in

Figure 1, extended with new concepts, which are

as follows. Every ProductType instance (and thier

instances, and so on) have a name. This means

that Book has a deﬁning name (”Book”), while book

instances also have their own name (like ”Moby

Dick”). To realize this, ProductTypes inherit from

NamedNode, which is an abstract node with a potency

value of 0. Its name ﬁeld is a dual ﬁeld, which means

that it must receive a new value every time its potency

decreases. Please note that while ProductType could

be an abstract clabject, we chose to remain faithful

to the original example, and left it as non-abstract.

The other extension is that every DVD is based on a

book, which is modeled as an association with a role

name. Every ﬁeld other than name is single, which

means that they only receive a value when their po-

tency reaches 0. On the middle level, we have the

ProductType instances: Book and DVD. There is an

association between the two (basedOn), which has a

potency value of 1, meaning that it can be instanti-

ated one level below. On the lowest level, we have the

Book and DVD instances: MobyDick DVD is based

on MobyDick Book.

Figure 4 depicts the mapped online store domain

in DMLA. The most signiﬁcant differences are per-

haps the modeled edges which appear as entities (like

BasedOn). The notation on the ﬁgure is deliberate

and is aimed at highlighting the differences compared

to classical modeling facilities. For example, since

there are no explicit levels in DMLA, the levels ap-

pear as they are present in the mapping, namely, as

slots (ﬁelds) in the entities. That is a DMLA tech-

nicality and it has nothing to do with the semantics

of the levels. Constraints on the slots are marked be-

Figure 4: Online store domain mapped in DMLA.

tween curly braces, similarly to Figure 4. For exam-

ple, the TaxRate slot in the ProductType node has a

type of Number, a cardinality of 1..1, a potency of 1,

a level of 2, and it is a single ﬁeld (”S” means single,

”D” means dual). Please note that the validation logic

does not appear in the ﬁgure, as it is not part of the

structural mapping, and it closely follows the speciﬁ-

cation presented in Section 3.

5 CONCLUSIONS

Multi-level modeling has a well-established literature

in the modeling research community. In our par-

ticular branch of research, level-adjuvant approaches

show strict level cohesion and segregation principles

uhne, 2018), and they mostly rely on the potency

notion as a concrete means of achieving deep instan-

tiation. Due to its relative importance in this regard,

the potency notion had been developed over the years,

with a few variations existing in both theory and prac-

tice today. Hence, in this paper, we discussed a di-

rect mapping between the main concepts of the classic

potency notion and its DMLA representation, which

is our level-blind multi-layer modeling framework.

However, this paper is only the beginning of a series

of research studies which we intend to publish where

our aim is to provide a practical modeling playground

with automatic model validation in order to be able

Multi-level Modeling without Classical Modeling Facilities

399

to better investigate and verify the semantics of many

multi-level modeling concepts. Therefore, in our cur-

rent work, we have implemented the concepts of the

potency notion according to its original deﬁnition and

presented how the mapping thereof was encoded in

DMLA. The results are promising for a multi-level

modeling framework to support future research work

such as i) implementing more varieties and interpre-

tations of existing multi-level concepts, and ii) in-

troducing domain-speciﬁc languages to adopt level-

adjuvant concepts in DMLA.

ACKNOWLEDGEMENTS

The research has been supported by the European

Union, co-ﬁnanced by the European Social Fund

(EFOP-3.6.2-16-2017-00013, Thematic Fundamental

Research Collaborations Grounding Innovation in In-

formatics and Infocommunications.

REFERENCES

Atkinson, C. and Gerbig, R. (2016). Flexible deep mod-

eling with melanee. In Modellierung 2016 - Work-

shopband : Tagung vom 02. M

arz - 04. M

arz 2016

Karlsruhe, MOD 2016, volume 255, pages 117–121,

Bonn. K

ollen.

Atkinson, C., Gerbig, R., and Kennel, B. (2012). Symbiotic

general-purpose and domain-speciﬁc languages. In

Proceedings of the 34th International Conference on

Software Engineering, ICSE ’12, pages 1269–1272,

Piscataway, NJ, USA. IEEE Press.

Atkinson, C., Gerbig, R., and K

uhne, T. (2014). Comparing

multi-level modeling approaches. In CEUR Workshop

Proceedings, volume 1286.

Atkinson, C. and K

uhne, T. (2000). Meta-level indepen-

dent modelling. In International Workshop on Model

Engineering at 14th European Conference on Object-

Oriented Programming.

Atkinson, C. and K

uhne, T. (2001). The essence of multi-

level metamodeling. In Proceedings of the 4th Inter-

national Conference on The Uniﬁed Modeling Lan-

guage, Modeling Languages, Concepts, and Tools,

pages 19–33, Berlin, Heidelberg. Springer-Verlag.

Atkinson, C. and K

uhne, T. (2008). Reducing accidental

complexity in domain models. Software & Systems

Modeling, 7(3):345–359.

orger, E. and St

ark, R. (2003). Abstract State Machines:

A Method for High-Level System Design and Analysis.

Springer-Verlag New York, Inc., 1st edition.

Clark, T. and Willans, J. (2012). Software language engi-

neering with xmf and xmodeler. In Formal and Prac-

tical Aspects of Domain-Speciﬁc Languages: Recent

Developments, volume 2, pages 311–340.

de Lara, J. and Guerra, E. (2010). Deep meta-modelling

with metadepth. In Vitek, J., editor, Objects, Mod-

els, Components, Patterns, pages 1–20, Berlin, Hei-

delberg. Springer Berlin Heidelberg.

de Lara, J., Guerra, E., and Cuadrado, J. S. (2014). When

and how to use multilevel modelling. ACM Trans-

actions on Software Engineering and Methodology,

24(2):12:1–12:46.

Fowler, M. and Scott, K. (2000). UML Distilled (2Nd

Ed.): A Brief Guide to the Standard Object Model-

ing Language. Addison-Wesley Longman Publishing

Co., Inc., Boston, MA, USA.

Frank, U. (2014). Multilevel modeling - toward a new

paradigm of conceptual modeling and information

systems design. Business & Information Systems En-

gineering, 6(6):319–337.

Gerbig, R., Atkinson, C., de Lara, J., and Guerra, E.

(2016). A feature-based comparison of melanee and

metadepth. In Proc. of the 3rd International Workshop

on Multi-Level Modelling co-located with ACM/IEEE

19th International Conference on Model Driven En-

gineering Languages & Systems (MoDELS 2016),

Saint-Malo, France, October 4, 2016., pages 25–34.

uhne*, T. (2018). Exploring potency. In Proc. of the

21th ACM/IEEE International Conference on Model

Driven Engineering Languages and Systems, MOD-

ELS ’18, pages 2–12, New York, NY, USA. ACM.

uhne, T. (2018). A story of levels. In Proceedings of

MODELS 2018 Workshops, Copenhagen, Denmark,

2018, pages 673–682.

uhne, T. and Schreiber, D. (2007). Can program-

ming be liberated from the two-level style: Multi-

level programming with deepjava. SIGPLAN Not.,

42(10):229–244.

MDA (2001). OMG: Model Driven Architecture.

https://www.omg.org/mda. Accessed:2019-10-23.

Mezei, G., Theisz, Z., Urb

an, D., B

acsi, S., Somogyi, F. A.,

and Palatinszky, D. (2019). A bootstrap for self-

describing, self-validating multi-layer metamodeling.

In Dunaev, D. and Vajk, I., editors, Proceedings of the

Automation and Applied Computer Science Workshop

2019 : AACS’19, pages 28–38.

MOF (2005). OMG: MetaObject Facility.

http://www.omg.org/mof/. Accessed:2019-10-23.

Neumayr, B., Schuetz, C. G., Jeusfeld, M. A., and Schreﬂ,

M. (2018). Dual deep modeling: multi-level modeling

with dual potencies and its formalization in f-logic.

Software & Systems Modeling, 17(1):233–268.

Urb

an, D., Mezei, G., and Theisz, Z. (2017). Formalism

for static aspects of dynamic metamodeling. Peri-

odica Polytechnica Electrical Engineering and Com-

puter Science, 61(1):34–47.

Urb

an, D., Theisz, Z., and Mezei, G. (2018). Self-

describing operations for multi-level meta-modeling.

In Proceedings of the 6th International Conference

on Model-Driven Engineering and Software Develop-

ment - Volume 1: MODELSWARD,, pages 519–527.

INSTICC, SciTePress.

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

400