Issue 8433: Section: 15.3.12 (uml2-rtf) Source: (, ) Nature: Clarification Severity: Minor Summary: Delete sub-section Attributes or change line to "None." Association connectionPoint:Pseudostate[*] subsets ownedMember. According to fig. 354, there is an association submachineState:State[*] that needs to be added and defined in the text. Association extendedStateMachine:StateMachine[*] redefines:redefinableElement I think. Figure 355 is overwritten by fig. 356 and this association is hard to read. In fig. 355, classifier StateMachine is not generalized or connected to any other classifier in the figure. Draw appropriate connections or make the StateMachine classifier a separate figure. Correct spelling of "conectionPoint" in OCL notation for constraint [3]. Add OCL notation to Additional Operations [1], [3], and [4] or otherwise note that OCL notation is not available for these operations. Typos - Para immediately above Run-to-completion and concurrency (pg. 671), change "... the invoked object complete..." to "...the invoked object completes..." - Page 619, 7th para. change "is" to "are." - Page 612, 1st para, last sent., does the capitalization of "verifyTransaction" need changing? - Personal preference for easier understanding place commas in "for, e.g., classes" on page 623 in sub-section Rational (second such labeled sub-section). Complete the sentence/paragraph for the last paragraph under StateMachine extension. Resolution: see above Revised Text: - Change sub-section Attributes to "None." Editor’s note: the above change was not entered because it does not conform to the standard format - Add to Association connectionPoint:Pseudostate[*] subsets ownedMember. - Add to section associations “submachineState:State[*] references the submachine (s) in case of a submachine state. Multiple machines are referenced in case of a concurrent state”. Editor’s note: the above change was not entered because the stated association end is non-navigable. (for good reason: just like a class, a state machine should not have to be changed each time it is referenced in some other state machine) - Add to Association extendedStateMachine:StateMachine[0..1] “subsets redefinedElement” Figure 355: the text of the association line extendedStateMachine is clipped. It shall say “extendedStateMachine {subsets redefinedElement}. Multiplicity shall be changed to [0..1] on both ends. Editor’s note: fixed in formal copy edit - Page 617 Paragraph above Run-to-completion and concurrency - change "... the invoked object complete..." to "...the invoked object completes..." - Page 619 7th para: change " while the source state and trigger is preserved." to " while the source state and trigger are preserved.” - Last paragraph under StateMachine - changed text to- State machine extension is an extension of 1.x. In 1.x, state machine generalization is only informally discussed as a non-normative practice. Actions taken: March 1, 2005: received issue August 23, 2006: closed issue Discussion: There are few items already fixed in the post FTF text. Revised text includes only those not yet addressed. End of Annotations:===== m: webmaster@omg.org Date: 01 Mar 2005 16:25:40 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Jane Messenger Company: U. S. Geological Survey mailFrom: jmessenger@usgs.gov Notification: Yes Specification: Superstructure Section: 15.3.12 FormalNumber: ptc/04-10-02 Version: 2.0 Draft Adopted RevisionDate: 10/08/2004 Page: 615-623 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) Description Delete sub-section Attributes or change line to "None." Association connectionPoint:Pseudostate[*] subsets ownedMember. According to fig. 354, there is an association submachineState:State[*] that needs to be added and defined in the text. Association extendedStateMachine:StateMachine[*] redefines:redefinableElement I think. Figure 355 is overwritten by fig. 356 and this association is hard to read. In fig. 355, classifier StateMachine is not generalized or connected to any other classifier in the figure. Draw appropriate connections or make the StateMachine classifier a separate figure. Correct spelling of "conectionPoint" in OCL notation for constraint [3]. Add OCL notation to Additional Operations [1], [3], and [4] or otherwise note that OCL notation is not available for these operations. Typos - Para immediately above Run-to-completion and concurrency (pg. 671), change "... the invoked object complete..." to "...the invoked object completes..." - Page 619, 7th para. change "is" to "are." - Page 612, 1st para, last sent., does the capitalization of "verifyTransaction" need changing? - Personal preference for easier understanding place commas in "for, e.g., classes" on page 623 in sub-section Rational (second such labeled sub-section). Complete the sentence/paragraph for the last paragraph under StateMachine extension. 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 To: uml2-rtf@omg.org Subject: Review of Ballot 6 X-KeepSent: B2E56A1E:CA4ACA57-852575BE:00549D44; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Jim Amsden Date: Wed, 27 May 2009 15:09:53 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 05/27/2009 13:09:56, Serialize complete at 05/27/2009 13:09:56 Sorry about taking so long on reviewing ballot 6. There just isn't enough time for everything. 6433 I think the resolution is confusing dependency wires between interfaces/usages/realizations and connectors between connectable elements. Dependency wires, whether they're shown with dependency or ball and socket notation should be between types that can be used to define connectable elements. This way the structural wiring shown at the class level using dependencies is consistent with the structural wiring using connectors at the part level. It seems very strange to create a dependency between a usage and realization in order to effect ball and socket notation. It makes no sense to individually connect different interfaces of the same component or port as at the part or runtime level, the connections are never between the individual interfaces, they're always between the parts that provide and use the interfaces. The ball and socket notation should simply be a notation shorthand for dependency wires or connectors where the connection between the classes or parts only involves a single provided and required interface. This is consistent with the intent in the current spec and with the semantics of connection. We shouldn't confuse notation options and conveniences with different elements in the metaclass. Figure 8.15 should show the dependency wires connected to the ports, not the ball and socket representing the provided and required interfaces. If the dependency is between the usage and realization of the classes used to type the ports, then this implies a dependency between all usages of those classes, not the particular usages to define individual ports. This seems like unintended coupling. This also appears inconsistent with the resolution for 9464. 7364 There was another issue raised suggesting that the contract for a connector should be a classifier rather than just a behavior. This would for example allow a collaboration to be used to define the contract allowing collaboration role bindings to indicate what parts play what roles in a multi-party contract. The current use of a behavior is not adequate because there is no context in which to connect the ends of the connector to representing lifelines, partitions or call operation action target input pins. So the contract is not very useful. SoaML did not use connector contract because the protocol for interaction between ports should be defined by the ports, not the connector. This ensures different instances of participants follow the correct protocol, regardless of the particular connector that connects them. Service contracts in SoaML also bind the ports to the protocols specified by their roles in the contract. This is still not associated with the connector contract. But perhaps this should be raised as a new issue and not change the resolution of this one. 8160 The connectors should never be to the balls or sockets - but rather to the ports or parts that provide or require the interfaces. The ball and socket is a notation for a derived provided or required interface, not a connectable element. This makes the ball and socket notation even more confusing. Figure 8.12, the delegation connectors are missing arrows and should be to/from the ports, not the balls and sockets. This also has significant implications for current tools which would have to special case connectable elements and ball and socket interface notation. 8705 This resolution does not sufficiently define what ComponentRealization means. ComponentRealizaiton should not be confused with usage dependencies or parts in a components internal structure. In figure 8.10, CustomerImpl, CustomerColl and CustomerDef are components used by Customer for its implementation, they don't realize the implementation. One would expect parts typed by these classes to be in the internal structure of Customer, perhaps with a delegation connector to the part typed by CustomerImpl The idea of ComponentRealization should be similar to InterfaceRealization. A realizing component must at least have all the ports and provide and use all the interfaces of the <> components it realizes, and must provide implementing methods that are behaviorally consistent with the behaviors of the realized specification components. This is clarified in SoaML to distinguish specification participants that can be used to define the architecture of a participant from realizing participant that can be instantiated in some execution environment. 8900 Figure 8.17 and 8.18 are not valid UML diagrams. The right part of the figure is missing a context in which these parts are connected. This results in continued confusion between class and instance level modeling and should be avoided. Correcting this could be considered an editorial change by simply adding a containing component. 12985, 13146 I don't agree with the resolution. See comments on 8705. A realizing classifier realizes its specification components, not the other way around. So the realizing classifier must realize and use all of the interfaces of its specification component, but may have more. The specification component would never provide or use interfaces of its realizing classifier because 1) it can't be instantiated and 2) this would be the opposite of what is desired for decoupling component specification from many possibly quite different component realizations. The interfaces a component exposes are those it realizes directly or indirectly through its ports. The interfaces realized by its realizing classifiers must be a superset of this, but don't contribute additional interfaces. Suggest pulling 8705, 12985 and 13146 until we can get clarification on the meaning of ComponentRealization and <> Component. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689