UML25 — UML2.5's Connector role constraint excludes inherited roles

UML 2.5, section 11.8 provides an OCL encoding of the following role constraint on a Connector:

[3] The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be roles of the Classifier
that owned the Connector, or they must be ports of such roles.

inv: structuredClassifier <> null
and
end->forAll( e |
structuredClassifier.role->includes(e.role)
or
e.role.oclIsKindOf(Port) and structuredClassifier.role->includes(e.partWithPort))

Inherited roles are excluded because StructuredClassifier::/role is a derived union that is subsetted only once by StructuredClassifier::ownedAttribute

In 17.7.3, Collaboration Semantics, the UML spec uses the term 'role' in a way that clearly suggests a broader intent than a subset of owned attributes:

Neither all Features nor all contents of the participating instances nor all links between these instances are always required in a particular Collaboration. Therefore, a Collaboration is often defined in terms of roles typed by Interfaces.

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.

In 17.7.3 CollaborationUses semantics, the UML spec uses the term 'role' in a way that could not legitimately restricted to a subset of owned attributes but instead include inherited attributes:

The roleBindings are implemented using Dependencies owned by the CollaborationUse. Each role in the Collaboration is bound by a distinct Dependency and is its supplier. The client of the Dependency is a ConnectableElement that relates in some way to the context Classifier: it may be a direct role of the context Classifier, or an element reachable by some set of references from the context Classifier. These roleBindings indicate which ConnectableElement from the context Classifier plays which role in the Collaboration.

One of the CollaborationUses owned by a Classifier may be singled out as representing the Behavior of the Classifier as a whole. This is called the Classifier’s representation. The Collaboration that is related to the Classifier by its representation shows how the instances corresponding to the StructuralFeatures of this Classifier (e.g., its attributes and parts) interact to generate the overall Behavior of the Classifier. The representing Collaboration may be used to provide a description of the Behavior of the Classifier at a different level of abstraction than is offered by the internal structure of the Classifier. The Properties of the Classifier are mapped to roles in the Collaboration by the role bindings of the CollaborationUse.

I suggest replacing the term 'role' in chapter 11 and 17 with 'all roles' or 'owned an inherited roles' where applicable.

I also suggest introducing a query:

StructuredClassifier::allRoles() : ConnectableElement[*]
body: allFeatures()>select(oclAsKind(ConnectableElement))>collect(oclAsType(ConnectableElement))->asSet()

Then the roles constraint on Connector in 11.8 should read:

[3] The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be owned or inherited roles of the Classifier
that owned the Connector, or they must be ports of such roles.

inv: structuredClassifier <> null
and
end->forAll( e |
structuredClassifier.allRoles()->includes(e.role)
or
e.role.oclIsKindOf(Port) and structuredClassifier.allRoles()->includes(e.partWithPort))

Accept the suggestions in the issue. For the Collaborations clause, avoid using “role” at all and use “collaborationRole”
instead, which is defined for that purpose.
This also resolves 7416.