Metamodels are one of the most important aspects of model-driven software development. Dealing with the following MDSD challenges requires knowledge of meta-modelling.
- Build a domain-specific modeling language (DSL): the metamodel describes the abstract syntax of this language;
- Model validation: the model is valid under the constraints defined in the metamodel;
- Model-to-model transformation: the mapping principle between two meta-models for which this transformation is defined;
- Code generation: generate template reference DSL metamodel;
- Tool integration: Based on the meta-model, modeling tools can be adapted to the respective domain;
1. Definition of Metamodel
A metamodel is a model for declarative modeling. More precisely, a metamodel describes the possible structure of a model -- it defines in an abstract way the components of a modeling language and their relationships, as well as constraints and modeling rules -- but not the language's Concrete grammar. We say that a metamodel defines the abstract and static syntax of a modeling language. And vice versa, every formal language has a metamodel, like Java or UML;
There is a class-instance relationship between metamodel and model: each model is an instance of metamodel, so defining a metamodel requires a metamodeling language, and the language is described by a metametamodel. In theory, this "cascading" of abstractions can be extended infinitely, but in practice other measures are taken.
In the context of MDSD, the domain's DSL is defined by a metamodel.
Relationship between reality, model, and metamodel
In principle, models can be described in any modeling language. The choice of language should be based on the language's suitability for the domain to be described. In real life, this decision is often determined by the question of whether there are practical tools available for the modeling language, which means that UML can now be used for modeling in many situations. It is therefore of great relevance to look at modeling in the context of UML.
Meta-relationships are usually model-relative.
OMG's Quad Layer
The construction Class in the UML meta-model is now an instance of the meta-element MOF Classifier. MOF classes are defined at the M3 level. Meta Object Facility MOF is OMG's meta-metamodel. MOF is used to define modeling languages such as UML at the M2 level. The idea behind it is that UML will not be the only modeling language, and that additional domain-specific and possibly standardized modeling languages will be defined based on MOF. MOF can also define non-object-oriented modeling languages.
In the OMG model, there is no meta layer above MOF - basically, MOF defines itself.
Part of interception in MOF
As the name MOF suggests, it is a meta-meta language based on the object-oriented paradigm. To this end, MOF borrows the kernel of classes from UML, using the same concepts and concrete syntax.
2. Comparing meta layer and abstraction layer
Models can have different relationships between them. Meta-relationships, which illustrate the concepts defined by the meta-model used to create the model.
On the other hand, models can be at different levels of abstraction even if they are on the same meta level. Typically, transformations are used to map models in higher model layers to models in lower abstraction layers, each model being an instance of the metamodel. So the two models are different, but model and metamodel can be found on the same meta layer.
3. MOF and UML
UML is an instance of MOF - an application. Various details must be considered.
First, UML existed before MOF. UML was originally defined formally -- that is, its knowledge was defined purely verbally. The subsequently defined MOF specifies that UML is formally based on MOF. Later versions of the UML definition overcome the problems caused by this sequence, so now UML can truly be a MOF language.
The notation of the MOF model is the concrete syntax of UML, which occasionally leads to confusion. Formally, this can be resolved by the specification of namespaces/packages for model elements, but there is still potential for confusion.
MOF contains many model elements that also occur in UML. For example, both languages have an element named Class. Even though elements have the same name and often roughly describe the same characteristics, they are not identical—as long as they are at different metalevels.
meta and abstract
4. Extend UML
In software development, you usually don't start by defining a whole new M2 language based on MOF, but you start with the UML metamodel and extend it when needed.
- Formal model extension based on UML
- Extended with class templates/profiles (UML1.x)
- Extended with class templates/configuration files (UML1.2)
1. Based on meta-model extension
This type of extension is to extend the metamodel of UML. For this, as is often done in modeling, a higher-level meta-level language is applied, in this case MOF. Such extensions can only be achieved with such tools if they possess a well-articulated, publicly available MOF-based metamodel.
Inheritance within the M2 layer
2. Extended with UML1.x category template
Extensions with class templates are a UML-specific feature defined as part of the configuration file mechanism.
3. Extended with UML2.0 configuration files
Use UML 2.0's Definition Extended Class Template mechanism and place it in the context of a more understandable configuration file mechanism. The concept of scaling is key here. Extensions are a new notation and a new UML language construct. It is represented as a filled inheritance arrow.
Another difference between UML 2.0 and UML 1.x is that a model element can now have multiple category templates at the same time. It then has all the attributes of the class template as tagged values.
Five, UML configuration file
Profiles support the adaptation and extension of UML to suit professional or technical domains. It may also be said that UML is not a language but a language family, in which case the UML profile is the element of the stroke - the concrete language. The goal is that UML tools and generators can handle configuration files like plugins. To this end, the OMG has defined a configuration file mechanism for UML.
UML now provides language options for expressing configuration files in UML and annotating its use with application models.
A configuration file is not self-contained. Instead it always relies on and uses a reference metamodel. This can be a UML metamodel, or an existing configuration file.
6. Meta-modeling and OCL
OCL is an acronym for Object Constraint Language. This is a conveniently declarative language with no downsides, and it is used to define constraints such as modeling rules based on the MOF modeling language. Constraints enrich the model with additional information about the validity of model instances. Constraints apply to applications at M1 and M2 layers.
7. Meta-modeling: Example 1
For illustration purposes, let us now build our own metamodel that is UML-independent, ie a metamodel that does not extend the UML metamodel. For example, using generative programming and feature models in the FODA approach.
8. Meta-modeling: Example 2
Another example of a metamodel is the extremely simplified component infrastructure available for small devices and embedded systems. The central ingredient of applications based on this infrastructure are -- obviously -- components. In the process of defining the architecture, it makes sense to define the content of a component, which is why it is necessary to define a metamodel for the components of this infrastructure in the first place.
Also, a component has many configuration parameters. To simplify the problem, these parameters must be properties of the component class of String type, because they are read from a configuration file when the system starts.
9. Model validation supported by tools
There are various tools that support meta-modeling. It is possible to distinguish the following alternatives:
- not support
- separate tool
- Integrated Modeling Tools
The most common use is to combine a UML tool with a separate generator/verifier. Unfortunately, integrated meta-modeling tools are still largely neglected by the market.
The generator takes all models as its input data. The parser analyzes these, and the metamodel instantiator then instantiates the resulting parse tree with the configured metamodel. Because different analyzers can be used in the generator, the format of the input is interchangeable.
10. Metamodeling and behavior
Behavior in the context of metamodeling is interesting in two ways. On the one hand, behavior can be hidden within the meaning of the metamodel, and on the other hand, the behavioral modeling can be explicitly accessed using metamodelling, for example, in the form of activity diagrams or state diagrams.
11. A more complex example
About the ALMA telescope. Data structures are defined in UML and various other artifacts are generated from it:
- XM L mode
- Wrapper classes for XML and (de)compilers implemented in various languages (C++, Java, Python);
- Converters for proprietary data formats
- Html documentation for the data model
1. Basics
First, a distinction must be made between entities and dependent objects. Entities have their own IDs and can be searched based on several attributes. An entity can be further divided into several parts, namely dependent objects. These dependent objects have no identity of their own and cannot be searched - only the entity holding them knows about them and can retrieve them. Sections can contain more sections.
2. Value type
There are other distinctions between data in the data model. Specific information, such as a star's position in the sky, is neither dependent on objects nor their underlying type. For this purpose, value types are introduced. Value types themselves have no identity: they consist only of their numeric value. Two value type instances with the same value are considered identical. Typically, properties defining entities or dependent objects can only be primitive types or value types, since these values are repeated in the system.
3. Physical quantity
Because ALMA is a physical measurement tool, the data it handles involves many physical quantities, so it makes sense to provide the physical quantities clearly as in the metamodel. A physical quantity has a value and a unit. Various physical quantities have certain defined units and value ranges.
12. Flaws in meta-modeling
This section gives some hints and tricks and exposes some pitfalls in metamodeling especially related to UML:
- The problem often arises in metamodeling that it is no longer obvious what notation has to be used;
- Stumbled upon finding myself in the wrong metalayer.
In general, it has proven helpful to ask the important question of how to implement a metamodel in a programming language. Conversely, it can be hinted what symbols are correct.
1. Interface
Problem: Wish to express the fact that the strength of a metaclass entity must implement a certain interface.
Correct solution: An entity's set of implemented interfaces must contain the interface stack. This can be represented by an OCL constraint, or by constructing a subset of meta-associations of words.
2. Dependency
Problem: Express the fact that components can depend on interfaces because they invoke operations on the interface.
Correct solution: define an association between component and interface and call it usage.
A component can use many interfaces and an interface can be used by many components.
3.ID
Problem: Entities must have one and only one String property called ID, which stands for identifying attribute or base key.
Correct solution: An OCL constraint is used, which stipulates that there must be a String attribute named ID in the attribute of the entity.
4. Basic keys
Problem: All instances of an entity must have one and only one attribute of type Entity PK among their attributes. Here, Entity PK is a special metaclass Attribute.
The correct solution:
correct metamodel
5. Meta layer and Instanceof
This section uses UML as an example to illustrate a pitfall in using complex modeling languages.
A UML class diagram and a UML object diagram are given. An object is an instance of a class defined in a class diagram. So far, the relationship between objects and classes is obviously an instanceof relationship, which further proves that multiple objects of the same class can exist. This is also the relationship between link and association.
This apparent contradiction is easily resolved by observing that the two instanceofs are not the same language construct.