6.5 Generalization and Specialization

All of the instances of a class must share common characteristics and common behavior. But we often face things that are somewhat common yet somewhat different.

6.5.1 The Concept of Generalization and Specialization

In Section 5.5: Checking Classes and Attributes, we presented a Product as an example of a uniformity problem. The online store sells more than just books; it also sells videotapes, CDs, DVDs, and computer software. All these products have a sale price and are identified by a universal product code (UPC). Books have an ISBN number; CDs, videotapes, and DVDs have a running time; computer software titles have version numbers. We noted a uniformity problem that made a single Product class undesirable and promised to show how to correct the problem.

An alternative to the single Product class is to have separate classes for each type of product, as shown in Figure 6.11. But while this is a more precise attribution, it isn't quite satisfying either. Attributes (and behaviors) that ought to be common are spread across many classes.

Figure 6.11. Separate Product Classes

The concept of generalization allows us to have the best of both worlds when confronted by this type of problem. We can have both a single Product class and individual classes for BookProduct, RecordingProduct, and SoftwareProduct. Figure 6.12 shows how these products may be partitioned into subsets, one for each kind of product.

Figure 6.12. Partitioning of Products into Subsets

Figure 6.13 models the Product class as a generalization of BookProduct, RecordingProduct, and SoftwareProduct. This means that the superclass Product contains attributes and associations applicable to all of the subclasses BookProduct, RecordingProduct, and SoftwareProduct. Likewise, BookProduct is a specialization of the Product class. It contains additional attributes and associations that are relevant only to books.

Figure 6.13. Product Generalization and Specialization

Definition: A superclass is a class that generalizes classes in a generalization-specialization hierarchy.

Definition: A subclass is a class that specializes classes in a generalization-specialization hierarchy.

Definition: A leaf subclass is a subclass that is not the superclass of any other class.

Each superclass and each subclass is a class like any other. It may have attributes and participate in associations. It must have a class description and descriptions for each attribute and association in which it participates.

Inheritance is a related, but different, concept. The UML Reference Manual [2] (p. 287) states: "Generalization is a taxonomic relationship among elements. It describes what an element is. Inheritance is a mechanism for combining shared incremental descriptions to form a full description of an element. They are not the same thing, although they are closely related." (See also the formal definition of UML in [3].)

The reference manual clearly distinguishes between the two concepts. Executable UML uses generalization and specialization, also called subclassing.

Of course, generalization and specialization can be implemented using inheritance, and inheritance can be used as an implementation mechanism in other contexts.

With the preceding in mind, we may now (finally!) define an object.

Definition: An object is an instance of a class, or an instance of several classes in a generalization-specialization hierarchy.

6.5.2 Mutual Exclusion and its Implications

Executable UML prescribes a strict mutual exclusion principle in defining generalizations: Each instance of a superclass must be one and only one of its superclasses, and each instance of a subclass must be an instance of the superclass.

Definition: An abstract class is a class whose instances can be created only in conjunction with an instance of one of its descendant subclasses.

In UML terms, all Executable UML superclasses are tagged {abstract} and all generalizations are tagged {disjoint, complete}. This means:

• Each Product must be one of the subclasses: a BookProduct, SoftwareProduct, or RecordingProduct. This makes the Product class abstract, because you can't make an instance of Product that is not an instance of one of its subclasses.

• Each Product must be one or the other of the subclasses. It is not possible to create an instance of a Product that is both a BookProduct and a SoftwareProduct ("disjoint").

We are careful to use "instance" to mean an instance of a class and to use "object" in the object-oriented way to mean an instance of a class potentially combined with instances of other classes in a generalization hierarchy to make a single object.

Hence, the instance of the class BookProduct for a book on Executable UML and an instance of the class Product for the same Executable UML book constitute a single object.

Superclasses in Executable UML are all abstract you cannot create an object that is only an instance of the superclass without its also being an instance of exactly one of the subclasses.

• The stated subclasses are the only subclasses of Product; there are no other hidden or unknown subclasses ("complete"). Since an Executable UML model is a precise specification, all subclassings are complete.

This approach supports the semantic modeling properties of Executable UML, and abstraction from things in the domain: the several products. Consequently, each product is a member of the superset and exactly one subset. The set partitioning is disjoint and complete as shown by the tag {disjoint, complete}.

6.5.3 Repeated Specialization

A class can be specialized repeatedly, as shown in Figure 6.14. Bank accounts can be subclassed into checking and savings accounts. A checking account can be further subclassed into regular and interest-bearing accounts.

Figure 6.14. Repeated Specialization

In cases of repeated specialization, all the non-leaf classes are abstract; hence the class CheckingAccount is abstract even as it is also a subclass.

6.5.4 Multiple Generalization

Consider now the hierarchy of Figure 6.15, in which a single subclass is the subclass of multiple superclasses. In this model, the class InterestCheckingAccount is a subclass of InterestBearingAccount and CheckingAccount. This is perfectly legal. Figure 6.16 illustrates how the accounts are organized into {disjoint, complete} subsets.

Figure 6.15. Multiple Generalization

Figure 6.16. Illustration of Multiple Generalization

However, when building these kinds of structures, watch out for "diamond generalization," as illustrated in Figure 6.17, wherein the same instance purports to be a subclass of two superclasses that have the same parent.

Figure 6.17. Improper Multiple Generalization

Here we have made the InterestBearingAccount a subclass of an Account. (After all, the InterestBearingAccount is surely some kind of account.) The result of this innocuous change is that an InterestCheckingAccount has a parent CheckingAccount that is a subclass of Account, and a parent InterestBearingAccount that is a different subclass of Account. The mutual exclusion rule forbids this. This situation is quite rare, but it is subtle and can cause a great deal of confusion.

6.5.5 Compound Generalization

In Figure 6.13 we subclassed Product into Book, Recording, and Software. In addition, some of each kind of Product are not actually kept in stock, but are special-ordered from the Publisher whenever ordered by a Customer. This subclassing is separate and distinct from whether the Product is a Book, Recording, or Software product. Figure 6.18 shows how we can represent this with a distinct generalization-specialization relationship.

Figure 6.18. Compound Generalization

UML allows Figure 6.18 to be an easier-to-draw version of a single hierarchy, if the association name is the same. That is, if both hierarchies were labeled R13, a Product would be just one of the five subclasses (Book Product, Recording Product, Software Product, In-Stock Product, and Special Order Product) as well as the superclass.

Formally, the relationship number here is called a discriminator.

We call this a compound generalization since the superclass is a disjoint, complete generalization in more than one hierarchy. Each generalization is shown as a separate relationship with its own triangle and collection of subclasses