Introduction to Multi-Level Modeling

Playground for Multi-Level Modeling

In this Chapter, we first discuss the background on multi-level modeling, introduc-ing the most commonly used concepts in this research field. Some of the more well-known approaches are also briefly presented. The Dynamic Multi-Layer Alge-bra is also discussed, which is referred to again later in this Chapter, during the discussion of the practical application. As the last part of the Background sec-tion, the mathematical formalism - Abstract State Machines - used by the proposed formalism to describe multi-level constructs is introduced. Next, we present said formalism for experimenting with multi-level constructs. The formalism is capa-ble of specifying the structure and semantics of multi-level constructs, regardless of their underlying theory or toolchains used in practice. Four selected constructs are specified with the formalism, in addition to a domain model. Afterwards, a new language is introduced that can be used to easily specify multi-level constructs in practice. Finally, the practical application of the formalism and language are demonstrated via the Multi-Level Modeling Playground (MLMP). MLMP is also evaluated in practice, comparing it to other approaches that could serve as the basis of a scientific playground.

Figure 3.1: The architecture of the Meta-Object Facility (MOF).

that “ignore the fact that there are levels” are akin to weakly-typed languages [AGK14]. In the literature, the former approaches are called level-adjuvant, while the latter are calledlevel-blind [AGK14]. Level-blind approaches can still implicitly employ the concept of levels, although they are not explicitly present in the model per se.

An important concern when discussing levels is the basis upon which entities are grouped into the same level, or, in other words, which entities are separated by levels. The related principles described by K¨uhne [K¨uh18] are as follows:

1. Level Cohesion Principle. Logical grouping helps segregate elements into the appropriate level, which can be beneficial since we can easily recognize problematic ”level-crossing” attributes, and the elements are systematically organized. K¨uhne argues that it is ”helpful to explicitly state” the cohesion principle of a multi-level approach.

2. Level Segregation Principle. This principle helps in recognizing how ele-ments in adjacent levels are related to each other. According to a survey con-ducted ahead of Dagstuhl seminar 17492 [AFK18], most participants agreed that this semantic barrier between levels is abstraction.

In multi-level modeling, model elements usually have a type (class) and an in-stance (object) facet, since they serve as a type for the elements on the level below, and as an instance for the elements on the level above. This makes it possible to instantiate elements at any level in the model. To reflect this behavior, model elements are called clabjects in the literature [AK00]. Clabjects may contain at-tributes (terminology may differ, e.g., fields, features), and can have relationships (edges) between them, just like in the MOF architecture.

Another important concept in multi-level modeling is deep instantiation. In classic, four-level meta-modeling, instantiation only concerns two levels: the meta level and the instance level. To contrast, this is usually referred to as shallow instantiation [AK01]. In contrast, deep instantiation spans multiple levels, namely, instances can also have their own instances. Moreover, a clabject on level N might indirectly influence another on level N-2, N-3, and so on. This is referred to asdeep characterization [K¨18]. One of the most prevalent approaches for governing deep instantiation (and deep characterization) is thepotency notion [AK01]. Potency is a non-negative integer number assigned to every model element in a multi-level model.

In short, the potency notion is responsible for governing the instantiation depth of

model elements. For example, a model element with a potency of 2 supports an instantiation chain of depth two. It can be instantiated once, on the level below, and then this instance in turn again on a further level below.

Figure 3.2: A multi-level model (inspired by related work [KS07]).

The concepts of clabject and potency are demonstrated on a simple example in Figure 3.2. The model has three levels: L2, L1, and L0. The numbers in the upper right corner of model elements represent their potency. For example, the node Pro-ductType (which is a clabject) has a potency of 2. Instantiation decreases potency by 1, and when potency reaches 0 (like in the case of the taxRate field or the Moby-Dick Book node), the given model element cannot be instantiated anymore. The NamedNode node is an abstract node with a potency of 0. Edges (like the basedOn edge) also have a potency value, in addition to their multiplicity. Underlined fields represent dual fields, which will be discussed later. Note that in practical scenarios,

”name” as an attribute could never appear in a semantically sound model based on classic potency, as the name of a model element is already included in the clabject definition. However, we still use this example in order to have examples for an abstract node and an inheritance relationship later.

Cross-level referencing is a recurring challenge in multi-level modeling [Fra18].

For example, it should be possible for two clabjects on different levels to have the same meta element, but it is difficult to achieve this when using level-adjuvant approaches, as instantiation can only occur between two neighbouring levels. A possible workaround would be using contingent levels, which makes an entity more flexible regarding its level [Fra18]. Another common example is when a clabject refers (via a relationship) to another clabject at a different abstraction level. Level-adjuvant approaches struggle more in this regard, while level-blind approaches (like fluid meta-modeling) can handle cross-level references, since they are not bound by the strict regulations regarding levels.

In multi-level modeling, one can distinguish between linguistic and ontological classification [dLGC14]. One of the most prevalent architectures that achieves this is the Orthogonal Classification Architecture (OCA) [AK02,AGK12,AG16,dLGC14], which is illustrated in Figure 3.3. In the OCA, clabjects have two orthogonal clas-sification dimensions: the ontological dimension defined by the modeled domain, and the linguistic dimension defined by the modeling structure. There are three linguistic levels: i) the top level (L²) contains the meta-modeling facilities, ii) the middle level (L¹) contains the domain model, consisting of an unlimited number of ontological levels (O^N..O⁰), and iii) the bottom level (L⁰) contains the real world elements.

Figure 3.3: The Orthogonal Classification Architecture (OCA).

The OCA aims to relax the constraints of OMG’s four-level modeling stack via the introduction of additional modeling levels, while also supporting every facility of OMG’s modeling infrastructure, including object-oriented modeling concepts like inheritance. The main reason of OCA’s success is the fact that its ontological instantiation assumes or prescribes no implicit semantics in OMG’s MDA design [Fra02b], which positions it clearly against the linguistic instantiation that does require it. Thus, state-of-the-art MDA tools are often capable of supporting the OCA out-of-the-box. There are several multi-level modeling approaches that are based on the OCA, some of which we will discuss later in this Section.

In traditional modeling methodologies, constraints are used when the structure of the model is not sufficient enough to express certain requirements. For exam-ple, in the case of UML [FS00], the Object Constraint Language (OCL) [WK03]

is often used to describe restrictions that cannot be expressed by the structure of the model. The key difference between traditional and multi-level modeling in this regard is managing constraints throughout the entire meta hierarchy. In traditional modeling, this is not an issue due to the limited number of modeling levels. In multi-level modeling, we have to define and manage how constraints behave on the hierarchy. Constraining in multi-level modeling is an active research area today [CF18]. For example, when we constrain an entity, we have to define how that con-straint behaves on the transitive instances of the entity in the meta hierarchy. We can differentiate between two main approaches to constraining in multi-level mod-eling based on the way constraints can be expressed. The first approach is to use

an external language to define the constraints, while the second is to use a built-in, modeled approach. The advantages of using an external language are that it is eas-ier to introduce, usually offers better tool support, and the language can be used in multiple approaches, thus, it is somewhat general. On the other hand, using a self modeled approach (internal language) has the advantage of being more flexible and customizable, easily extendable (as opposed to an external language), and the validation of the constraints become easier.

Finally, it is worth mentioning that in recent years, there have been a proposal to fundamentally change how we approach modeling, which the authors likened to a Kuhn-style scientific revolution in this research field [HSEGP˚A13]. This has facilitated discussion in the field, including topics like what exactly do we mean by multi-level modeling [K¨uh18, AGK14, BKKM18].

In order to establish a unified terminology, from now on, we refer to clabjects as nodes, to relationships between them as edges, and to attributes contained in clabjects as fields. Together, we refer to all of the above as model elements. Note that some approaches also model edges as clabjects, but our terminology differs in this regard.