Issue 18697: UML2.5's Connector role constraint excludes inherited roles (uml25-ftf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: 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)) Resolution: Revised Text: Actions taken: May 7, 2013: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "uml25-ftf@omg.org" Subject: UML2.5's Connector role constraint excludes inherited roles because the UML specification fails to distinguish between owned and inherited roles Thread-Topic: UML2.5's Connector role constraint excludes inherited roles because the UML specification fails to distinguish between owned and inherited roles Thread-Index: AQHOS2a+pS4EdaelWEKfJm5+ORm9Yg== Date: Tue, 7 May 2013 21:06:29 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR16Wag= X-Brightmail-Tracker: AAAAAA== 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)) - Nicolas. From: "Bock, Conrad" To: Steve Cook , "Manfred R. Koethe" , "" Date: Sat, 22 Jun 2013 08:02:10 -0400 Subject: RE: [UML 2.5 FTF] Ballot 6 - Revision 3, comments, 18697 Thread-Topic: [UML 2.5 FTF] Ballot 6 - Revision 3, comments, 18697 Thread-Index: Ac5vQEetLPWUDbSfSY6n9FcFpdmI6g== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org Steve, > Re 18697. I > disagree that the replacement text is unclear. Clause 11.2.3 is not to > do with collaborations. The resolution discussion text for 18697 says "For the Collaborations clause, avoid using "role" at all and use "collaborationRole" instead, which is defined for that purpose". As part of this, it changes the documentation for Collaboration::collaborationRole from "References ConnectableElements (possibly owned by other Classifiers) which represent roles that instances may play in this Collaboration." which distinguishes role and instance playing the role, to "Represents the particants in the Collaboration"." where "participants" can mean the instances or the roles, and so is more ambiguous than the existing text. Conrad From: Steve Cook To: "Bock, Conrad" , "Manfred R. Koethe" , "" Subject: RE: [UML 2.5 FTF] Ballot 6 - Revision 3, comments, 18697 Thread-Topic: [UML 2.5 FTF] Ballot 6 - Revision 3, comments, 18697 Thread-Index: Ac5vQEetLPWUDbSfSY6n9FcFpdmI6gAAI4Yg Date: Sat, 22 Jun 2013 12:08:41 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.105] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(13464003)(189002)(199002)(20776003)(56776001)(55846006)(6806003)(47776003)(59766001)(74706001)(54316002)(69226001)(74876001)(74366001)(77096001)(81342001)(81542001)(76482001)(63696002)(54356001)(76786001)(56816003)(50466002)(77982001)(76796001)(79102001)(49866001)(47446002)(46406003)(53806001)(46102001)(51856001)(4396001)(74662001)(65816001)(80022001)(44976004)(74502001)(16406001)(33656001)(31966008)(50986001)(47736001)(23726002)(47976001)(491001);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB029;H:TK5EX14HUBC107.redmond.corp.microsoft.com;CLIP:131.107.125.37;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 088552DE73 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r5MC90SX002448 Conrad This wording is chosen because it summarizes the second paragraph of 11.7.3 Semantics which uses the words "participant" and "participating instances" and describes all about instances, collaborationRoles, etc. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 22 June 2013 13:02 To: Steve Cook; Manfred R. Koethe; Subject: RE: [UML 2.5 FTF] Ballot 6 - Revision 3, comments, 18697 Steve, > Re 18697. I > disagree that the replacement text is unclear. Clause 11.2.3 is not to > do with collaborations. The resolution discussion text for 18697 says "For the Collaborations clause, avoid using "role" at all and use "collaborationRole" instead, which is defined for that purpose". As part of this, it changes the documentation for Collaboration::collaborationRole from "References ConnectableElements (possibly owned by other Classifiers) which represent roles that instances may play in this Collaboration." which distinguishes role and instance playing the role, to "Represents the particants in the Collaboration"." where "participants" can mean the instances or the roles, and so is more ambiguous than the existing text. Conrad