Representing the Whole and the Parts

If you have a class such as car and you want to model the car and its parts (such as the engine, brakes, chassis, and wheels), you use aggregation. In UML, aggregation shows the relationship between the whole and its parts. Using the notation is simple; just follow these steps:

Decide which class is playing the role of the whole and which classes play the role of the whole’s parts.
Draw an association line between the class that is playing the whole (car) and each of its parts (engine, brake, and so on).
Place a small diamond shape on the association line, right up against the class that is playing the role of the whole (car).

We show an example of this diamond shape in Figure 5-1, later in this chapter. (We also talk about when to fill in the diamond as in Figure 5-1 and when not to as in Figure 5-2 later in the chapter.)

Figure 5-1: Example of composition, a strong form of aggregation.

Figure 5-2: A weak form of aggregation-some parts survive if the whole goes away.

Consider the multiplicity of this special association that is now an aggregation.

Usually the whole has multiplicity of one.

Consider the multiplicity of the each of the parts in relation to the whole.

For example, the engine has a multiplicity of one, and the wheels have a multiplicity of four (or five if you count the spare tire).

Modeling complexity

For the modeler, aggregation is important because it hides complexity. Objects are like black boxes: We can see the outside of the box but not what is inside. If an object is really an aggregation of parts, then the inside of the box may be complex. A car, for example, is a complex object—and (as with a black box) we don’t have to understand all its internal parts to use it. The aggregation notation helps the modeler handle complexity by building two diagrams:

External associations of the aggregate: On this class diagram, place the class playing the whole, and show classes outside the whole that are associated with the whole. This first diagram shows the external context of the whole class.

This diagram hides the complexity of the internal parts. In other words, just look at the external aspects of the complex whole.
Internal structure of the aggregate: On this second class diagram, place the class playing the role of the whole at the top and show all of its parts underneath. Then consider the associations between the parts and show those on this diagram.

This diagram only shows the classes involved in the aggregation and does not show any classes outside the aggregation. The modeler can focus on the internal workings of the aggregate without the complexity of what is outside the aggregate. In other words, just look at the internal aspects of a complex whole.

Considering aggregation behavior

A whole and its parts form a special bond. The whole object usually invokes the behavior of its parts to accomplish its own behavior. When you start a car, you use an interface (the ignition-key slot) that is part of the car. After turning the ignition key, various parts of the car (wires, battery, ignition coil, engine, and so on) are invoked in the right sequence to start the engine. From a programming perspective, the whole (car) invokes behavior on the aggregated parts to achieve its requested behavior (to start running).

For programmers, aggregations have a special meaning beyond just allowing instances of one class to invoke the behavior of instances of another class. Because the whole controls its parts, use the following when designing operations for the whole and its parts:

Constructor: Think about the constructor operation (the operation invoked to create instances of the class) of the whole. Ask yourself what parts must be available as soon as the whole object is created at runtime. Be sure to create them in the constructor’s method (the actual code for the constructor operation).
Life cycle: Consider the life cycle of the whole. You need to think about the state changes the whole goes through during its life—and for aggregates, this can be quite complex. During the life of an aggregate, its parts are created and deleted at specific times, and the aggregate invokes the behavior of each part at specific times in specific order. You may want to consider building a state diagram for the class that plays the role of the whole. (You can find more information on state diagrams in Chapter 16.)
Cascading operations: For each major stage in the life cycle, consider what behavior the whole is performing. Further consider which parts get involved to assist the whole. For example, when the car is asked to accelerate, the accelerator, throttle, engine, transmission, axes, and wheels get involved. When the car is asked to stop, the brakes, wheels, axes, transmission, and engine are involved. Think of how requests of the whole object are passed down to requests on the parts.
Handling errors: Consider how you handle errors. If a part is having a problem, the natural place to handle the problem is within the part. However, if the part can’t deal with the error, you can throw the error over to the whole and let it deal with it. Often the whole object “knows” enough about the internal workings of itself and all its parts that it can rectify the problem.
Destructor: Don’t forget the destructor operation (the operation that contains behavior to delete instances of a class) of the whole. You should consider what happens when the whole is asked to destruct. Take the time to think about the life cycle of the whole’s parts. Reflect on whether any parts are left over—are they all destroyed along with the whole? Program your destructor operation on the whole accordingly.

Tip The following are some quick guidelines for specifying aggregation:

Don’t worry about naming this special association. All aggregations are also associations. Aggregations are a special kind of association because they associate a whole with its parts. So, all aggregations are implicitly named “part-of.” You can name them if you want to, but you don’t have to.
Consider naming the part end of the association only if it plays some special role in relation to the whole.
On the class representing the whole, add operations that control the parts.
Create a state diagram for the whole, indicating its dynamic life cycle. (See Chapter 16 for more on state diagrams.)
Carefully consider the constructor and destructor operations on the whole.