« Introduction to the weblog | Main | 5.0 Multiple inheritance, composition »

September 28, 2004

4.0 Compound subclassing

Previous post in category

Compound subclassing (aka multi-directional subclassing) occurs when the same class is the root superclass for two different subclassing relationships:

[Screw] -------+ +----------- [StockItem] +threadSize | | + quantity | | R1 +---|> [Part] <|----+ R2 | | | | [Washer] ------+ +----------- [SpecialOrder] +diameter +leadTime

Here we can subclass [Part] in two quite different ways. The interesting issue here is: What properties does a Part object have? That depends upon whether the relationships are joint or disjoint. (Though the subsets of each individual relationship are constrained to be disjoint, the subsets across relationships are not so constrained.) In UML whether they are disjoint or not is determined from the relationship names (discriminators R1 and R2 in this case). If the names are different, that indicates the relationships are joint (i.e., the union of members of each relationship's subclasses is the same as the union of members of the other relationship's subclasses). In that case the actual object properties are determined in a combinatorial fashion. Thus every Part instance will be one of the combinations: {Screw, StockItem}, {Screw, SpecialOrder}, {Washer, StockItem}, or {Washer, SpecialOrder} and will have all of the properties of the combination.

If the names are the same (e.g., both discriminators might be "R7"), that means the relationships are disjoint (i.e., each subclass represent a unique subset of [Part] members). Thus every Part instance must be a member of exactly one subclass from one relationship. This form is rather uncommon because one could just as easily create a single disjoint subclassing relationship. It is also uncommon because it implies a Part is needed in two very different contexts (e.g., POS catalogue descriptions vs. inventory control). Given the need to properly partition the application based on cohesive subject matters (see Application partitioning category), this is rather unlikely.

[The joint case can also be reified to a single subclassing relationship where the subclasses are identified combinatorially. However, that can get out of hand quickly when there are lots of combinations. (If each relationship had four subclasses there would be sixteen combinations.) Thus the joint case tends to be more common because it compacts the model.]

previous post in category

Posted by HS in Relationships | Permalink