- Introduction
- 16.1 Applying UML: Common Class Diagram Notation
- 16.2 Definition: Design Class Diagram
- 16.3 Definition: Classifier
- 16.4 Ways to Show UML Attributes: Attribute Text and Association Lines
- 16.5 Note Symbols: Notes, Comments, Constraints, and Method Bodies
- 16.6 Operations and Methods
- 16.7 Keywords
- 16.8 Stereotypes, Profiles, and Tags
- 16.9 UML Properties and Property Strings
- 16.10 Generalization, Abstract Classes, Abstract Operations
- 16.11 Dependency
- 16.12 Interfaces
- 16.13 Composition Over Aggregation
- 16.14 Constraints
- 16.15 Qualified Association
- 16.16 Association Class
- 16.17 Singleton Classes
- 16.18 Template Classes and Interfaces
- 16.19 User-Defined Compartments
- 16.20 Active Class
- 16.21 Whats the Relationship Between Interaction and Class Diagrams?
This chapter is from the book
This chapter is from the book
This chapter is from the book
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 parts—either 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 composite—no 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).
Guideline: The association name in composition is always implicitly some variation of “Has-part,” therefore don’t bother to explicitly name the association.
){kind=small}
Figure 16.13 Composition in the UML.