2. Composition

It's amazing how much confusion exists about the distinction between the part-whole-association concepts aggregation and composition. The main problem is the widespread misunderstanding (even among expert software developers and among the authors of UML) that the concept of composition implies a life-cycle dependency between the whole and its parts such that the parts cannot exist without the whole. But this view ignores the fact that there are also cases of part-whole-associations with non-shareable parts where the parts can be detached from and survive the destruction of the whole.

In the UML specification document, the definition of the term "composition" has always implied non-shareable parts, but it has not been clear what is the defining characteristic of "composition", and what is merely an optional characteristic. Even in the new version (as of 2015), UML 2.5, after an attempt to improve the definition of the term "composition", it remains still ambiguous and doesn't provide any guidance how to model part-whole-associations with non-shareable parts where the parts can be detached from, and survive the destruction of, the whole as opposed to the case where the parts cannot be detached and are destroyed together with the whole. They say:

If a composite object is deleted, all of its part instances that are objects are deleted with it.

But at the same time they also say:

A part object may be removed from a composite object before the composite object is deleted, and thus not be deleted as part of the composite object.

This confusion points to an incompleteness of the UML definition, which does not account for life-cycle dependencies between components and composites. It's therefore important to understand how the UML definition can be enhanced, e.g. by introducing a UML stereotype for <<inseparable>> compositions, or by introducing a constraint keyword inseparable for characterizing the association end at the component side.

As Martin Fowler has explained, the main issue for characterizing composition is that "an object can only be the part of one composition relationship". This is also explained in the blog post UML Composition vs Aggregation vs Association by Geert Bellekens. In addition to this defining characteristic of a composition (to have exclusive, or non-shareable, parts), a composition may also come with a life-cycle dependency between the composite and its components. In fact, there are two kinds of such dependencies:

  1. Whenever a component must always be attached to a composite, or, in other words, when it has a mandatory composite, as expressed by the "exactly one" multiplicity at the composite side of the composition line, then it must either be re-used in (or re-attached to) another composite, or destroyed, when its current composite is destroyed. This is exemplified by the composition between Person and Heart, shown in the diagram below. A heart is either destroyed or transplanted to another person, when its owner has died.

  2. Whenever a component must not be detached from its composite, or, in other words, when it is inseparable, then, and only then, the component has to be destroyed, when its composite is destroyed. An example of such a composition with inseparable parts is the composition between Person and Brain.

In summary, life-cycle dependencies only apply to specific cases of composition, but not in general. They are, therefore, not a defining characteristic. The UML spec states: "A part may be removed from a composite instance before the composite instance is deleted, and thus not be deleted as part of the composite instance."

In the example of a Car-Engine composition, as shown in the following diagram, it's clearly the case that the engine can be detached from the car before the car is destroyed, in which case the engine is not destroyed and can be re-used. This is implied by the zero or one multiplicity at the composite side of the composition line.

The multiplicity of a composition's association end at the composite side is either 1 or 0..1, depending on the fact if components have a mandatory composite or not. Of course, the fact that a component is inseparable implies that it has a mandatory composite, and consequently the composite's multiplicity must be 1.