Understand Modeling Aggregation

An aggregate object is an object built from other objects. In addition, the aggregate object is greater than the sum of its parts. All interactions with this assembly of objects are performed through the aggregate object interface. The component objects are hidden or encapsulated within the aggregate.
Aggregation uses a diamond to describe the association instead of a verb. A verb may be used, but usually the diamond is used without a verb for the association name.

Many modelers leave the multiplicity off the diamond/aggregate end, assuming a multiplicity of one.
Assuming is never a good option. There is no default value.

Aggregation is used for modeling both logical and physical assemblies. For example, a baseball team is a logical assembly. The coach and players work together as a unit. If the team is scheduled to play, then all the players and the coach are scheduled to play as a unit. A car, however, is a physical assembly with a number of component parts working together as a unit. To move the car forward requires that the parts work together in a prescribed manner and as a unit. A common characteristic of aggregates is that the parts may be changed over time. A team member may switch teams. An engine may be replaced in a car. Logical grouping and regrouping are common activities when working with aggregates. Changes in the parts imply the need to track the configuration of the aggregate object over time.

Watch for these key words and phrases in the problem statement:

1. Assembly
2. Part of
3. Consists of
4. Made up of

The word "contains" is sometimes used as well. I hesitate to use it because it is an extremely weak form of aggregation that lacks coordination among the parts that is typical of most aggregates. The only behaviors a container usually exhibits are adding and deleting members, finding, sorting, and managing space allocation.

Click the Exercise link below to draw a class diagram based on an aggregation example.
Modeling Aggregation - Exercise