UML 2.5 FTF Avatar
  1. OMG Issue

UML25 — UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole

  • Key: UML25-515
  • Legacy Issue Number: 18699
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In UML 2.5 section 11.7.3 Collaboration Semantics says:

    Collaborations may be specialized from other Collaborations. If a role is extended in the specialization, its type in the specialized Collaboration must conform to its type in the general Collaboration. The specialization of the types of the roles does not imply corresponding specialization of the Classifiers that realize those roles. It is sufficient that they conform to the constraints defined by those roles.

    A specialized Collaboration can redefine some roles of its parent Collaborations but it should be possible to reuse them without redefining them.
    Unfortunately, this is not possible:

    Collaboration::collaborationRole subsets StructuredClassifier::/role, which is a derived union subsetted only by StructuredClassifier::ownedAttribute.

    That is, the inherited roles of a parent Collaboration are not roles of its specializing Collaborations.

    Currently, Collaboration::collaborationRole : ConnectableElement[*] subsets StructuredClassifier::role.
    That is, it is up to the discretion of the modeler to decide which subset of a Collaboration's roles are to be the Collaboration's collaborationRoles as well.

    It seems that the subset constraint is too strong; that is, it seems it should be relaxed such that a modeler could pick a subset of a Collaboration's roles and Collaboration's inherited roles as its collaborationRoles.
    That is, I suggest replacing:

    Collaboration::collaborationRole : ConnectableElement[*]

    {subsets StructuredClassifier::role}

    with:

    Collaboration::collaborationRole : ConnectableElement[*]

    { subsets Classifier::inheritedMember}

  • Reported: UML 2.5b1 — Tue, 7 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue is based on a misunderstanding. In fact the modeler chooses some ConnectableElements to be collaborationRoles,
    and /role is derived from that.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT