- State-of-the-art meta-model based technologies are facing increasing pressure under new challenges originating from practical industrial applications. Dynamic Multi-Layer Algebra (DMLA) is a novel generic modeling approach that intends to meet these challenges by combining multi-level meta-modeling and validated instantiation. This paper describes the core ideas and techniques that have been applied to DMLA in order to create a modular model intrinsic validation of instantiation. The approach is also illustrated by a simple example.
Meta-model based solutions have been gradually gaining acceptance in many complex industrial applications, for example in the domains of telecommunications, IoT and cloud management systems. Many of these applications rely on EMF technologies to provide facilities for type safe storage and manipulation of millions of configuration and control parameters. Nevertheless, those practical model-based solutions are seriously hampered by a legacy, that is, metamodel induced database schemas must be maintained by design-time derived toolchains such as EMF/CDO. Thus, these solutions are hardly capable of automatically coping with a massive amount of frequently changeable instance data that is mostly regulated by a slowly, but steadily evolving set of type information controlled by some product life-cycle schemes. Therefore, an integrated validation mechanism of design- and run-time models should become part of any such industrial solutions. Also, the validation mechanism shall be both modular and capable of maintaining the instance data and the meta-model schemas in sync irrespective of their abstraction levels and design or run-time nature. This practicality requirement asks for a proper multi-level metamodeling technique, which supports the validation of the instantiation step not as an afterthought, but as a direct consequence of the underlying multi-level modeling formalism.
The paper describes our proposed solution, the Dynamic
Multi-Layer Algebra (DMLA), which represents a modular,
operation-based, multi-level meta-modeling approach with a
Zoltán Theisz
self-described, model intrinsic validation mechanism to
automatically evaluate every potential change of its
encompassing multi-level meta-model. Most of our ideas and
solution techniques are the results of our hands-on experiences
we have gathered by analyzing real industrial information
models for several years. As a consequence, the current
DMLA version (v2.1), is not a theory any longer; we have also
implemented major parts of it as an executable demo, which is
available for download at [
Practical meta-model based applications show an increased
interest for both state-of-the-art and innovative modeling
technologies. OMG’s Meta-Object Facility (MOF) is still the
dominant meta-modeling approach used for industrial
applications. There are two reasons for this: 1) MOF's four
layer modeling architecture is easily comprehensible; 2) the
Eclipse Modeling Framework (EMF) has been maturing
during the recent years. However, new practical challenges,
for example, full life-cycle management of model-based
instances may require full-fledged multi-level meta-modeling.
These alternative techniques advocate an explicit distinction
between linguistic and ontological meta-models [
An important step forward to achieve expressive
multilevel meta-modeling is the Lazy Initialization Multilayered
Modeling framework (LIMM, [
DMLA aims to combine multi-level meta-modeling with
dynamic model manipulation, which also necessitates
nontrivial description of constraints on the instantiation steps
through meta-levels. Also, DMLA incorporates a fully
selfmodeled operation language, which is currently implemented
as a lightweight external DSL, called DMLAScript. Hence,
although on the surface, DMLA looks very similar to XMF
and XModeler [
The Dynamic Multi-Layer Algebra (DMLA) is a multilevel modeling framework that consists of two major parts: (i) the Core, a formal definition of the modeling structure and its management functions; (ii) the Boostrap, an initial set of predefined modeling entities.
The definition of the Core is based on Abstract State
Machines (ASM, [
Definition – The superuniverse |A| of a state A of the DMLA consists of the following universes: (i) UBool containing logical values {true/false}; (ii) UNumber containing rational numbers and a special symbol ∞ representing infinity; (iii) UString containing character sequences of finite length; (iv) UID containing all possible entity IDs; (v) UBasic containing elements from {UBool ∪ UNumber ∪ UString ∪ UID}. Additionally, all universes also contain a special element, undef, which refers to an undefined value.
The labels of the entities take their values from the following universes: (i) XID: UID, (ii) XMeta: UID, (iii) XValues: UBasic[] (contained primitive values), (vi) XAttrib: UID[] (reference to entities).
In ASMs, functions are used to rule how one can change the states. In DMLA, we rely on shared and derived functions. The current attribute configuration of a model element is represented via shared functions. The values of these functions can be modified either by the algebra itself, or by the environment of the algebra (e.g. by the user). Derived functions represent calculations which cannot change the model; they are only used to obtain and to restructure existing information. The vocabulary ∑ of DMLA is assumed to contain the following characteristic functions: (i) Meta(UID): UID, (ii) Attrib(UID, UNumber): UID, (iii) Value(UID, UNumber): UBasic. The functions are used to access the values stored in the corresponding labels. These functions are not only able to query the requested information, but they can also update it. For example, one can update the meta definition of an entity by simply assigning a value to the Meta function (although the new relation may be invalid based on the instantiation rules). Moreover, there are two other derived functions: (i) Contains(UID, UID): UBool and (ii) DeriveFrom(UID, UID): UBool, which check containment and instantiation (transitive) relations, respectively.
In a nutshell, the Core is the formalism, while the Bootstrap is the practical foundation for DMLA. The Bootstrap is an initial set of modeling constructs and built-in model elements (e.g. built-in types) which are necessary in order to adapt the abstract modeling structure to practical applications. The main idea behind separating the Core and the Bootstrap is to improve flexibility, but also to keep the formal definition: the algebraic part is relatively fixed and structurally self-contained; its purpose is to isolate itself from the certain particularities of the various bootstraps. This design makes it possible to replace the Bootstrap; hence, one can not only customize the basic modeling entities, but one can also re-define even the semantics of what valid instantiation means. A particular bootstrap seeds the meta-modeling facilities of generic DMLA formalism, thus, one may create a Bootstrap for simulating potency notion, another one for LIMM and a third one for power type behavior, etc.
The main elements of the current bootstrap (Fig. 1) can be categorized into four groups: (i) basic entities (blue boxes), (ii) built-in types (purple boxes) representing the primitive types available in DMLA, (iii) entities used in facilitating the introduction of operations in DMLA (green boxes), and (iv) validation related entities (red boxes).
Basic entities are the enablers of multi-level metamodeling in DMLA. They create the root of the meta hierarchy all other modelled entities rely on.
The Base entity is at the very top of the hierarchy, thus all other entities are instantiated from it (directly or indirectly). Base defines that entities can have slots (defined by SlotDefs) and ConstraintContainers. Slots represent substitutable properties, which are syntactically similar to class members in OO languages. ConstraintContainers (and the contained Constraints) are used to customize the instantiation validation formulae. Moreover, Base has two other slots, reserved for validation of those formulae, which enforce the basic mechanisms of instantiation validation for multi-level modeling as explained later.
The SlotDef entity is a direct instantiation of Base. It is used to define slots. Slots can contain ConstraintContainers, which grants them the capability to attach constraints to the containment relations defined by the slot. Moreover, SlotDef overrides the validation slots inherited from Base.
The Entity entity is another direct instance of Base. Entity is used as the common meta of all primitive and user-defined types. Entity has two instances: Primitive (for primitive types) and ComplexEntity (for custom types). All domain relevant entities further instantiate ComplexEntity.
The core entities needed to represent the universes of ASM in the bootstrap are: Bool, Number and String. All these types refer to sets of values in the corresponding universe. For example, the entity Bool has been created so that it could be used to represent Boolean type values within the model. Builtin types are relied on when a slot is filled by a concrete value and that value is not a reference to another model entity, but a primitive, atomic value. All built-in types are instances of Primitive.
All these entities representing the grammar of the operation language are defined in the AST subpart of the bootstrap under ComplexEntity. Moreover, there are also some extragrammar entities defined here that deal with ASM execution semantics of those operations by specifying for example the invocation mechanism and the handling of return values and variables. This aspect of DMLA is not discussed in this paper in detail.
In DMLA, the validation logic relies on the selection of two type specific formulae based on the meta-hierarchy of the element to be validated. These two types are referred to as alpha and beta. The Base entity contains the default alpha and beta formulae, which can be constrained by the instances via their own specialized definition of valid instantiation, provided that does not contradict the standard validation rules imposed by Base. The validation mechanism is detailed later.
In DMLA, if a model entity claims another entity as its
meta the framework automatically validates if there is indeed a
valid instantiation between the two. In DMLA 1.0 [
While implementing DMLA 2.0, we realized that by introducing operations into our framework we could describe validation formulae and their modular extensions, the socalled constraints, by attaching operations onto certain DMLA entities. Herewith, automatic model validation became a core feature. By further experimenting with this feature, we were able to establish a very compact though flexible validation system.
When we introduced operations into DMLA, the first technical issue was related to their representation. It was clear that operations must be described by DMLA modeling elements only, similar to other modeling entities in the Bootstrap. We have decided to base our representation on Abstract Syntax Tree (AST), where operations consist of entities representing their roles in the grammar such as expressions or statements. For example, the conditional statement (“if”) has three child attributes: a condition (expression), a true branch (statement), and an optional false branch (statement). Since all of these subparts are DMLA entities, validation rules are applied to them similarly to other entities, which created the self-describing facility of DMLA.
The second technical issue considered how and when the operations must be executed. DMLA’s practicality agenda aims at a virtual machine (DMLA VM) implementation similar to Java VM in order to interpret and execute operations. We have not reached this goal yet, but we have already defined and implemented an engine capable of parsing AST related DMLA entities and of producing executable Java code from the model. Currently, the generated code can be automatically integrated into the program, which is running the Core of DMLA’s ASM implementation. Since the validation logic of the bootstrap is in its entirety described in DMLA operations, its semantics can be completely and consistently updated by simply changing the model.
The last technical issue focused on the effective
manipulation of the operations within DMLA. Since DMLA
2.0’s formal entity syntax is 4-tuple based [
In DMLA, the validation logic of instantiation relies on the selection of two type specific formulae based on the hierarchy of the element to be validated. We refer to these two types of formulae as alpha and beta. The alpha type formulae have been designed to validate an entity against its instances, by simply checking if the instantiation relation can be verified between the two entities (meta and instance). During validation, the framework iterates over the entities of the model, and invokes the alpha type validation on every entity and its meta entity. In contrast, the beta type formulae are in context checks: they are used when an entity has to be validated against multiple related entities, typically the attributes of an entity. For example, cardinality-like constraints shall be evaluated by beta formulae due to the underlying one-to-many relation thereof. Note that the exact validation rules provided by the alpha and beta formulas are Bootstrap-dependent, thus, it is easy to re-interpret the instantiation logic by only modifying these formulae.
Modular validation in DMLA works via compatible constraint extension. It means that entities can copy or extend the validation logic of their meta entity, which grants a very high level of flexibility without any loss of expressivity. The integration of operation ASTs into the Bootstrap allowed it to contain executable logic. Therefore, any model entities may provide their own specialized version(s) of valid instantiation, provided there is no contradiction with the standard validation rules imposed by their meta type (meta formulae are automatically validated by the framework).In parallel to validation rules, constraint specification was also modularized in order to avoid repeated definitions by introducing a generic Constraint entity. Constraints describe reusable validation logic that can be attached to any entity. It is important though to mention that the validation of constraints is special because it is not enough to validate the (Constraint) entity itself, but also the entity the constraint is referring to. For example, a range checker constraint added to a slot describing a number attribute must validate the value of the attribute, not the constraint (definition) itself. This is why we added special formulae to Constraints: the constraint-alpha and constraintbeta aimed to validate the entity containing the constraint.
However, constraints are also special due to their life cycle.
Thus, in order to achieve self-describing multi-level validation we needed constraints which are able to govern their own (customized) life-cycle. E.g. a constraint can decide if its reinstantiation is valid, or not. This feature is encoded in two other operations (lifecycle alpha and beta). This feature is similar to a self-managed, customizable potency notion.
In summary, the validation of the Bootstrap is based on three pairs of formulae: 1) the alpha and the beta type validation formulae, which are applied to every entity of the Bootstrap; 2) the ConstraintAlpha and the ConstraintBeta formulae, which are extensions of the container entity’s alpha and beta formulae; 3) the Constraint-LifeCycleAlpha and the ConstraintLifeCycleBeta formulae, which manage and validate the DMLA correct life-cycle of Constraint instances 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<Object>( firstNames, 0) != index<Object>( firstNames, 1);
Code 1 – The PersonAlpha operation }
In order to showcase how DMLA and its validation framework in practice, let us take the following example: we are creating the meta model of a person that has a name which consists of one or two first names and a single last name. There is also a constraint imposed on every person, namely that a person cannot have matching first names: e.g. “Bob Smith” and “Bob Rob Smith” are valid, but “Bob Bob Smith” is not. In order to turn this specification into DMLA entities, only a few steps are required. As usual in modeling, one has to create customized composite entities to represent these concepts. In the current Bootstrap, the entities are instances of ComplexEntity, which enables having an arbitrary amount of attribute slots within.
First, the ComplexName entity is defined to encapsulate the parts of a person name. It has two slots: one for the first name(s) with [1..2] cardinality, and another one for the last name with [1..1] cardinality; both being of type String. Secondly, the Person entity is defined, which contains a single slot with [1..1] cardinality, and is an instance of ComplexName. Now, the structure having been set up, validation follows.
As explained earlier, validation in DMLA is based on two operation types: the alpha and the beta type formulae. The core validation logic is defined in the alpha and beta formulae defined inside entity Base, which is the root meta of the Bootstrap (all other entities are direct or indirect instances of Base). Since in the example the validation logic can be evaluated on a single Person instance without considering any of its context (matching name constraint is contained within Person), one only has to override the alpha formula. In order to do so, an additional operation must be attached to Person describing the customized alpha validation logic. The alpha formula (Code 1) is a simple operation, it accepts two IDs, an instance ID and a meta ID, and it returns true if the metainstance relation is valid in this regard. The logic of the operation is written in DMLAScript. When it comes to execution, the validation logic is first translated into 4-tuples, that is, into DMLA native entities, and then the tuples are compiled into Java code that represents the ASM compliant behavior in JVM carrying out the validation.
DMLA went through various stages during the last few years, from the pure theoretical foundation to the implementation of a highly modular and practical multi-level meta-modeling framework of industrial focus. Although the current implementation is still pre-alpha, model validation has become flexible and modular enough due to DMLA’s powerful self-describing formalism. By now, we have started producing realistic bootstraps to cover industry induced use cases. Currently, our research goals aim at introducing executable semantics via operations, polishing 4-tuple generation, and streamlining the Java based execution engine for DMLA’s ASM virtual machine.