An aggregation is a special kind of association—a “whole/part” relationship within which one or more classes are parts of a larger whole. A class can be aggregated to one or more other classes.

Using aggregation is an excellent way to establish a “pecking order” of complexity, with more complex classes aggregating less complex ones. For a system of any size, doing this can only help viewers of your models more easily understand the concepts that are important to them while enabling them to ignore concepts expressed at lower levels of detail.

An aggregation appears as a line with an open diamond at one end. The class next to the diamond is the whole class; the class at the other end of the line is the part class. See Figure 2-7.

Figure 2-7.  Aggregation notation

If a given class aggregates more than one class, you can show each aggregation using a separate line, or you can consolidate the lines. Figure 2-8 shows both variations.

Figure 2-8.  Aggregating multiple classes

A class can also aggregate itself, as shown in Figure 2-9.

Figure 2-9.  Self-aggregation

This self-aggregation construct is useful in situations such as those that involve “rollups” for reporting purposes. (A rollup is a consolidation of information expressed at one or more particular levels of detail into a higher level of detail.)

Figure 2-10.  Aggregations

NOTE Multiplicities now appear on each aggregation relationship. If an aggregation doesn’t show multiplicity values, the default is many (*) parts and one whole.

Figure 2-10 shows that an instance of the Order class aggregates one each of instances of the ShippingInfo and BillingInfo classes and one or more instances of the Book class. An important property of aggregation is that the aggregated classes are still basically independent of the aggregating class. In other words, when a particular Order goes away (because it’s been archived, for example), the ShippingInfo and BillingInfo instances that were aggregated to that Order are still present in the system. (The Book instance, of course, is gone.)

Composition is a “strong” form of aggregation. There are two differences between composition and regular aggregation, as follows:

• Within a composition relationship, the whole and the parts have coincident lifetimes. This means that if a particular instance of the whole is destroyed, so are the instances of the parts.

• A class can only belong to one composition relationship at a time as a part.

Figure 2-11 shows an example of a composition relationship.

Figure 2-11.  Composition

This relationship specifies that a GLAccount in a composition relationship with a particular GeneralLedger is destroyed when that GeneralLedger is destroyed.

Composition versus aggregation is generally an issue that comes up during activities such as physical database design. It’s not generally a distinction that you need to worry about at, say, the analysis level.