t's amazing how much confusion has been created about the distinction between the UML part-whole-association concepts aggregation and composition. The main problem is the widespread misunderstanding (even among many expert software developers) that the concept of composition is defined by a life-cycle dependency between the whole and its parts such that the parts cannot exist without the whole. But this view is ignoring the UML definition of the term "composition" by confusing the defining characteristic with an optional characteristic. However, this confusion also points to a weakness, or 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 by introducing a UML stereotype for «inseparable» compositions where components cannot be detached from their composite, and, thus, have to be destroyed whenever their composite is destroyed.
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:
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
Heart, shown in the diagram below. A heart is either destroyed or transplanted to another
person, when its owner has died.
Whenever a component cannot 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
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
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 whole side is either 1 or 0..1, depending on the fact if parts are separable, that is, if they can be detached and exist on their own.