Generalization refers to a relationship between a general class (the superclass or parent) and a more specific version of that class (the subclass or child). You can think of the subclass as being a “kind of” the superclass.

A generalization appears as a line with an open triangle at one end. The class next to the triangle is the parent/superclass; the class at the other end of the line is the child/subclass. See Figure 2-12.

Figure 2-12.  Generalization notation

If a given class has more than one child/subclass, you can show each generalization using a separate line, or you can consolidate the lines, as with aggregation. Figure 2-13 shows both variations.

Figure 2-13.  Generalizing multiple classes

Figure 2-14 shows a sample generalization.

Figure 2-14.  Generalization

Note the change between Figure 2-14 and Figure 1-3 (see Chapter 1): The operations that used to belong to the Review class have been “pushed down” into Customer Review. This is because these methods don’t apply to the new Editorial Review class. This is a good example of how the subclass, Customer Review, specializes the more general superclass, Review.

We’ve only looked at “single” inheritance to this point, but the UML also offers a way to model multiple inheritance—in other words, generalizations within which a class is a child of two or more parents. The basic notation is the same; the diagrams just get a little harder to read. Multiple inheritance is something of a tricky subject that’s outside the scope of this book, except as referenced in the following paragraphs. (It’s also something that some implementation platforms, such as .NET, and languages, such as C#, don’t support.)

You can use a generalization set to define partitions for the subclasses of a particular class (the superclass). The superclass acts as the powertype for the generalization set, which means that the instances of that superclass are also subclasses of another class.

Within Figure 2-15, PaymentType serves as a powertype on Payment.

Figure 2-15.  Powertype

In other words, the instances of PaymentType include those named CreditCard, CorporateAccount, and GiftCertificate—each of which is, in turn, a subclass of Payment. Each of these classes forms its own generalization set; this provides the modeler with extra flexibility in defining behavior associated with each subclass.

The UML offers the following four constraints (see the section “More About Operations” in Chapter 1), which you can use in conjunction with generalization sets:

• The {incomplete} constraint means that not all children have been speci fied for a given generalization set and that more can be specified.

• The {complete} constraint means that all children have been specified for a given generalization set and that no more can be specified.

• The {disjoint} constraint means that given multiple inheritance, no object can be an instance of more than one child within the generalization set.

• The {overlapping} constraint means that given multiple inheritance, an object can be an instance of more than one child within the generaliza tion set.