The OMG's MOF Standard
The meta object facility (MOF) is a standard for the management of metadata publicized by the Object Management Group (OMG). A wide array of technologies which are standardized by the OMG (including UML, IMM, BPMN, Software Process Engineering Metamodel (SPEM) and various UML profiles) use MOF and/ technologies derived from it (XMI in particular) for the metadata-oriented exchange and processing of model information.
4-Layered Architecture for Metadata
The classic approach to meta modeling is based on a 4-layered architecture. These layers are normally described i the following way:
- The "information" layer contains the data to be described from the "real world". As this is the bottommost layer of this architecture, this layer is also abbreviated to "M0" (metalevel 0)
- The "model" layer (M1) is used for describing information from the real world, i.e. data from the M0 layer below, and classifying it. Data in the M1 layer contains information about metadata used for describing data from the "information" layer. All of these metadata are, therefore, also known as a model.
- The "meta-metamodel" layer (M3) behaves with the M2 layer below it in the following way: its data describes and classifies the structure and semantic of a model's information. Consequently, data in the M2 layer is referred to as meta-metadata. All of these meta-metadata are, therefore, also known as a metamodel. A metamodel can also be expressed as an "abstract language" which can be used to describe various types of information. The way in which this description can be carried out is initially open.
- The "meta-metamodel" layer (M3) behaves with the M2 layer below it in the following way: it is used for the structural and semantic description of meta-metamodels. A meta-metamodel can also be expressed as an "abstract language" which can be used to describe various types of metadata.
If you look at this 4-layer architecture in a different way, you can always access a value from a layer as an example (instance) of an information entity from the layer below. This relationship can often be recognized by the "instanceOf" key word.
MOF is used by the OMG as a standardized "metalanguage" to specify other modeling languages, such as e.g. UML. This is why MOF is a standard for the M3 layer in the 4-layered architecture for metadata. The following illustration shows the connection to the UML standard.
Figure: 4-Layered Metadata Architecture (Compare UML 2.4.1 Infrastructure, Figure 7.8)
The MOF 2 specification is similar in many respects to the "UML 2 infrastructure" specification as parts of this specification were reused, e.g. the notation in the form of class models (see below), MOF 2 then essentially expands this to concepts for a metadata management.
If you transfer this 4-layered architecture to the Innovator architecture, the following illustration can be seen:
- The M3 layer is a fixed component of the Innovator model server and cannot be changed.
-
- The actual modeling takes place in the M1 layer. The tool window, diagram editor and table editor which the user of an Innovator model works with can be used for this layer.
- The M0 layer represents the real world and is, therefore, not a typical part of a model. It is, however, possible to model instance specifications as an "object" type of the real world in Innovator for Software Architects.
Understanding Metaclasses, Meta Attributes and Meta Associations
The Meta Object Facility uses class models for specifying metamodels. If you can read class diagrams, you should also essentially be able to read and correctly interpret MOF-compliant metamodels. The most important properties of the metaclass, meta attribute and meta association base constructs which you should know are covered in this chapter.
Metaclasses
The purpose of a class is to classify data from the metadata architecture's layer below using common properties. A metaclass is, therefore, a combination of similar model elements into one common super term, also known as "element type" in Innovator models. A class is shown as a square, the "classifier" icon.
The following illustration gives an example of both the "association" and "class" metaclasses which are both components of the UML 2 metamodel. These metaclasses can be instantiated in a model: Both the "person" and "car" classes in our example are instances of the "class" metaclass; the "person.car" association between both these classes is an instance of the "association" metaclass.
Figure: Example of Metamodeling (Compare UML 2.4.1 Infrastructure, Figure 7.6)
Meta Associations
An association between two metaclasses states that two instances of the associated metaclasses (i.e. two metadata of one model) can be related to each other.
Only binary associations can display aggregations (i.e. a part-whole relationship). The association end which the metaclass for the "whole" is on is a rhombus. If this rhombus is filled black, it is then a strong aggregation relationship (composition). The following applies in this case: if the "whole" is deleted from a composition, all "parts" are automatically deleted with it.
An arrowhead at an association end shows that this is a navigable association end. Navigable ends are used to be able to directly access the runtime of data on this side of the association. Any number of ends of an association can be navigable. Regardless of this, it is also possible for modeling tools to navigate non-navigable association ends.
The subsetting is an important set-theoretic concept that can be used not for the association itself but for its association ends. This concept signifies that the multivalue on an association end a, which is a subset of an association end b, is either identical to the multivalue of b or is an actual subset of this multivalue. Subsetting is used more and more frequently when defining metamodel extensions; this is done to formulate constraints for stereotypes.
Meta Attributes
A meta attribute is either an attribute of a metaclass or an association end of a meta association. The type of such an attribute sets which values are allowed as metadata in the model.
The properties of attributes and association ends can be specified in more detail using various key words:
-
If an association end is labeled as {ordered}, the metadata's multivalues can be assigned according to a given sort criteria.
-
The {non-unique} key word means that the metadata's multivalue can contain duplicates. If this key word is missing, the values of the multivalue can be easily distinguished from one another.
-
If an attribute is marked as {readOnly}, an initial value which once entered, cannot then be changed at a later date.
-
A derived attribute can be distinguished by a forward slash in front of the attribute name ("/name"). The value of a derived attribute can be calculated using other information. The calculation rule for this can e.g. be described in the form of a constrained expression in the OCL language.
Derived attributes are often marked as {read-only} (see above) so that the attribute value can only be calculated once and then not changed again.
- A derived association role can also be marked as a derived union using the keyword {union}. This conveys that the multivalue of an association role labeled as "/<role> {union}" is calculated as follows:
All subsets of this association role are taken into consideration, as well as all roles marked with {subsets <role>}
A derived union is made from these subsets.
Important:
An association role a can only be marked as a subset of another role b ("a {subsets b}") if its multivalue conforms to the multivalue of role b. This is normally the case if the metaclass linked to the role a is a specialization of the metaclass which is linked with the role b.
The derived union of an association role is only a calculation rule; the actual multivalue depends on the number and size of the non-derived subsets of this association role and re-ensues for each metaclass when possible.
Related Topics
