4.5 SOLUTIONS AND GUIDELINES

The best architecture of a multi-layer framework for metamodelling is still uncertain. The ANSI/OMG four-layer approach [17; 33], shown in Figure 2.19, has been used for the longest period of time but has led to the discovery of very many anomalies in its use, particularly when product and process modelling are integrated. The Orthogonal Classification Architecture has also been proposed [6], perhaps together with the notion of standardizing a language over a combination of two layers (Figure 4.20) [7]. As an alternative, the practice-based architecture of Figure 2.20 is newer but supports the use of powertypes more successfully within a single “metamodel” layer.

The integration of process and product aspects of a methodology has led to many apparent paradoxes, resolved either by potency or powertypes (see Chapter 5) but deeper analysis leads to the identification of more and more anomalies. For instance, when one instantiates a class (in object-oriented terms), one gets an object – which is itself non-instantiable. Consequently, since the UML metamodel (OMG level M2) consists of classes (sometimes labelled as metaclasses but with no stated differentiating semantics), one would anticipate that the instantiated M1-level entities should be objects, yet they are normally understood to be classes (e.g. in a user-drawn UML class diagram). Indeed, the whole OMG architecture is based on the notion that the instance of an M3 class is an M2 class and the instance of an M2 class is an M1 class. Only the instantiation of an M1 class results in an object. There is a missing metatypical mapping, as identified in [20] and demonstrated in Figure 4.4. This needs to be made visible.

A second issue is the realization that there are in fact two distinct kinds of metamodelling: linguistic (or logical) and ontological (or physical). One normally thinks of metamodelling in software engineering in terms of the UML/MOF hierarchy which is focussed primarily on linguistic modelling. In this case, the guideline is that the SUS and the modelling language used to describe the SUS are different e.g. bank account as opposed to UML Classifier. When ontological modelling is accidentally interspersed, this is readily identifiable by the fact that apparent metaclasses are in the same domain and use the same modelling language and terminology e.g. breed as a metaclass for dog.

A common problem observed (as outlined above) is the intermixing of metalayers in one diagram. Based on traditional object-oriented modelling, one would expect only one example of, say, Class in the metalevel diagram with several example instances of that class in the layer below. This ties in strongly with the notion that the Type-Object relationship can be represented by set theory or category theory as a useful basis for object orientation [45]. A test therefore is whether there are linguistic classes such as Classifier or Operation in the same diagram as multiple classes all with the same domain-specific name (as in Figure 4.21). A subsidiary test for ontological modelling is whether a generalization could alternatively be used; for instance, many stereotyped classes can be more appropriately modelled as a class and its superclass.

A second common problem, often linked, is that of scoping. Many fragment metamodels, as used in method engineering, state that they define a “fragment” but in fact have a much broader scope, bearing on domains at very different granularities or purpose. Another example is the number of classes in MOF 1.0 which far exceed the minimum set envisaged by e.g. [41] or CDIF [25]. Guidelines here require simply common sense and a tighter constraint on what is and isn't in scope.

A final rule of thumb is provided by Atkinson et al. [8] who suggest that, when evaluating if a particular stereotype named “S” is appropriate, we should ask the following question: “Do I under any circumstance want instances of the stereotyped element to be understood as ‘S’ instances?” If the answer is yes, then the stereotype name is wrong. These authors offer, as an example, the case in which an OnlineGame instance ought to be regarded as an “applet” instance – “Applet” is a good candidate for an Applet superclass name, but not for the stereotype. Atkinson et al. note that a good guideline is to remember that, just as a class name dictates what its instances (i.e., objects) are (e.g., applets), then any good stereotype name should similarly spell out what its instances (i.e., types) are (e.g., AppletType).

These insights, rules of thumb and guidelines, appropriately applied by all metamodellers, should increase the quality of all metamodels as needed for an increasing number of aspects of modern-day software engineering.