What is the difference between composition and aggregation?

Both aggregation and composition are
special kinds of associations. Aggregation is
used to represent ownership or a whole/part
relationship, and composition is used to
represent an even stronger form of ownership.
With composition, we get coincident lifetime
of part with the whole. The composite object
has sole responsibility for the disposition of
its parts in terms of creation and destruction.
In implementation terms, the composite is
responsible for memory allocation and
deallocation

Moreover, the multiplicity of the aggregate
end may not exceed one; i.e., it is unshared.
An object may be part of only one composite at
a time. If the composite is destroyed, it
must either destroy all its parts or else give
responsibility for them to some other object.
A composite object can be designed with the
knowledge that no other object will destroy
its parts.

Composition can be used to model by-value
aggregation, which is semantically equivalent
to an attribute. In fact, composition was
originally called aggregation-by-value in
an earlier UML draft, with normal
aggregation being thought of as
aggregation-by-reference. The definitions
have changed slightly, but the general
ideas still apply. The distinction between
aggregation and composition is more of a design
concept and is not usually relevant during
analysis.

Finally, a word of warning on terminology.
While UML uses the terms association,
aggregation, and composition
with specific meanings, some object-oriented
authors use one or more of these terms with
slightly different interpretations. For
example, it is fairly common to see all three
UML relationships grouped under a single term,
say composition, and then to discuss
object-oriented relationships as being either
inheritance (generalization) or composition.