16.13. Composition Over Aggregation
Aggregation is a vague kind of association in the UML that loosely suggests whole-part relationships (as do many ordinary associations). It has no meaningful distinct semantics in the UML versus a plain association, but the term is defined in the UML. Why? To quote Rumbaugh (one of the original and key UML creators):
In spite of the few semantics attached to aggregation, everybody thinks it is necessary (for different reasons). Think of it as a modeling placebo. [RJB04]
Guideline :
Therefore, following the advice of UML creators, don't bother to use aggregation in the UML; rather, use composition when appropriate.Composition, also known as composite aggregation , is a strong kind of whole-part aggregation and is useful to show in some models. A composition relationship implies that 1) an instance of the part (such as a Square ) belongs to only one composite instance (such as one Board ) at a time, 2) the part must always belong to a composite (no free-floating Fingers), and 3) the composite is responsible for the creation and deletion of its partseither by itself creating/deleting the parts, or by collaborating with other objects. Related to this constraint is that if the composite is destroyed, its parts must either be destroyed, or attached to another compositeno free-floating Fingers allowed! For example, if a physical paper Monopoly game board is destroyed, we think of the squares as being destroyed as well (a conceptual perspective). Likewise, if a software Board object is destroyed, its software Square objects are destroyed, in a DCD software perspective.The UML notation for composition is a filled diamond on an association line, at the composite end of the line (see Figure 16.13).
Figure 16.13. Composition in the UML.
[View full size image]
The association name in composition is always implicitly some variation of "Has-part," therefore don't bother to explicitly name the association.