UML Aggregation
Shared aggregation (aggregation) is a binary association between a property and one or more composite objects which group together a set of instances. It is a "weak" form of aggregation when part instance is independent of the composite. Shared aggregation has the following characteristics:
- it is binary association,
- it is asymmetric - only one end of association can be an aggregation,
- it is transitive - aggregation links should form a directed, acyclic graph, so that no composite instance could be indirect part of itself,
- shared part could be included in several composites, and if some or all of the composites are deleted, shared part may still exist.
Notation
Shared aggregation is depicted as association decorated with a hollow diamond at the aggregate end of the association line. The diamond should be noticeably smaller than the diamond notation for N-ary associations.
Example below shows Triangle as an aggregate of exactly three line segments (sides). Multiplicity '*' of the Triangle association end means that each line Segment could be a part of several triangles, or might not belong to any triangle at all. Erasing specific Triangle instance does not mean that all or any segments will be deleted as well. (Note, that we named collection of three line Segments as 'sides', while usual UML convention is to use singular form, i.e. 'side', even for collections.)
Triangle has 'sides' collection of three line Segments.
Each line Segment could be part of none, one, or several triangles.
Shared aggregation could be depicted together with other association adornments such as navigability and association end ownership. In the example below line Segment is navigable from Triangle. Association end 'sides' is owned by Triangle (not by association itself), which means that 'sides' is an attribute of Triangle.
Triangle has 'sides' collection of three unique line Segments.
Line segments are navigable from Triangle.
Association end 'sides' is owned by Triangle, not by association itself.
Mistakes
Aggregation is asymmetric relationship - only one end of association is allowed to be marked as shared or composite aggregation. Both UML 1.x and 2.x don't allow a diamond to be attached to both ends of association line. The reasoning behind the example below was that each Student instance has a list of courses he/she is registered to, and every Course has a list of students registered for that course.
Aggregation mistake - only one end of association
can be marked as aggregation.
It will not help if we draw two separate aggregations as shown below. Aggregation links should form a directed, acyclic graph, so that no composite instance should be direct or indirect part of itself.
Aggregation mistake - no composite instance
should be direct or indirect part of itself.
History
In UML 1.x aggregation kinds were none, aggregate, and composite. UML 2.0 renamed the aggregation kind described on this page from aggregate to shared, so that in UML 2.x aggregation kinds are: none, shared, and composite.
