Design pattern: aggregation

Sometimes a class type really represents a collection of individual components. Although this pattern can be modeled by an ordinary association, its meaning becomes much clearer if we use the UML notation for an aggregation.

Example: a small business needs to keep track of its computer systems. They want to record information such as model and serial number for each system and its components.

• A very naïve way to do this would be to put all of the information into a single class type. You should recognize that this class contains a set of repeated attributes with all of the problems of the “phone book” pattern. You could fix it as we show here:

Incorrect model (with improvement)

System components class diagram

• The improved model will accommodate the addition of more types of components (a scanner, perhaps), a system with more than one monitor or printer, or a replacement component on the shelf that don’t belong to any system right now. But UML allows us to show the association in a more semantically correct way.

Better model (with UML aggregation)

System components class diagram

• The system is an aggregation of components. In UML, aggregation is shown by an open diamond on the end of the association line that points to the parent (aggregated) class. There is an implied multiplicity on this end of 0..1, with multiplicity of the other end shown in the diagram as usual. To describe this association, we would say that each system is composed of one or more components and each component is part of zero or one system.

• Since the component can exist by itself in this model (without being part of a system), the system name can’t be part of its PK. We'll use the only candidate key {type, mfgr, model, SN} as PK, since this class is not a parent. The system name, just an FK here, will be filled in if this component is installed as part of a system; it will be null otherwise.

System components relation scheme

In UML, there is a stronger form of aggregation that is called composition. The notation is similar, using a filled-in diamond instead of an open one. In composition, component instances cannot exist on their own without a parent; they are created with (or after) the parent and they are deleted if the parent is deleted. The implied multiplicity on the “diamond” end of the association is therefore 1..1.