UML CollaborationUse ownership

In section 11.8.5 on p. 265 of the PDF document, there is the description of CollaborationUse which is a specialization of NamedElement. CollaborationUse has a type Property which is the Collaboration on which it is based. Here is the description of CollaborationUse::type():

• type : Collaboration [1..1] (opposite A_type_collaborationUse::collaborationUse)
The Collaboration which is used in this CollaborationUse. The Collaboration defines the cooperation between
its roles which are mapped to ConnectableElements relating to the Classifier owning the CollaborationUse.

As usual, we know from section 7.2.3.1 under the description of Element that

Every Element in a model must be owned by exactly one other Element of that
model, with the exception of the top-level Packages of the model.

Now, please consider the abstract syntax diagram for "Collaborations":

Why is the classifier association end (highlighted in red) specified with multiplicity of [0..1] and not 1?

The presence of the association end representation in Classifier, which seems to duplicate collaborationUse in Classifier, leads me to expect that there might be some other owner than the one involved in the role bindings of the Collaboration; however, it subsets collaborationUse whose opposite end subsets owner, so how are they different?

=================

EDIT:

In the UML specification, there are several instances of this kind of composite aggregation where the aggregate end (the one with the diamond) is owned by the association and not by the Classifier on the opposite end, and where the association end subsets Element::owner. I have a suspicion that the 0..1 multiplicity, in cases where this is obviously not intended(?), is caused by an interaction in the specifications of LiteralInteger and MultiplicityElement in interpreting the XMI specification of the corresponding element when an empty <lowerValue.../> is present. The difficulty arises from the fact that in cases where more than one kind of Element can own another Element, the multiplicity of 0..1 is justified, also in the case of unowned Packages; in other cases, it is not. There seems to be no way of automating the detection of when one case applies and not the other.

In this particular example, here is the excerpt from the file UML.xmi where the classifier association end is described. Note that the XML element <ownedEnd...> includes an empty <lowerValue.../> element. It begins at line 18501:

<packagedElement xmi:type="uml:Association" xmi:id="A_collaborationUse_classifier" name="A_collaborationUse_classifier">
   <memberEnd xmi:idref="Classifier-collaborationUse"/>
   <memberEnd xmi:idref="A_collaborationUse_classifier-classifier"/>
   <ownedEnd xmi:type="uml:Property" xmi:id="A_collaborationUse_classifier-classifier" name="classifier" type="Classifier"
             association="A_collaborationUse_classifier">
      <subsettedProperty xmi:idref="Element-owner"/>
      <!-- ??? -->
      <lowerValue xmi:type="uml:LiteralInteger"
                  xmi:id="A_collaborationUse_classifier-classifier-_lowerValue"/>
      <!-- xxx -->
   </ownedEnd>
</packagedElement>

In contrast, consider the specification of Slot and its associations on page 168, where the multiplicity of the composite aggregation owningInstance to InstanceSpecification is apparently correct; the ValueSpecification can either be owned by a Slot or by the InstanceSpecification, so their multiplicities of 0..1 are justified:

The XMI description of owningInstance in UML.xmi on line 17967 is as follows:

<ownedAttribute xmi:type="uml:Property" xmi:id="Slot-owningInstance" name="owningInstance" type="InstanceSpecification"
                association="A_slot_owningInstance">
   <subsettedProperty xmi:idref="Element-owner"/>
   <ownedComment xmi:type="uml:Comment" xmi:id="Slot-owningInstance-_ownedComment.0"
                 body="The InstanceSpecification that owns this Slot.">
      <annotatedElement xmi:idref="Slot-owningInstance"/>
   </ownedComment>
</ownedAttribute>

There is no <lowerValue.../> given (also no <upperValue.../>), resulting in the multiplicity of 1, as it should.

Looking at the UML specification for MultiplicityElement, the description of the derivation of the attributes /lower and /upper on page 88 under section 7.8.8.7 is as follows:

• lower() : Integer [0..1]
  The derived lower attribute must equal the lowerBound.
  
  body: lowerBound()

This is followed immediately by the definition of lowerBound():

• lowerBound() : Integer [1..1]
  The query lowerBound() returns the lower bound of the multiplicity 
  as an integer, which is the integerValue of lowerValue, 
  if this is given, and 1 otherwise.
                    ^^^^^^^^^^^^^^^^
  body: if (lowerValue=null or lowerValue.integerValue()=null) 
        then 1 
        else lowerValue.integerValue() 
        endif

lowerValue is defined (under "Association Ends" further up on the same page) as follows:

♦ lowerValue : ValueSpecification [0..1]{subsets Element::ownedElement} (opposite
A_lowerValue_owningLower::owningLower)
The specification of the lower bound for this multiplicity.

There is (or are) constraints which requires that lowerValue be of type LiteralInteger, which can be null or else a non-negative Integer in the context of MultiplicityElement.

My conclusion is that whatever tool generated the UML diagrams and machine-generated descriptions has translated the empty <lowerValue.../> tags in every case as 0, although according to the specification of MultiplicityElement it should return 1 ... if missing...

But if it is NOT missing, we have to look at the definition of LiteralInteger::integerValue (p. 125) which looks like this:

8.6.9.4 Attributes
• value : Integer [1..1] = 0
The specified Integer value.

8.6.9.5 Operations
• integerValue() : Integer {redefines ValueSpecification::integerValue()}
The query integerValue() gives the value.

body: value

So the real culprit (IMHO) is the default value 0 of the value attribute combined with its multiplicity of 1..1. Although the implementation of Multiplicity::lowerBound() does check both lowerValue AND lowerValue.integerValue() for null, the default value of LiteralInteger::value as 0 ensures that lowerValue.integerValue() will NEVER be null (which would result in a value of 1) if it is present in the XMI file as an empty XML element.

I think the question should be the other way around. Why are there composite aggregations with the multiplicity 1? Far more of them have the multiplicity 0..1. In some cases this is needed, because there are multiple possible owners, but in many cases I can only find one.

My guess is that only where it is quite obvious, that no alternative compositions could be lurking somewhere, a multiplicity of 1 is used. Since with the exception of packages every element must have an owner, even a multiplicity of 0..1 means that the allowed cardinality is 1. So, the result doesn't change by using 0..1. It makes it possible to later add something to the specification, without having to change the existing metamodel.

I don't think this has anything to do with the xmi-serialization of default values. Using 0..1 is probably what the authors had in mind.