Issue 8462: UML 2 Super / General / invalid subset rule too strict (uml2-rtf) Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: The redefinition rule [4] of Property on page 127 of ptc/04-10-02 restricts a navigable property from being redefined by a non-navigable property. Unfortunately, this rule is violated in many parts of the model. Recommendation: As a practical resolution for this problem, it is suggested that this constraint be removed since it does not seem to provide any benefits and yet prevents the realization of the agreed design intent Resolution: see above Revised Text: Superstructure: In section 7.3.44, change constraint [4] to: A redefined property must be inherited from a more general classifier containing the redefining property. if (redefinedProperty->notEmpty()) then (redefinitionContext->notEmpty() and redefinedProperty->forAll(rp| ((redefinitionContext->collect(fc| fc.allParents()))->asSet())-> collect(c| c.allFeatures())->asSet()-> includes(rp)) InfrastructureLibrary: Make the same change for constraint [5] in section 11.3.5. Editor’s note: The change was made to constraint [4] not constraint [5] (the latter is a mistake in the resolution) Actions taken: March 4, 2005: received issue August 23, 2006: closed issue Discussion: The UML2 specification current couples navigability and property ownership as described in section 6.5.2. In addition, there is currently no notation for specifying property ownership separate from navigability. Although section 6.5.2 may specify useful defaults in the absence of anything specific from the modeler, this is not currently part of the specification. As a result, any redefinition that changes navigability will also change the property from an ownedAttribute of a class to/from an ownedEnd of an Association. This will result in an invalid redefinition because the redefined property will not be in a classifier that is a generalization of the classifier containing the redefining property (the redefinition context). In addition, even if there was notation that allowed the ownership to be specified separately from the navigability, there are instances in the UML2 model where navigability of the same property is redefined to be both navigable and non-navigable in different subclasses which results in the property needing to be owned by an association and class at the same time. Constraint [4] in section 7.3.44 says a navigable property can only be redefined or subsetted by a navigable property. There are many cases in the UML2 model where this constraint is violated for subsetted properties contributing to derived unions. For example, Element::/element is a navigable derived union which is redefined or subsetted by many non-navigable and navigable non-derived properties. This results in many invalid subsets because of changes in navigability in different subclasses for the same inherited property. However, the subsetting context for an association end is the classifier at the other end. Constraint [3] says subsetting may only occur when the context of the subsetting property conforms to the context of the subsetting property. That is, the subsetting context must be the same or a subclass of the subsetted context. This is the case of all of the subsets in the UML2 model as long as navigability is ignored. In theory, the subsetting context from a non-navigable subsetted end would not be a property of a classifier inherited by the context of the subsetting end. However, a property does know its association, so like OCL, subsetting can be defined to be independent of navigability. It is not clear this is the intent of the UML2 specification, but it is clearly used many times in the metamodel. Redefinitions must be stricter because the redefined property must not simply be accessible, but must be a inherited. Fortunately there are no instances where redefinitions change property ownership. When an association generalizes another association and redefines its ends, the redefined end must be accessible through the generalization. This means redefining and redefined properties must be ownedEnds of the association or ownedAttributes of the participating classes. Redefining ownership (either directly or indirectly by changing navigability with default ownership) resulting in the redefined property no longer being a member of the general classifier would result in an invalid redefinition. As a result, constraint [4] in section 7.3.44 both over-constrains subsets and is incomplete. It should state the redefined property must be inherited from a generalization of the classifier containing the redefining property. This doesn’t apply to subsetting because it’s not a redefinition. So constraint [4] should not reference subsetted properties. End of Annotations:===== ssue X7: UML 2 Super / General / invalid subset rule too strict Source: Jim Amsden, IBM Software Summary: The redefinition rule [4] of Property on page 127 of ptc/04-10-02 restricts a navigable property from being redefined by a non-navigable property. Unfortunately, this rule is violated in many parts of the model. Recommendation: As a practical resolution for this problem, it is suggested that this constraint be removed since it does not seem to provide any benefits and yet prevents the realization of the agreed design intent. Subject: RE: Draft ballot 10 Date: Tue, 13 Sep 2005 05:55:08 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft ballot 10 Thread-Index: AcW2aOQD6ZfxzYXAQZu1pJpSW7CuewAbw2MQ From: "Pete Rivett" To: "Branislav Selic" , Issue 8134: If DeployedArtifact does indeed inherit from 2 versions of Element (and this is not achieved via PackageMerge) then why can the diagram not show 2 classes Element (from kernel) and Element (from Dependencies)? Issue 8136: the same applies Issue 8139: the policy is NOT to have constraints on diagrams - we have had other issue resolutions explicitly removing them! Issues 8137, 8140: we should really use the style {subsets X} rather than the English text "This association specializes...". Maybe we want a separate resolution to clean all these up? There are some resolutions in this ballot that use (subsets X) and others that use {subsets X} Issue 8433 needs tidying - I think this was already spotted Issue 8457: should move the first section under Revised text to Discussion (since these are just general directions not detailed changes to the document), so that Revised text now starts with 'Superstructure'. Issue 8459: I disagree with the paragraph at the end of the resolution which states the following which I think is not at all justified by the spec which has keywords and stereotypes as quite separate things (albeit regrettably using the same notation).Since none of these standard stereotypes provides any new properties or associations, they can be regarded as keywords and therefore do not require profile capabilities in order to be applied to L1 models." Moreover this explanation appears under 'revised text' and it's not clear what Text it's revising - it seems to be making a (invalid IMHO) justification for 'no change' which should be under Discussion. If we really do want to allow stereotypes to be considered keywords at L1 then there should be some very clear text added to the spec. Issue 8460: I think we're hasty removing the constraint. The reason I can see for not allowing non-derived properties to redefine derived ones is that a non-derived property requires a slot. An implementation could work on the basis that a redefinition always reuses and never needs to obtain a new slot. Issue 8462: I object to removing the constraint on subsetting. To me it's as simple as this - in order for a property C.P1 to subset a property P2 then P2 must be accessible/in the namespace of C: either directly owned by C or inherited. (C here is the Classifier that owns P1). Issue 8468: The last changes to constraints [2] and [3] would have been better to provide the OCL than adding 'OCL not available' On a more general note I think we should have a policy for when/whether to reference the finalized spec ptc/04-10-02 or the newly available formal spec. Pete -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, September 10, 2005 8:34 PM To: uml2-rtf@omg.org Subject: Draft ballot 10 Just 31 proposed resolutions. Apologies for the messay state of the draft ballot, but I did not have time to clean it up fully. Thought it better to have it out on time. Also, I have not yet had a chance to actually review the proposed resolutions. Please review them carefully and comment on anything that you feel is controversial or needs fixing -- the official ballot will be sent out on Friday. Regards, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 To: Branislav Selic Cc: uml2-rtf@omg.org Subject: Re: Draft ballot 11 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Kenneth Hussey Date: Mon, 31 Oct 2005 09:41:15 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 6.5.4|March 27, 2005) at 10/31/2005 09:41:21, Serialize complete at 10/31/2005 09:41:21 Bran, Some comments: 8433: I see that the multiplicity of StateMachine::extendedStateMachine is changing from 0..1 to *. Was this intentional? Should a similar change be made for Region::extendedRegion, State::redefinedState, and Transition::redefinedTransition? 8462: The OCL for this constraints must also be updated. 8894: The proposed resolution addresses the issue in the context of TimeEvent, but not the general issue that there is no way to specify the value for a TimeExpression. Note that the same applies for Duration. Both could be addressed by making TimeExpression and Duration specializations of ValuePin in response to issues 9097 and 9096. 8932: Are we sure that "specialized from" here always refers to subsetting (as opposed to redefinition)? 8976: The multiplicity of Realization::abstraction should be [0..1], not [0..*]. The multiplicity of Realization::realizingClassifier should be [1..1], not [0..*]. The multiplicity of Lifeline::coveredBy should be [0..*], not [0..1]. Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 Branislav Selic/Ottawa/IBM@IBMCA 10/30/2005 09:29 PM To uml2-rtf@omg.org cc Subject Draft ballot 11 Attached, please find the draft of ballot 11 -- the last formally scheduled ballot of our RTF. The only resolutions we will consider after this are ones that are deemed absolutely critical (e.g., they may be needed to generate the XMI). There are 94 issues on the ballot, so we need to take 2 weeks for the soak before we release the official ballot. A couple of things I would like to draw your attention to on the resolutions in this ballot: (1) There are many resolution proposals from Kenn Hussey who is working on producing the XMI for UML 2.0. Each of these issues were uncovered relatively recently during the process of generating the XMI. Since the XMI is a mandatory part of the spec, we have no choice but to solve these issues before we release UML 2.1. This formal process uncovered numerous inconsistencies and incompletenesses in the spec that had to be resolved. In most cases, the resolution is simple and obvious. (2) I added a few mostly editorial minor issues that were spotted during various implementations. I took the liberty of proposing resolutions for them without asking the owners of the respective areas. So, this is a chance for the owners to review and comment on bthe resolution proposals: 8938, 8955, 8968 : State machines (Eran) 8976: Components (Thomas) Interactions (Oystein) 8989, 8990: Components (Thomas) 8993 : Common Behaviors (Thomas), StateMachines (Eran) 9077 : Interactions (Oystein) (3) Resolution 8956 proposas a solution to the long-standing problem of an explicit notation for association ends owned by an association. (4) Resolution 8963 defines the semantics of navigability in more detail. Regards, Bran [attachment "Draft.Ballot11.051030.pdf" deleted by Kenneth Hussey/Ottawa/IBM] To: Kenneth Hussey , Eran Gery , jamsden@us.ibm.com, conrad.bock@nist.gov Cc: uml2-rtf@omg.org Subject: Re: Draft ballot 11 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 31 Oct 2005 17:09:07 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 10/31/2005 17:09:08, Serialize complete at 10/31/2005 17:09:08 Kenn, Thanks for the review. Comments below: > 8433: I see that the multiplicity of StateMachine:: > extendedStateMachine is changing from 0..1 to *. Was this > intentional? Should a similar change be made for Region:: > extendedRegion, State::redefinedState, and Transition::redefinedTransition? I think that this is an error in the resolution text -- I changed it back to 0..1. The reason for this whole thing is to implement state machine inheritance using redefinition. Making this multiplicity 0..* would imply some kind of multiple inheritance for state machines, which is, to say the least, semantically undefined. ERAN, CAN YOU PLEASE COMMENT ON THIS SINCE I CHANGED YOUR PROPOSED RESOLUTION > 8462: The OCL for this constraints must also be updated. Good point. I had trouble writing this constraint. Here is what I put in, but I suspect that there is a simpler way of doing this: if (featuringClassifier->notEmpty() and redefinedProperty->notEmpty()) then redefinedProperty->forAll(rp| ((featuringClassifier->collect(fc| fc.allParents()))->asSet())-> collect(c| c.allFeatures())->asSet()-> includes(rp)) JIM, CAN YOU PLEASE REVIEW AND COMMENT SINCE I CHANGED YOUR PROPOSED RESOLUTION > 8894: The proposed resolution addresses the issue in the context of > TimeEvent, but not the general issue that there is no way to specify > the value for a TimeExpression. Note that the same applies for > Duration. Both could be addressed by making TimeExpression and > Duration specializations of ValuePin in response to issues 9097 and 9096. KENN, can you please provide a resolution that is consistent with the resolution to 9096 and 9097 > 8932: Are we sure that "specialized from" here always refers to > subsetting (as opposed to redefinition)? CONRAD, DID YOU EVER USE "SPECIALIZED FROM" INSTEAD OF "REDEFINES"? > 8976: The multiplicity of Realization::abstraction should be [0..1], > not [0..*]. The multiplicity of Realization::realizingClassifier > should be [1..1], not [0..*]. The multiplicity of Lifeline:: > coveredBy should be [0..*], not [0..1]. Thanks for spotting this, I did a blind copy-paste and screwed up. Bran Reply-To: From: "Conrad Bock" To: "Branislav Selic" , Subject: RE: Draft ballot 11 Date: Tue, 1 Nov 2005 14:44:38 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, Comments on draft ballot 11. Conrad - Issue 7977: ReduceAction The figure is missing after the third line in the revised text. See attachment. In the Revised Text, under Semantics: Second paragraph: Replace the second and third sentences with "This will not affect the result of the action if the behavior is symmetric and associative, see below." In the sentence beginning "If the reducing behavior is not symmetric", after "symmetric" add "and associative". Replace third paragraph with: If isOrdered = false, the reducer behavior should be symmetric and associative so it will produce the same reduced value regardless of which two elements are paired at each invocation. For example, addition is symmetric because because a + b = b + a. It is also associative because ((a + b) + c) = (a + (b + c)). Symmetry and associativity are not required, but the result will be indeterminate if isOrdered = false. and add it to the end of the second paragraph. I made the above text changes in the attachment. - Issue 8250: Section: 12.3.33 In the discussion, third line, at end of line, there are two footnote numbers, which should be double-quotes. - Issue 8462: UML 2 Super / General / invalid subset rule too strict The discussion begins "The UML2 specification current couples navigability and property ownership as described in section 6.5.2.", which is incorrect. - Issue 8500: mustIsolate: In Discussion, last sentence, before "points", insert "filer". - Issue 8679: token In Discussion, second line, at end, replace "possible" with "possibly". In Revised text, third line, after "replace", replace the two occurences of "edges" with "node". - Issue 8932: UML Superstructure / Actions / incorrect form for subsetting There's one "specialized from" that is not a subset: SendObjectAction.request. It should be "(redefines InvocationAction:argument)". BTW, ActivityPartition has an entry for activity that shouldn't be there. - Issue 8963: UML2 Navigability Impact on Tools Navigability applies to n-ary (n > 2) associations (see Description and Semantics of Association) , whereas the proposed text limits it to binary. It also says that navigation proceeds from the instance at the navigable end, and this could easily be misinterpreted as navigating in the wrong direction, because the navigable end appears in the diagram at the target end. Suggested rewording: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from nonnavigable ends. - Issue 9096: UML 2.1 Implementation Issue In the new figure, shouldn't ValuePin have the name of the source package in it? It isn't defining an increment of ValuePin. - Issue 9097: UML 2.1 Implementation Issue In the new figure, shouldn't ValuePin have the name of the source package in it? It isn't defining an increment of ValuePin. In the new figure, there is a minus sign before the association end "value". Is that intended? - Issue 9103: UML 2.1 Implementation Issue - Issue 9107: UML 2.1 Implementation Issue Probably should clarify that the first figure in each of these is from the resolution of Issue 8867 (OpaqueAction).