Skip to content

Association types

Jump to bottom
Tobias Spears edited this page Mar 24, 2020 · 8 revisions

Home Modelling

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.

Association types

  • 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 committee may be the whole, and persons are parts. But persons may still exist independent of the committee, they may be part of several committees, and they may even be part of other classes. If the committee 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 [1].

When should one use the different association types? There is no simple answer to this, but take into consideration:

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.

Clone this wiki locally