Composite aggregation, or composition, means that the part is a member of only one composite object, and that there is an existence and disposition dependency of the part on the composite.For example, a hand is in a composition relationship to a finger.
In the Design Model, composition and its existence dependency implication indicates that composite software objects create (or caused the creation of) the part software objects (for example, Sale creates SalesLineItem).
But in the Domain Model, since it does not represent software objects, the notion of the whole creating the part is seldom relevant (a real sale does not createa real sales line item). However, there is still an analogy. For example, in a "human body" domain model, one thinks of the hand as including the fingers, so
if one says, "A hand has come into existence," we understand this to also mean that fingers have come into existence as well.
Composition is signified with a filled diamond. It implies that the composite solely owns the part, and that they are in a tree structure parts hierarchy; it is
the most common form of aggregation shown in models.
For example, a finger is a part of at most one hand, thus the aggregation diamond is filled to indicate composite aggregation (see Figure 4-9).
1. Recall that each end of an association is a role, and that a UML role has various roperties, such as multiplicity, name, navigability and isAggregate.