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)
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)
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.
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.
