2.3 CATEGORIZATION ISSUES

A whole set of modelling issues is poorly handled by conventional modelling languages but is crucial for the modelling of methodologies and endeavours: representing categories of things. We have shown that the modelling language given by a metamodel not only must be able to express the kinds of work products, work units and producers that appear in methodologies, but also the work products, work units and producers that appear in endeavours. In consequence, a metamodel was defined as a domain-specific language oriented towards the representation of software development methodologies and endeavours. As a result, a metamodel that represents both methodologies and endeavours will contain concepts such as work product and work product kind; work unit and work unit kind; producer and producer kind. On the one hand, it is evident that the two concepts in each of these pairs are closely related; on the other hand, most people would recognize that these are distinct concepts. What is the different between a work product and a work product kind? Can we point to a work product and then to a work product kind? Can we find definitions for these concepts? Can we establish how they are related to each other? The correct representation of these pairs of concepts, as well as the appropriate interconnection of the elements in the pair, is crucial to implementing categorization in the metamodel.

The next sections look at this problem using the example of a veterinary management system and then a metamodelling scenario.

2.3.1 Veterinary Management System Scenario

Let us imagine a veterinary management system that must keep a database of animal species, including, for each one, details about its average lifespan, usual diet and recommended vaccinations. Also, the system needs to keep a pet database that will allow the vets to keep track of their patients (Figure 2.13).

Figure 2.13: Basic data model for the veterinary management system

The link between the species database and the pet database allows vets to access a wealth of information about any pet as long as the appropriate species has been selected for the pet. In other words, when the vet enters a new pet in the database, she is responsible for categorizing it into one of the existing animal species in the database. Figure 2.14 shows some instances of the system, and how the association between AnimalSpecies and Pet serves as a bridge that allows navigating from a pet instance into its category (an animal species instance).

Figure 2.14: Instances in the veterinary management system model

This data model may work well under simple situations, but cannot cope with more complex needs. For example, how could we represent specific characteristics of each animal species? For instance, cats and dogs have a breed, but snakes do not. Snakes, however, may be venomous, but this is irrelevant for rats and cats. A naive approach would be to use specialization (Figure 2.15) to capture species-specific characteristics.

Specialization works well in isolation and Figure 2.15 is correct on its own. However, when we focus on, for example, the Cat subclass, and put it together with Figure 2.14, we obtain Figure 2.16.

The concept of the cat species was initially represented as an instance of AnimalSpecies, i.e. as an object. Now, because of the need to capture species-specific characteristics, it has been modelled as a class. Our model, in fact, is representing the same SUS concept (cat species) using two model units at the same time: a class and an object. Both of them refer to the same entity in the SUS, but stress a different aspect of it. The object in the model describes its data, whereas the class in the model captures the fact that it can be used as a template to generate instances (such as “Valentina” in Figure 2.16).

Neither is this a case of redundant data. Removing one of the facets of cat in Figure 2.16 would remove valuable information from the model that is not provided by the other; it is the combination of both facets that makes up a comprehensive description (object) and useful specification (class) of the cat species.

Figure 2.15: Using specialization to model species-specific characteristics; subclasses Dog, Cat, Rat and Snake have been added with specific attributes where necessary

Figure 2.16: The cat species is represented in the model by a class and an object, as depicted by the ellipse

The situation described here can be formalized by introducing some new terminology. First of all, a class–object pair that represents a single concept (such as the cat species in our example) can be called a “clabject” [1]. The ellipse in Figure 2.16 thus encloses a clabject. A clabject is a dual entity and can be thought of as being composed of a conventional object-oriented class plus a conventional object-oriented object, both of which represent the same SUS entity. Alternatively, one can think of it as a multifaceted entity possessing both an object facet and a class facet. Clabjects have been described by [2] in a different metamodelling context.

Furthermore, it can be seen that the class facet of the clabject in Figure 2.16 is a subtype of Pet, whereas its object facet is an instance of Pet's categorizing class, AnimalSpecies. We will find this pattern repeatedly, where the class facet of a clabject is a subtype of a given class and the object facet of the clabject is an instance of the class that partitions (or categorizes) that class. Notice that, in our example, AnimalSpecies could be safely called PetKind or PetCategory. Using the species of the pet is just one way of categorizing or partitioning the class of pets into subsets; the necessary semantics for clabjects and categorization to work only require that the class of the object facet of the clabject (AnimalSpecies in our example) represents a category of those elements represented by the superclass of the class facet of the clabject. According to Odell [31], the class of the object facet is a powertype of the superclass of the class facet, and this is partitioned by the former (Figure 2.17).

Figure 2.17: Formalizing the model of Figure 2.16, a different notation is used to depict the relationship between the powertype and its partitioned type

A powertype, together with the type that it partitions (its partitioned type), forms a powertype pattern [16], i.e. a tightly bound whole that represents a concept (given by the partitioned type) plus a particular way of categorizing it (given by the powertype). At the same time, each class in the pattern retains its autonomy and can function as a class for instantiation and subclassing purposes. Also, notice that any concept can be partitioned according to multiple criteria; for example, pets can be categorized according to their species but also according to their quarantine requirements. This means that, in addition to the powertype pattern Pet/AnimalSpecies shown in Figure 2.17, a different one could be composed between Pet and QuarantinePetClass. The specific criterion that is used to partition a type into a powertype is called a discriminant.

2.3.2 Metamodelling Scenario

A key component of most metamodels for development methodologies is a work-related element named “task”. We discussed, in Section 1.1.3, the various meanings that different communities may associate with this term. We argue now that the confusion and misunderstanding that often occurs in this regard comes from the fact that the concept of task in metamodelling is not a simple concept but a powertype pattern, i.e. a partitioned concept plus a particular way of categorizing it. If this is true, a metamodel should consider both tasks and task kinds or, in other words, endeavour-level managed intervals of time (tasks), plus their methodology-level representations (task kinds). This can be captured, at the metamodel level, by a powertype pattern structure, which, at the method level, generates the necessary clabjects (Figure 2.18).

Figure 2.18: Powertype pattern between Task and TaskKind at the metamodel level, which generates clabjects at the method level