27.2. Aggregation and Composition

Aggregation is a kind of association used to model whole-part relationships between things. The whole is called the composite.

For instance, physical assemblies are organized in aggregation relationships, such as a Hand aggregates Fingers.

Aggregation in the UML

Aggregation is shown in the UML with a hollow or filled diamond symbol at the composite end of a whole-part association (see Figure 27.5).

Aggregation is a property of an association role.^[1]

^[1] Recall that each end of an association is a role, and that a UML role has various properties, such as multiplicity, name, navigability and isAggregate.

The association name is often excluded in aggregation relationships since it is typically thought of as Has-part. However, one may be used to provide more semantic detail.

Composite Aggregation—Filled Diamond

Composite aggregation, or composition, means that the part is a member of only one composite object, and that there is an existence and disposition dependency of the part on the composite. For example, a hand is in a composition relationship to a finger.

In the Design Model, composition and its existence dependency implication indicates that composite software objects create (or caused the creation of) the part software objects (for example, Sale creates SalesLineItem).

But in the Domain Model, since it does not represent software objects, the notion of the whole creating the part is seldom relevant (a real sale does not create a real sales line item). However, there is still an analogy. For example, in a “human body” domain model, one thinks of the hand as including the fingers, so if one says, “A hand has come into existence,” we understand this to also mean that fingers have come into existence as well.

Composition is signified with a filled diamond. It implies that the composite solely owns the part, and that they are in a tree structure parts hierarchy; it is the most common form of aggregation shown in models.

For example, a finger is a part of at most one hand (we hope!), thus the aggregation diamond is filled to indicate composite aggregation (see Figure 27.6).

If the multiplicity at the composite end is exactly one, the part may not exist separate from some composite. For example, if the finger is removed from one hand, it must be immediately attached to another composite object (another hand, a foot, ...); at least, that is what the model is declaring, regardless of the medical merits of this idea!

If the multiplicity at the composite end is 0..1, then the part may be removed from the composite, and still exist apart from membership in any composite. So, if you want fingers floating around by themselves, use 0..1.

Shared Aggregation—Hollow Diamond

Shared aggregation means that the multiplicity at the composite end may be more than one, and is signified with a hollow diamond. It implies that the part may be simultaneously in many composite instances. Shared aggregation seldom (if ever) exists in physical aggregates, but rather in nonphysical concepts.

For instance, a UML package may be considered to aggregate its elements. But an element may be referenced in more than one package (it is owned by one, and referenced in others), which is an example of shared aggregation (see Figure 27.7).

How to Identify Aggregation

In some cases, the presence of aggregation is obvious—usually in physical assemblies. But sometimes, it is not clear.

On aggregation: If in doubt, leave it out.

Here are some guidelines that suggest when to show aggregation:

Consider showing aggregation when: The lifetime of the part is bound within the lifetime of the composite—there is a create-delete dependency of the part on the whole. There is an obvious whole-part physical or logical assembly. Some properties of the composite propagate to the parts, such as the location. Operations applied to the composite propagate to the parts, such as destruction, movement, recording.

Other than something being an obvious assembly of parts, the next most useful clue is the presence of a create-delete dependency of the part on the whole.

A Benefit of Showing Aggregation

Identifying and illustrating aggregation is not profoundly important; it is quite feasible to exclude it from a domain model. Most—if not all—experienced domain modelers have seen unproductive time wasted debating the fine points of these associations.

Discover and show aggregation because it has the following benefits, most of which relate to the design rather than the analysis, which is why its exclusion from the domain model is not very significant.

• It clarifies the domain constraints regarding the eligible existence of the part independent of the whole. In composite aggregation, the part may not exist outside of the lifetime of the whole.

  • During design work, this has an impact on the create-delete dependencies between the whole and part software classes and database elements (in terms of referential integrity and cascading delete paths).

• It assists in the identification of a creator (the composite) using the GRASP Creator pattern.

• Operations—such as copy and delete—applied to the whole often propagate to the parts.

Aggregation in the POS Domain Model

In the POS domain, the SalesLineItems may be considered a part of a composite Sale; in general, transaction line items are viewed as parts of an aggregate transaction (see Figure 27.8). In addition to conformance to that pattern, there is a create-delete dependency of the line items on the Sale—their lifetime is bound within the lifetime of the Sale.

By similar justification, ProductCatalog is an aggregate of ProductSpecifications.

No other relationship is a compelling combination that suggests whole-part semantics, a create-delete dependency, and “If in doubt, leave it out.”