Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
This page is inspired by Geert Bellkeens' blog post Composition or Aggregation or Association
Association are used to connect classes or data types in the model. UML has three types of associations in class diagrams (beside generalization): simple association, aggregation and composition. All types of associations may be navigable in one or both directions. This is defined with direction arrows, multiplicity and roles.
- In a simple association, both classes are equal. In the figure above there is a simple association between the classes Person and Car. A person may own none, one or many cars, and a car must have one or many owners. And they are at the same level, none of them is a part of the other.
- In an aggregation (illustrated with an open diamond), we have a hierarchy where the class on the diamond end is the whole, and the class on the other end is a part. For example, a commitee may be the whole, and persons are parts. But persons may still exist independent of the commitee, they may be part of several commitees, and they may even be part of other classes. If the commitee is removed, the persons will still exist.
- In a composition (illustrated with a filled diamond), the class on the diamond end owns the class on the other end. For example, a car owns its wheels. The wheels can only belong to one car at a time. The multiplicity on the diamond end decides whether or not the class on the other end can exist on its own. In the figure, the multiplicity is set to 0..1, which means that the wheels may exist without a car. For a composition, there are in reality only two realistic multiplicities: [0 to 1] and .
When should one use the different association types? There is no simple answer to this, but take into concideration:
An aggregation does not really add anything more to the model then a simple association, but it is helpful for illustrating hierarchy.
A composition add stronger binding into the model, which will have influence on the implementations. Compositions should only be used when you are sure that they will fit in an implementation.
Related article on roles and navigability.