Multiplicity of 0..1 on composition end

From: Matthias Hofmann (hofmann_at_anvil-soft.com)
Date: 03/26/05 

Date: Sat, 26 Mar 2005 17:59:40 +0100

Hello!

The concept of composite aggregation seems to be a controversial matter. The
latest thread I started in order to discuss this topic resultated in a
heated debate lasting several weeks. This makes me reluctant to post any
question about that issue, but it looks like I do not have a choice...

The focus of my problem is the following statement from 3.48.1 in Version
1.5 of the OMG Unified Modeling Language Specification, which describes the
semantics of a composition:

"The multiplicity of the aggregate end may not exceed one (it is unshared)."

It seems clear that according to this rule, the multiplicity of the
aggregate end of a composition may be either 1 or 0..1. While there seems to
be common agreement over the meaning of the former case (a multiplicty of
exactly one), the latter situation (a multiplicity of zero or one) remains a
mystery.

I consulted several text books on the UML in order to find out how a
multiplicity of zero or one is supposed to be interpreted. Unfortunately,
the outcome of my research is rather unsatisfactory. The vast majority of
text books keeps quiet about the existence of a multiplicty of zero or one
and insists that the only multiplicity allowed one the aggregate end of a
composition is exactly one. Only a single book mentioned the theoretical
possibility of a multiplicty of zero or one, but also labeled it nonsense
which should be avoided.

I am convinced that said multiplicity of zero or one has a well-defined
meaning. There was also a footnote in one book stating that some people
interpret such a multiplicity of zero or one in such a way that the part can
be created outside the whole and added to the whole at a later time.
However, this seems to contradict the rule that "the composite object has
sole responsibility for the disposition of its parts" (also found in
3.48.1).

Another interpretation I got to know during the debate mentioned at the
beginning of this post is that a multiplicity of zero or one means that the
part can be removed from the whole. This leads to my own 'favorite'
interpretion, which is as follows:

If (and only if) the multiplicty on the aggregation end of a composition is
zero or one, then the part can exist without the whole. An example (in
C/C++) would be:

struct X
{
   int i;
};

Or as a diagram:

0..1 1
| X |<#>-----------| int |

(I hope the layout is not messed up to much due to various character sets.
My intent is to show a diagram with a class "X" and a class "int". The
multiplicity is "0..1" one the whole end and "1" one the part end of the
composition.)

The way I would interpret such a diagram with my present knowledge is that
an object of type "int" can exist as part of an object of type "X", but
there are also stand-alone objects of type "int". If the multiplicity on the
whole end where "1" instead of "0..1", then an object of type "int" could
*only* exist as part of an object of type "X".

Answering the question about how to interpret a multiplicity of zero or one
on the aggregation end of a composition would bring me much closer to my
goal of understanding the concept of composition in the UML. I appreciate
your thoughts and comments.

Best regards,

Matthias Hofmann

Relevant Pages

  • Re: Multiplicity of 0..1 on composition end
    ... The composition only places a life cycle constraint on the Part. ... > multiplicity of zero or one is supposed to be interpreted. ... > interpret such a multiplicity of zero or one in such a way that the part can ...
    (comp.object)
  • Re: Multiplicity of 0..1 on composition end
    ... > It seems clear that according to this rule, the multiplicity of the ... > multiplicity of zero or one is supposed to be interpreted. ... > composition is exactly one. ... For example, you have a house, that optionally has a garage. ...
    (comp.object)
  • Re: Aggregation vs composition
    ... Therefore the upper bound of the multiplicity ... state that the multiplicity for composition is always 1, ... The distinction between aggregation and composition was even harder to ... >> This expresses the idea of a person living in a house. ...
    (comp.object)
  • Re: Mapping Class Diagram to coding
    ... Aggregation (Weak Composition). ... Aggregation exists in UML to provide symmetry with composition (i.e., a Whole/Part semantics but without the referential integrity constraint). ... Take the example of CAR and WHEEL-CUP. ...
    (comp.object)
  • Re: When A Have a Collections of Bs -- a Design Question
    ... i missed concepts of composition and aggregation. ... composition has a responsibility of life-cycle controling while ... disign/implementation, if life-cycle was found, so the underlying model ...
    (comp.object)