4.1 TERMINOLOGY AND CULTURE CLASHES

Taking UML as an exemplar use of the four-layer, strict metamodelling architecture, we first note the ambiguity engendered when one also applies the standard Type–Object model of object technology. Figure 4.1 shows that the object book1 is of type Book, i.e. there is an instance-of relationship from book1:Book to Book. In contrast, the analyst is not concerned with individual book objects but wishes to model, for a library information system, the requirement that a library contains many books. The simple model shown in Figure 4.2 illustrates this by the use of two classes, Library and Book, related with a one-to-many association relationship. Since both Library and Book are classes, they can be shown as instances of the M1 class, Class (Figure 4.3). This is standard object-oriented modelling (with UML or any equivalent modelling language).

Figure 4.1: In traditional object-oriented modelling, an object (book1) is an instance of a class (Book)¹

Figure 4.2: Simple object-oriented model in which a library houses many books

Although this is widely accepted as the standard approach to creating an (M1-level) object-oriented class model, further consideration of Figure 4.3 leads to the realization that since (M2) Class is in fact a class, its instances must be objects; in other words, both Library and Book are in fact objects not classes.

Figure 4.3: Object-oriented model of Figure 4.2 explicitly showing instantiation relationships to class Class

Figure 4.4: A virtual mapping is needed from a new object ob1:Class to the Book class (adapted from [20])

Source: Gonzalez-Perez and Henderson-Sellers, 2007, copyright Elsevier. Reproduced with permission

What is occurring (as pointed out in [20]) is that by sleight of hand, the modelling has introduce a virtual mapping from ob1:Class to Book (Figure 4.4), thus preserving all the tenets of both strict metamodelling and object modelling.

In order to make this mapping explicit, various authors have differing solutions. Johnson and Woolf [27] have proposed a pattern called “Type-Object” that can be used to “decouple instances from their classes so that those classes can be implemented as instances of a class”. Pirotte et al. [37] introduce a “materialization relationship” (although admittedly in the context of database modelling not object modelling) and Odell [32] introduces the notion of a “powertype”, which coincidentally has very similar properties to the database materialization solution published at almost the same time. Of these solutions, it is the last that has found more recent use in the context of metamodelling and the one that we will explore most in this book (it is one of the foci of Chapter 5), in parallel with and in contrast to the established, traditional strict metamodelling approach used in the UML.

In a modelling language, an important relationship is that an Object is an instance of a Class (which acts as a Type). Thus, as shown in the M2 layer of Figure 4.5, a language such as UML is likely to include two concepts in the metamodel, one for Class and one for Object and a instance-of relationship between them.

Figure 4.5: The object wilhelmina is an instance of both the M1 class Cat and the M2 class Object, in violation of the rules of strict metamodelling

Strictly speaking, this is a violation of the strict metamodelling principle (which is why it no longer exists in Version 2 of UML). However, to expound the resultant dilemma, an actual object, say wilhelmina, which is of type Cat, must have an instance-of relationship to the (M1) Cat class. In turn, in normal object-oriented modelling, the (M1) class Cat is said to be an instance of the M2 class Class (with the caveat discussed above and exemplified by the sleight of hand proposed in Figure 4.4). On the other hand, wilhelmina is an object and therefore could be reasonably said to have an instance-of relationship to the class Object in the M2 layer. Of course, this is now seen to violate two aspects of the UML strict metamodelling rules: (1) an object is an instance of two classes simultaneously and (2) an instance-of relationship has been introduced that crosses two meta-boundaries. This well-known conundrum results directly from the adoption of strict metamodelling and standard object modelling. We do not attempt to resolve it here but it forms an ongoing discussion point both in the community and in this book.