Category list

Deciding between Aggregation and Composition

You might find it difficult to decide between modeling a relationship as an association, an aggregation, or a composition. Here are a few clues to look for when you’re modeling relationships:

If you hear words like “part of,” “contains,” or “owns,” then you probably have an aggregation relationship.
If the life-cycle of the parts are bound up within the life-cycle of the whole, then you have a composite .
If the parts are shared, then it’s an aggregation .
If the parts are not shared, then you may have composition .

Aggregations (and composition) also have two other identifying properties: they’re not symmetric but they are transitive. Hang on, these are fancy terms for a couple of simple ideas. An association is symmetric if it is the same thing in both directions. Think of the relationship between a generic report and one of its columns . Although it’s true that the column is part of the generic report, it’s not true that the generic report is also part of the column. (Seems obvious, doesn’t it?) When you’re deciding about whether you have a part-of relationship, ask the symmetry question. The transitive property is a fancy way of saying: If A is a part of B, and B is a part of C, then A is also a part of C.

Here’s a down-to-earth way to say that again: If a filament (A) is a part of a light bulb (B), and a light bulb (B) is part of a lamp (C), then the filament (A) is also part of the lamp (C). If you can apply the transitive property, then chances are you have an aggregation.

Table 5-1 summarizes these criteria to help you decide whether you have an aggregation, composition, or association.

Table 5-1: Aggregation Versus Composition: Clues
Decision Result	Criteria
Aggregation or Composition	Part-of, contains, owns words are used to describe relationship between two classes
Aggregation or Composition	No symmetry
Aggregation or Composition	Transitivity among parts
Composition	Parts are not shared
Composition	Multiplicity of the whole is 1 or 0..1
Aggregation	Parts may be shared
Aggregation	Multiplicity of the whole may be larger than 1
Association	Relationship does not fit the other criteria

Using Alternate Composite Notation

UML allows you to place a class diagram inside a class. When we’re talking about composites, this isn’t as strange as it may seem. Since the second compartment of a class shows structure, and a composite has complex structure within itself, then you can show the parts of the composite inside as a mini class diagram.

UML2 UML 2 has a new diagram name for this alternative notation: composite structure diagram.

Remember The UML notation for class has three major compartments:

The first compartment names the class, describes its stereotype and lists its properties.
The second compartment shows the structure of the class as a list of attributes.
The third compartment is where you place the class’s behavior specification.

This compartmentalization was allowed as an interesting idea in the previous version of UML 1.4. Most of the CASE tools, however, didn’t pick up on this idea. But that is changing with UML 2.0.

Showing parts as classes

Modeling the strong form of aggregation—composition—often results in a class diagram with lots of confusing lines. You have lines between the class playing the role of the whole and classes playing the role of the parts. You also have lines showing the associations between individual parts internal to the composite. With all these lines, the diagram can be difficult to read. UML 2 allows you to model composites and their parts as a class diagram within a class (composite structural diagram). This reduces the clutter and allows you to be clear about what you mean.

You can show the parts of a composite inside the structure compartment of a class by putting a box around the part and providing a name for that part: part name, then a colon , then a class name for the part. If you have more than one part of the same type in the composition, then you can show its multiplicity in square brackets. For example the Body part of a GenericReport would be surrounded by a box with detail:Body[1..*] inside, as in Figure 5-3.

click to expand
Figure 5-3: Composite parts shown inside a class.

Parts can also be connected by (you guessed it) connectors —lines that indicate links between instances of parts within a composite—so those parts may communicate with each other. UML 2.0 provides for two kinds of connectors—assembly and delegation. An assembly connector allows one part of the composite to supply services that another part needs. On the other hand, use a delegation connector to show the whole composite forwarding some external request for behavior to one of its internal parts. The assembly connector connects two parts like an association. The delegation connector connects the whole with one of its parts. The delegation connector is shown as a line from the edge of the composite class to one of the parts inside the composite class.

Figure 5-3 illustrates just such a diagram. The GenericReport class is playing the role of the whole or composite. The parts are anonymous parts with classes named Header, Column and Footer . One of the parts is named detail which is of the class Body . The parts are connected using lines that can be named just like associations. Indeed you can place multiplicity, role names, and qualifiers on these connections. Each of the connections shown in Figure 5-3 are assembly connections. For instance the Header will invoke the print service of Column .

Showing parts as attributes

This section ties together composites, part diagrams (those class diagrams inside of a class), and attributes. Figure 5-4 shows the class for GenericReport and its attributes. Notice the correspondence between the attributes in Figure 5-4 and the classes in Figure 5-3. The class definition in Figure 5-4 hides the internal structure of the GenericReport class by simply listing the major parts as attributes. The sqlStatement is not a part—rather, it’s one of the attributes of the GenericReport class.

Figure 5-4: Showing composite parts as attributes inside a class.

If you want to convert a simple class into a composite structure diagram, you can use Table 5-2 as a guide. The table shows the correspondence between attributes in a simple class diagram and the elements of a part diagram inside of a composite class. For instance the detail attribute of the GenericReport becomes a part with the same name in the composite structure diagram. The Body datatype becomes the name of the detail part’s class. The [1..*] multiplicity is carried forward to the multiplicity of the detail part.