“MOF and UML emphasize the linguistic dimension”, say Atkinson and Kühne [9]. For initial
modeling architectures, this was fine; it allowed the enactment of an easy to understand four layered modeling architecture called MOF. However, the demands on UML and other modeling languages grew and soon MOF’s foundations started to crumble. We describe in the current section some causes and effects of this process. First, we introduce some terms that are often used in the discussion about modeling architectures [9][7][5][10].
Terminology for Properties of a Modeling Architecture
Because meta and modeling languages are considered to be only structural definitions, they limit their semantics to the model at the layer below (M2 for metalanguages and M1 for modeling languages). Atkinson and Kühne call this shallow instantiation. The term strict
metamodeling is used for the modeling architectures, which only allow shallow instantiation
between the different layers and have a linear layer organization.
In the MOF architecture, each layer is defined in a layer above. The top layer is defined in itself. All layers thus have a lower and a higher layer. Through this, classes seem to play a double role in the modeling architectures. From the point of view of the layer above, they are objects. From the point of view of the layer below, they seem classes. This Class-Object duality can be observed in traditional modeling architectures. Atkinson and Kühne [9] explain how the syntax of modeling languages hides this dual nature of classes and objects. They introduce the term Clabject for it. The name of a class is displayed in its syntax, yet in reality, it is an instance of the attribute “name” from the defining class. To express this they created a cube to represent model elements (see Figure 3-2).
Figure 3-2 - A Clabject8
Ambiguous Classification
Multiple classification was an early problem in the interpretation of UML diagrams. As we
explained in the previous chapter, each model element has multiple instanceOf relations. Because the linear hierarchy of the initial MOF architecture, these multiple relations had to violate the strict layered interpretation as is shown in Figure 3-3. The revised architecture
that put user data models on the M1 layer partly solved this problem. It however deemphasizes the ontological instanceOf relation in which the user is interested [7].
Figure 3-3 - Multiple classification in the MOF architecture (taken from [7])
Decreased Extensibility
There is a need for reuse of metamodels [27]. The semantics of UML assumes that users will only work at modeling levels M0 and M1. However, in order to reuse metamodels their users generally need to also model at level M2. UML supports this by means of stereotypes, which can be bundled into packages of stereotypes using profiles. A profile can be introduced to reuse the UML language for a specific architecture. Java only supports single generalization, whereas UML by default uses multiple generalization. By creating a profile Java that contains a special stereotype <<JavaClass>>9 for Class the concept Class can be
restrained to only one generalization.
Stereotypes are however, limited to annotation of types and the addition of static attributes called Tags. This ensures that the stereotype mechanism does not break the strict modeling hierarchy and that stereotyped models remain compatible with their originals [6].
Stereotypes can thus be seen as a restricted way to generalize the instantiation concept over all the levels. It becomes an alternative way to express instantiation without adding modeling power [5]. This adds extra semantic and notational baggage. Furthermore, it creates confusion when there are no rules offered on when to use which mechanism and why, which is the case with the current UML version. Especially since the instantiation mechanism choice is not meta-level independent, defining such rules may be complicated.
Replication of Concepts
Previous versions of UML suffered from a replication of concepts because they had to model the structure of instances for each Class individually (Node, Component, etc) [10]. This problem seems solved with the UML 2.0 specification [75], which introduces a general InstanceSpecification construct. It is up to tool vendors to represent classes on this construct according to the UML semantics.
Failure to Express Power Types
“A power type is a type the instances of which are subtypes of another type (called the partitioned type)” [76]. A classical example is the TreeSpecies, which instances can be Elm, Oak, etc.
Obviously the latter ones are all types themselves. The partitioned type in this case is the Tree. The benefits of power types are that new types can be introduced dynamically, as instances. At the same time, this makes it hard to support power types, since they are also
specializations of the partitioned type. And - this is the problem - specialization is normally
done statically in modeling. Figure 3-4 shows this in an example with Vehicles, VehicleKind and Boat.
Figure 3-4 - An example power type (taken from [47])
Instantiation Semantics
Atkinson and Kühne tried to “compensate for shallow instantiation” in order to give semantics to MOF that keeps intact its strict modeling hierarchy. They feel this hierarchy is important, because “the strictness discipline was instrumental in uncovering and understanding
the subtle problems of the original presentation of the metamodeling framework. In the presented two dimensional framework, the strictness discipline is fully applicable and—like any guideline—provides help in staying away from unclear scenarios”
To compensate for shallow instantiation they evaluated the use of deep instantiation, an instantiation mechanism over multiple layers in modeling hierarchy. Potency is introduced to express the number of levels that the instantiation may cross. Dual fields naturally appear under these circumstances, because fields can be both attributes and slots (holding values).