Issue 18699: UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole (uml25-ftf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: 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} 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: UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole Thread-Topic: UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole Thread-Index: AQHOS5lBWmVp8n9qfEG1aWwTku1llQ== Date: Wed, 8 May 2013 03:08:04 +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 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} - Nicolas. From: Steve Cook To: "Rouquette, Nicolas F (313K)" CC: "uml25-ftf@omg.org" Subject: RE: UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole Thread-Topic: UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole Thread-Index: AQHOS5lBWmVp8n9qfEG1aWwTku1llZkEwSKg Date: Tue, 14 May 2013 14:16:55 +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:(189002)(199002)(47736001)(74662001)(47976001)(16236675002)(15202345002)(46102001)(74502001)(512954002)(33656001)(81542001)(80022001)(55846006)(71186001)(81342001)(65816001)(77982001)(69226001)(74706001)(20776003)(53806001)(31966008)(59766001)(44976003)(76482001)(50986001)(54316002)(49866001)(56816002)(79102001)(54356001)(56776001)(51856001)(4396001)(63696002)(6806003)(47446002)(74366001)(74876001)(16406001);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB017;H:TK5EX14MLTC102.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 084674B2CF X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Nicolas I am trying to understand this issue 18699 that you posted. Your logic seems to be faulty and I don.t know quite what to make of it. I.d like to understand it properly before addressing issue 18697. Please see my comments interspersed below. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 08 May 2013 04:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole 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. Your statement is self-contradicting. StructuredClassifier::/role is subsetted by ownedAttribute and by collaborationRole, and is derived as the union of both of them. That is, the inherited roles of a parent Collaboration are not roles of its specializing Collaborations. I don.t believe you can conclude that. The roles of a specializing Collaboration might (via collaborationRole) be specified to include inherited ownedAttributes. 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. Not really. The modeller chooses some ConnectableElements to be collaborationRoles, and /role is derived from that. 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} That would have the result of not deriving role from collaborationRole at all, which I don.t think is right. - Nicolas. From: "Rouquette, Nicolas F (313K)" To: Steve Cook CC: "uml25-ftf@omg.org" Subject: RE: UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole Thread-Topic: UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole Thread-Index: AQHOS5lBWmVp8n9qfEG1aWwTku1llZkEwSKggAAWCVA= Date: Tue, 14 May 2013 15:40:29 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] 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== Steve, Yes, I agree with you that: The modeller chooses some ConnectableElements to be collaborationRoles, and /role is derived from that. So the modeler can include inherited or owned attributes as roles of a collaboration. For a Collaboration, this makes sense. We can close this issue. I was looking at how .roles. work . it.s amazing that the same term has different meanings in at least 3 different contexts: Collaborations, non-Collaboration StructuredClassifiers and Connectors. - Nicolas. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, May 14, 2013 7:17 AM To: Rouquette, Nicolas F (313K) Cc: uml25-ftf@omg.org Subject: RE: UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole Nicolas I am trying to understand this issue 18699 that you posted. Your logic seems to be faulty and I don.t know quite what to make of it. I.d like to understand it properly before addressing issue 18697. Please see my comments interspersed below. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 08 May 2013 04:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole 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. Your statement is self-contradicting. StructuredClassifier::/role is subsetted by ownedAttribute and by collaborationRole, and is derived as the union of both of them. That is, the inherited roles of a parent Collaboration are not roles of its specializing Collaborations. I don.t believe you can conclude that. The roles of a specializing Collaboration might (via collaborationRole) be specified to include inherited ownedAttributes. 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. Not really. The modeller chooses some ConnectableElements to be collaborationRoles, and /role is derived from that. 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} That would have the result of not deriving role from collaborationRole at all, which I don.t think is right. - Nicolas.