Issue 11323: UML2 Property collaborationRole should be removed (uml2-rtf) Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: The collaborationRole property of Collaboration does not appear to be needed and could be removed. A Collaboration's ownedAttributes subsets inherited derived union role, and therefore represent the roles in a Collaboration. Since Property is extended to be a ConnectableElement, collaborationRole is redundant with ownedAttributes. In addition, the description does not seem to make sense. A collaborationRole can't reference connectable elements (possibly contained in another classifier) because the roles of a Collaboration must be parts or ownedAttributes of that Collaboration. The roleBindings of a CollaborationUse bind the roles of its Collaboration type to parts of some other classifier. However, there could be another interpretation of collaborationRole. If Collaborations are used to represent patterns, then a Collaboration's ownedAttributes may represent the common part of the pattern while the collaborationRoles represent the variable part. Instantiating the pattern with a CollaborationUse may then mean that the Classifier owning the CollaborationUse would need to directly contain the common parts (copies of them from the collaboration), and require roleBindings to the variable parts. In this case, collaborationRole parts would require bindings (and therefore subclass role) while ownedAttributes don't (and wouldn't subclass role)? In any case, the purpose of property collaborationRole is unclear and should be amplified in the specification to distinguish it from ownedAttributes and how it should be used. Resolution: Revised Text: Actions taken: August 30, 2007: received issue Discussion: End of Annotations:===== ubject: UML2 Property collaborationRole should be removed X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Jim Amsden Date: Thu, 30 Aug 2007 12:05:28 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.0|August 02, 2007) at 08/30/2007 10:05:29, Serialize complete at 08/30/2007 10:05:29 The collaborationRole property of Collaboration does not appear to be needed and could be removed. A Collaboration's ownedAttributes subsets inherited derived union role, and therefore represent the roles in a Collaboration. Since Property is extended to be a ConnectableElement, collaborationRole is redundant with ownedAttributes. In addition, the description does not seem to make sense. A collaborationRole can't reference connectable elements (possibly contained in another classifier) because the roles of a Collaboration must be parts or ownedAttributes of that Collaboration. The roleBindings of a CollaborationUse bind the roles of its Collaboration type to parts of some other classifier. However, there could be another interpretation of collaborationRole. If Collaborations are used to represent patterns, then a Collaboration's ownedAttributes may represent the common part of the pattern while the collaborationRoles represent the variable part. Instantiating the pattern with a CollaborationUse may then mean that the Classifier owning the CollaborationUse would need to directly contain the common parts (copies of them from the collaboration), and require roleBindings to the variable parts. In this case, collaborationRole parts would require bindings (and therefore subclass role) while ownedAttributes don't (and wouldn't subclass role)? To: uml2-rtf@omg.org Subject: Re: Draft Ballot #3 X-KeepSent: 1C6B626E:E38FB3EA-852573ED:007AD662; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: Jim Amsden Date: Tue, 12 Feb 2008 17:31:56 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.0|August 02, 2007) at 02/12/2008 15:31:57, Serialize complete at 02/12/2008 15:31:57 >> Issue 11323: UML2 Property collaborationRole should be removed The resolution says: "there could be roles of a collaboration ... that are not collaboration roles" This is confusing. Needs an example or more elaboration. << Conrad, The problem is collaborationRole is confusing and I can't give and example of its use. Collaboration::role is a derived union inherited from StructuredClassifier. Collaboration::collaborationRole contributes to this union, as does the Collaboration's ownedAttributes. It is not at all clear what the difference is between these two different kinds of roles. I do not understand the use of collaborationRole from its description, and there are no examples in the spec that would clarify its use. It is only mentioned in the attribute definition. It is possible that this attribute was added not realizing that ownedAttributes were already roles of a Collaboration. Unless... roleBindings were only intended to be possible to collaborationRoles, not Collaboration ownedAttributes, and the ownedAttributes represented something else, perhaps the common parts of a pattern or something. The spec should either clarify this, or remove collaborationRole. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 "Bran Selic" 02/12/2008 02:55 PM To conrad.bock@nist.gov cc uml2-rtf@omg.org Subject Re: Draft Ballot #3 Wow! Noted. Bran On Feb 12, 2008 1:52 PM, Conrad Bock wrote: Hi Bran, See comments on ballot 3 below. Manyn of the comments are due to resolutions that do not explain in any detial why the disposition of the issue was chosen. Conrad Summary: I'd like these removed from the ballot ... ... for more discussion: - 10597: Behavioral port ... if they cannot be closed with no change: - 8970: Behavior - 9873: Section: Common Behavior - isReentrant should default to ... if they cannot be addressed without closing with no change: - 8026: Contextualized attribute values Figures 121 - 6866: Part subtype - 8077: Properties on Association for end objects - 9001: Section: Common Behavior - 9005: Section: Common Behavior - 9138: inconsistency wrt UML2 classifier behavior - 10536: A_end_role should not be bidirectional ... if the comments below cannot be addressed: - 9005: Section: Common Behavior - 9138: inconsistency wrt UML2 classifier behavior - 10081: Section: 13.2 - 10999: 9.3.9 Invocation Action - 11323: UML2 Property collaborationRole should be removed Issue 6866: Part subtype This should be defered if it is not addressed. Other issues asking for modeling functionality have been defered, for example, issue 7398. Issue 8026: Contextualized attribute values Figures 121 o The resolution says: practice has shown that there is not a problem with initialization of such classes, but doesn't say whose practice, or the results of the practical experience. The filer explains exactly the problem, but the resolution does not respond to it. Issue 8034: Notation for classifierBehavior The resolution says: Apparently no further need for such notation has been raised. but doesn't say raised to whom. If it is OMG, does it require duplicate issues to be filed to address an issue? Issue 8077: Properties on Association for end objects The resolution says: This issue is difficult to understand, as it mixes a number of concepts. (a) Navigating to an end of an association is a concept related to traversing the model as it is stored in a repository. (b) Retrieving the object at an end of a link with an action is related to dynamic interpretation of the model. but the issue is explicitly refers to "objects" and "instances of an association" (links), which are at M0. It cannot be an issue with (b), as that has nothing to do with representing structured associations. If there is no standard way to define M1 properties that can be used to navigate from an M0 instance of an association to its M0 end objects, then there is no way to use composoite struction on association classes, ie, no representation of structured associations. Issue 8970: Behavior This should be closed with no change, see below. Please add this to the discussion: The application for operations on behaviors-as-classes is described in the Activity chapter, Activity, Semantics, seventh paragraph. Issue 9001: Section: Common Behavior ANyReceiveEvent is certainly usable outside of state machines, and makes sense to be in Common Behavior. The spec should be modified to make that clear. Issue 9005: Section: Common Behavior The discussion should say what other issue has been filed that addresses this. I can't evaluate whether there is another issue that covers this. Would like more time to see what the other issue says. Issue 9138: inconsistency wrt UML2 classifier behavior The discussion says this has been discussed before without saying what was discussed. The earlier discussion should be included. Issue 9873: Section: Common Behavior - isReentrant should default to true This attribute originated in activities to specify how tokens are handled when they are offered to a call behavior action that is already invoked. It was (perhaps inappropriately) called "isReentrant" and applied to Activity, then understandably misinterpreted to be a more general property of behaviors. For queuing applications isRentrant=false would be a better default. For typical programming true would be better. This ossue should be closed withno change, since any default would be inappropriate for a significant number of applications. Issue 10081: Section: 13.2 As the filer says, the it makes sense for the languages attribute to be unique. Doesn't changing uniqueness require a change in the metamodel diagrams? Issue 10536: A_end_role should not be bidirectional I agree with Ken this needs to be fixed, and Ken has given the inheritance examples for this in the past. Ken had some proposals before which should be examined. Issue 10597: Behavioral port I agree with Ed about taking more time to consider this. Issue 10789: Port.provided:Interface I agree with the filer, the sentence in the spec doesn't clearly state "that When a port is typed by an interface, it has one provided interface, namely that typing the port". Issue 10999: 9.3.9 Invocation Action The resolution isn't addressing the filed issue, which is ports that have more than one value at M0. Issue 11067: Section: 9 Composite Structures / Port notation The ball and socket notation should be in the composite structure chapter. The resolution does not explain why it isn't. Issue 11323: UML2 Property collaborationRole should be removed The resolution says: "there could be roles of a collaboration ... that are not collaboration roles" This is confusing. Needs an example or more elaboration. Issue XXX: Title This one is empty. In any case, the purpose of property collaborationRole is unclear and should be amplified in the specification to distinguish it from ownedAttributes and how it should be used.