Validated Multi-Layer Meta-modeling
via Intrinsically Modeled Operations
Gergely Mezei, Dániel Urbán Zoltán Theisz
Department of Automation and Applied Informatics Huawei Design Centre,
Budapest University of Technology and Economics Dublin, Ireland
Budapest, Hungary zoltan.theisz@huawei.com
{gmezei, urban.daniel}@aut.bme.hu
Abstract— State-of-the-art meta-model based technologies are self-described, model intrinsic validation mechanism to
facing increasing pressure under new challenges originating from automatically evaluate every potential change of its
practical industrial applications. Dynamic Multi-Layer Algebra encompassing multi-level meta-model. Most of our ideas and
(DMLA) is a novel generic modeling approach that intends to solution techniques are the results of our hands-on experiences
meet these challenges by combining multi-level meta-modeling
we have gathered by analyzing real industrial information
and validated instantiation. This paper describes the core ideas
and techniques that have been applied to DMLA in order to models for several years. As a consequence, the current
create a modular model intrinsic validation of instantiation. The DMLA version (v2.1), is not a theory any longer; we have also
approach is also illustrated by a simple example. implemented major parts of it as an executable demo, which is
available for download at [1].
Keywords— validated meta-model; modular constraints; multi-
level modeling II. RELATED WORK
Practical meta-model based applications show an increased
I. INTRODUCTION interest for both state-of-the-art and innovative modeling
Meta-model based solutions have been gradually gaining technologies. OMG’s Meta-Object Facility (MOF) is still the
acceptance in many complex industrial applications, for dominant meta-modeling approach used for industrial
example in the domains of telecommunications, IoT and cloud applications. There are two reasons for this: 1) MOF's four
management systems. Many of these applications rely on EMF layer modeling architecture is easily comprehensible; 2) the
technologies to provide facilities for type safe storage and Eclipse Modeling Framework (EMF) has been maturing
manipulation of millions of configuration and control during the recent years. However, new practical challenges,
parameters. Nevertheless, those practical model-based for example, full life-cycle management of model-based
solutions are seriously hampered by a legacy, that is, meta- instances may require full-fledged multi-level meta-modeling.
model induced database schemas must be maintained by These alternative techniques advocate an explicit distinction
design-time derived toolchains such as EMF/CDO. Thus, between linguistic and ontological meta-models [2] [3] and
these solutions are hardly capable of automatically coping can also differentiate between shallow and deep instantiation
with a massive amount of frequently changeable instance data [4]. Deep instantiation is more prevalent because it can
that is mostly regulated by a slowly, but steadily evolving set effectively reduce accidental complexity in the domain
of type information controlled by some product life-cycle models. For example, in the case of potency notion [4], every
schemes. Therefore, an integrated validation mechanism of class and attribute gets a potency assigned, which indicates the
design- and run-time models should become part of any such remaining levels the model elements can get through before
industrial solutions. Also, the validation mechanism shall be reaching their finally instantiated status. In a sense, potencies
both modular and capable of maintaining the instance data and are simple non-negative numbers, but, in their effect, they
the meta-model schemas in sync irrespective of their represent the current level of abstraction. They are
abstraction levels and design or run-time nature. This decremented at each instantiation and when they reach 0 no
practicality requirement asks for a proper multi-level meta- further instantiation is allowed. Potency notion has been
modeling technique, which supports the validation of the successfully implemented in the EMF based tool Melanee [5].
instantiation step not as an afterthought, but as a direct However, despite the many advantages potency notion
consequence of the underlying multi-level modeling provides, it also showcases some disadvantages due to its
formalism. Orthogonal Classification Architecture (OCA) [6] heritage.
The paper describes our proposed solution, the Dynamic Namely, OCA takes it for granted that all meta-model
Multi-Layer Algebra (DMLA), which represents a modular, management facilities, i.e. introducing a new attribute to a
operation-based, multi-level meta-modeling approach with a clabject, are operational on each metalevel, thus, the
instantiation step is oversimplified; it is merely controlled by a
single integer value. Melanee tried to diversify this naïve Directed Graph. Each element of the model such as nodes,
counting by distinguishing the concepts of durability and edges or even attributes can have labels. These labels are used
mutability, but the constraining of the instantiation is still only either to hold data (e.g. concrete literal value of an attribute) or
described by integer values. to express relations (e.g. containment) between the elements.
An important step forward to achieve expressive multi- Because attributes may have complex structure, we represent
level meta-modeling is the Lazy Initialization Multilayered them as hierarchical trees. Also, for the sake of simplicity, we
Modeling framework (LIMM, [7]). This approach enables the will use a dual field notation for labelling of Name/Value
definition of model elements at the meta level, at the pairs, that is, a label with the name N of the model element X
application level, or one can simply declare them as data. In is referred to as XN. We defined the following labels: (i) X ID:
effect, LIMM associates flags to the model elements in order globally unique ID of model element; (ii) XMeta: ID of the
to control how they are to be used in the successive layers. An meta-model definition; (iii) XValues: values of the model
attached flag can take three values: it restricts, allows or element; (iv) XAttributes: ordered set of contained attributes.
enforces the initialization of a model element in subsequent Definition – The superuniverse |A| of a state A of the
layers. In a sense, the potency value evolves into a simple DMLA consists of the following universes: (i) UBool containing
indicator of life-cycle status, which incorporates more than logical values {true/false}; (ii) UNumber containing rational
only checking if the value is positive when meta-level numbers and a special symbol ∞ representing infinity; (iii)
transitions of model elements are being evaluated. UString containing character sequences of finite length; (iv) UID
DMLA aims to combine multi-level meta-modeling with containing all possible entity IDs; (v) UBasic containing
dynamic model manipulation, which also necessitates non- elements from {UBool ∪ UNumber ∪ UString ∪ UID}. Additionally,
trivial description of constraints on the instantiation steps all universes also contain a special element, undef, which refers
through meta-levels. Also, DMLA incorporates a fully self- to an undefined value.
modeled operation language, which is currently implemented The labels of the entities take their values from the
as a lightweight external DSL, called DMLAScript. Hence, following universes: (i) XID: UID, (ii) XMeta: UID, (iii) XValues:
although on the surface, DMLA looks very similar to XMF UBasic[] (contained primitive values), (vi) XAttrib: UID[]
and XModeler [8], it clearly advocates a different architectural (reference to entities).
design. Firstly, DMLA’s main focus lies on the multi-level In ASMs, functions are used to rule how one can change
meta-modeling of data; thus, it considers operations also as the states. In DMLA, we rely on shared and derived functions.
data (of a particular meta-level) that can be mixed in into the The current attribute configuration of a model element is
rest of the meta-model. Secondly, DMLA separates the DSL represented via shared functions. The values of these functions
representation of DMLAScript from its internal meta- can be modified either by the algebra itself, or by the
modeling formalism. Thirdly, DMLA’s formal foundation is environment of the algebra (e.g. by the user). Derived
ASM-based, that is, it is executable by design [9]. functions represent calculations which cannot change the
Nevertheless, both approaches rely on the concept of a self- model; they are only used to obtain and to restructure existing
describing multi-level meta-model and the core idea of having information. The vocabulary ∑ of DMLA is assumed to
a bootstrap. However, as long as XMF’s meta-model utilizes contain the following characteristic functions: (i) Meta(U ID):
higher order functions to process syntax and to provide a basic UID, (ii) Attrib(UID, UNumber): UID, (iii) Value(UID, UNumber):
executable language which extends OCL syntax and UBasic. The functions are used to access the values stored in the
semantics, in DMLA, the operation language is a mere corresponding labels. These functions are not only able to
facilitator to generate meta-model elements for the bootstrap. query the requested information, but they can also update it.
As a result of this setup, the operations are constrained only by For example, one can update the meta definition of an entity
the other elements of the bootstrap; thus, either they can be by simply assigning a value to the Meta function (although the
directly interpreted by the underlying ASM formalism or they new relation may be invalid based on the instantiation rules).
must be translated and later executed by some ASM Moreover, there are two other derived functions: (i)
compatible run-time platform(s). Contains(UID, UID): UBool and (ii) DeriveFrom(UID, UID): UBool,
which check containment and instantiation (transitive)
III. THE DYNAMIC MULTI-LAYER ALGEBRA relations, respectively.
The Dynamic Multi-Layer Algebra (DMLA) is a multi-
level modeling framework that consists of two major parts: (i) B. The Bootstrap
the Core, a formal definition of the modeling structure and its In a nutshell, the Core is the formalism, while the
management functions; (ii) the Boostrap, an initial set of Bootstrap is the practical foundation for DMLA. The
predefined modeling entities. Bootstrap is an initial set of modeling constructs and built-in
model elements (e.g. built-in types) which are necessary in
A. The Core order to adapt the abstract modeling structure to practical
The definition of the Core is based on Abstract State applications. The main idea behind separating the Core and
Machines (ASM, [9]). In our case, the states of the state the Bootstrap is to improve flexibility, but also to keep the
machine are snapshots of the models, while transitions formal definition: the algebraic part is relatively fixed and
represent modification actions between these states (e.g. structurally self-contained; its purpose is to isolate itself from
deleting a node). The model is represented as a Labeled the certain particularities of the various bootstraps. This design
Fig. 1 – Main elements of the Bootstrap
makes it possible to replace the Bootstrap; hence, one can not refer to sets of values in the corresponding universe. For
only customize the basic modeling entities, but one can also example, the entity Bool has been created so that it could be
re-define even the semantics of what valid instantiation means. used to represent Boolean type values within the model. Built-
A particular bootstrap seeds the meta-modeling facilities of in types are relied on when a slot is filled by a concrete value
generic DMLA formalism, thus, one may create a Bootstrap and that value is not a reference to another model entity, but a
for simulating potency notion, another one for LIMM and a primitive, atomic value. All built-in types are instances of
third one for power type behavior, etc. Primitive.
The main elements of the current bootstrap (Fig. 1) can be 3) Operations
categorized into four groups: (i) basic entities (blue boxes), (ii) All these entities representing the grammar of the operation
built-in types (purple boxes) representing the primitive types language are defined in the AST subpart of the bootstrap
available in DMLA, (iii) entities used in facilitating the under ComplexEntity. Moreover, there are also some extra-
introduction of operations in DMLA (green boxes), and (iv) grammar entities defined here that deal with ASM execution
validation related entities (red boxes). semantics of those operations by specifying for example the
1) Basic entities invocation mechanism and the handling of return values and
Basic entities are the enablers of multi-level meta- variables. This aspect of DMLA is not discussed in this paper
modeling in DMLA. They create the root of the meta in detail.
hierarchy all other modelled entities rely on. 4) Validation
The Base entity is at the very top of the hierarchy, thus all In DMLA, the validation logic relies on the selection of two
other entities are instantiated from it (directly or indirectly). type specific formulae based on the meta-hierarchy of the
Base defines that entities can have slots (defined by SlotDefs) element to be validated. These two types are referred to as
and ConstraintContainers. Slots represent substitutable alpha and beta. The Base entity contains the default alpha and
properties, which are syntactically similar to class members in beta formulae, which can be constrained by the instances via
OO languages. ConstraintContainers (and the contained their own specialized definition of valid instantiation, provided
Constraints) are used to customize the instantiation validation that does not contradict the standard validation rules imposed
formulae. Moreover, Base has two other slots, reserved for by Base. The validation mechanism is detailed later.
validation of those formulae, which enforce the basic
mechanisms of instantiation validation for multi-level IV. VALIDATION AND OPERATIONS
modeling as explained later. In DMLA, if a model entity claims another entity as its
The SlotDef entity is a direct instantiation of Base. It is meta the framework automatically validates if there is indeed a
used to define slots. Slots can contain ConstraintContainers, valid instantiation between the two. In DMLA 1.0 [11]
which grants them the capability to attach constraints to the instantiation was simply validated by a fixed set of general
containment relations defined by the slot. Moreover, SlotDef usage formulae, but in DMLA 2.0 [10], those formulae have
overrides the validation slots inherited from Base. been modularized by introducing a bootstrap compatible
The Entity entity is another direct instance of Base. Entity representation thereof. Since these formulae can directly
is used as the common meta of all primitive and user-defined influence the current semantics of the instantiation, model
types. Entity has two instances: Primitive (for primitive types) modification has got modularized and DMLA’s instantiation
and ComplexEntity (for custom types). All domain relevant has become effectively self-defined by model interpretation.
entities further instantiate ComplexEntity. While implementing DMLA 2.0, we realized that by
2) Built-in Types introducing operations into our framework we could describe
The core entities needed to represent the universes of ASM validation formulae and their modular extensions, the so-
in the bootstrap are: Bool, Number and String. All these types called constraints, by attaching operations onto certain DMLA
entities. Herewith, automatic model validation became a core of the element to be validated. We refer to these two types of
feature. By further experimenting with this feature, we were formulae as alpha and beta. The alpha type formulae have
able to establish a very compact though flexible validation been designed to validate an entity against its instances, by
system. simply checking if the instantiation relation can be verified
When we introduced operations into DMLA, the first between the two entities (meta and instance). During
technical issue was related to their representation. It was clear validation, the framework iterates over the entities of the
that operations must be described by DMLA modeling model, and invokes the alpha type validation on every entity
elements only, similar to other modeling entities in the and its meta entity. In contrast, the beta type formulae are in
Bootstrap. We have decided to base our representation on context checks: they are used when an entity has to be
Abstract Syntax Tree (AST), where operations consist of validated against multiple related entities, typically the
entities representing their roles in the grammar such as attributes of an entity. For example, cardinality-like
expressions or statements. For example, the conditional constraints shall be evaluated by beta formulae due to the
statement (“if”) has three child attributes: a condition underlying one-to-many relation thereof. Note that the exact
(expression), a true branch (statement), and an optional false validation rules provided by the alpha and beta formulas are
branch (statement). Since all of these subparts are DMLA Bootstrap-dependent, thus, it is easy to re-interpret the
entities, validation rules are applied to them similarly to other instantiation logic by only modifying these formulae.
entities, which created the self-describing facility of DMLA. Modular validation in DMLA works via compatible
The second technical issue considered how and when the constraint extension. It means that entities can copy or extend
operations must be executed. DMLA’s practicality agenda the validation logic of their meta entity, which grants a very
aims at a virtual machine (DMLA VM) implementation high level of flexibility without any loss of expressivity. The
similar to Java VM in order to interpret and execute integration of operation ASTs into the Bootstrap allowed it to
operations. We have not reached this goal yet, but we have contain executable logic. Therefore, any model entities may
already defined and implemented an engine capable of parsing provide their own specialized version(s) of valid instantiation,
AST related DMLA entities and of producing executable Java provided there is no contradiction with the standard validation
code from the model. Currently, the generated code can be rules imposed by their meta type (meta formulae are
automatically integrated into the program, which is running automatically validated by the framework).In parallel to
the Core of DMLA’s ASM implementation. Since the validation rules, constraint specification was also modularized
validation logic of the bootstrap is in its entirety described in in order to avoid repeated definitions by introducing a generic
DMLA operations, its semantics can be completely and Constraint entity. Constraints describe reusable validation
consistently updated by simply changing the model. logic that can be attached to any entity. It is important though
The last technical issue focused on the effective to mention that the validation of constraints is special because
manipulation of the operations within DMLA. Since DMLA it is not enough to validate the (Constraint) entity itself, but
2.0’s formal entity syntax is 4-tuple based [10], operations also the entity the constraint is referring to. For example, a
must be specified accordingly. Nevertheless, we realized that range checker constraint added to a slot describing a number
it would become cumbersome to produce realistic models by attribute must validate the value of the attribute, not the
only relying on the 4-tuple representation. Even simple constraint (definition) itself. This is why we added special
statements and operation calls may require dozens of entities formulae to Constraints: the constraint-alpha and constraint-
that refer to each other in a complex entanglement. Hence, we beta aimed to validate the entity containing the constraint.
implemented a simple XText-based DSL language with However, constraints are also special due to their life cycle.
concrete syntax for DMLA, the so-called DMLAScript. The Thus, in order to achieve self-describing multi-level validation
language design has borrowed syntax ideas mainly from Java, we needed constraints which are able to govern their own
but the repertoire of language constructs is limited by the (customized) life-cycle. E.g. a constraint can decide if its re-
needs of DMLA. Although DMLAScript looks like being part instantiation is valid, or not. This feature is encoded in two
of DMLA, it is not: DMLAscript is pure syntactic sugar above other operations (lifecycle alpha and beta). This feature is
DMLA’s 4-tuple representation. Nevertheless, by being able similar to a self-managed, customizable potency notion.
to specify validation logic in DMLAScript, our productivity In summary, the validation of the Bootstrap is based on
increased enormously. Currently, DMLAScript descriptions three pairs of formulae: 1) the alpha and the beta type
are parsed into 4-tuples, which are then input to DMLA validation formulae, which are applied to every entity of the
ASM’s standard Java code generator. In other words, code Bootstrap; 2) the ConstraintAlpha and the ConstraintBeta
generator (semantics) and language parsing (syntax) work formulae, which are extensions of the container entity’s alpha
independently, but hand-in-hand in the current toolchain and beta formulae; 3) the Constraint-LifeCycleAlpha and the
implementation. ConstraintLifeCycleBeta formulae, which manage and
validate the DMLA correct life-cycle of Constraint instances
A. Flexible instantiation
In DMLA, the validation logic of instantiation relies on the
selection of two type specific formulae based on the hierarchy
operation Bool ID::PersonAlpha(ID instance) {
//Access the value of the slot containing the name of the person
ID fullName = call $GetRelevantAttributeValue(instance, $Person.FullName);
If (fullName==null)
return true; // If no name is specified yet => valid
Object[] firstNames=call $GetRelevantAttributeValues(fullName, $ComplexName.FirstName);
//Access the first name values contained by the ComplexName
if(firstNames ==null || size(firstNames)<2) return true; //not specified/has less than 2 first names
//Ensure the first names do not match
return index