Issue 8032: Link maintenance in StructuredClassifier (uml2-rtf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Minor Summary: Link maintenance in StructuredClassifier The semantics of StructuredClassifier should indicate that links are created/destroyed according to connectors when objects are added/removed from the connected properties. Extend Create/Destroy/ClearLinkAction and Add/Remove/ClearStructuralFeature with boolean properties that "turn on" this semantics. Resolution: see ptc/2006-04-01 p 94 Revised Text: Actions taken: December 30, 2004: received issue August 23, 2006: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 30 Dec 2004 15:28:28 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: No Specification: UML 2 Super Section: Composite FormalNumber: ptc/04-10-02 Version: 2.0 RevisionDate: 04-10-02 Page: - Nature: Revision Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Description Link maintenance in StructuredClassifier The semantics of StructuredClassifier should indicate that links are created/destroyed according to connectors when objects are added/removed from the connected properties. Extend Create/Destroy/ClearLinkAction and Add/Remove/ClearStructuralFeature with boolean properties that "turn on" this semantics. Reply-To: From: "Conrad Bock" To: "uml2rtf" Subject: Issues 8031, 8032 Date: Tue, 21 Jun 2005 08:39:45 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Composers, See attached proposals for issues 8031 and 8032, and on wiki at: http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue1000000024 http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue1000000025 Summary: Issue 8031 is modified from the original to not destroy links that shouldn't be. Issue 8032 is written in a more minimalist way than I would have liked, but hopefully more acceptable to Thomas. Conrad issueresolution-8031-8032.doc Subject: RE: Issues 8031, 8032 Date: Tue, 21 Jun 2005 14:08:23 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues 8031, 8032 Thread-Index: AcV2Y8Ht7iCbXMNFTsGUj4ot3lQgAwAQUe0g From: "Mellor, Stephen" To: , "uml2rtf" X-OriginalArrivalTime: 21 Jun 2005 21:09:32.0098 (UTC) FILETIME=[84E18220:01C576A5] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5LLJXhh012001 I continue to disagree strongly with both these resolutions. They both--as I read them--take away from the primitive nature of the actions. There are multiple situations in which the automatic deletion of objects/links is not the right thing to do. I can explain why if you insist, but I have done so already several times over. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: 2005-06-21, Tuesday 05:40 > To: uml2rtf > Subject: Issues 8031, 8032 > > Composers, > > See attached proposals for issues 8031 and 8032, and on wiki at: > > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000024 > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000025 > > Summary: > > Issue 8031 is modified from the original to not destroy links that > shouldn't be. > > Issue 8032 is written in a more minimalist way than I would have > liked, but hopefully more acceptable to Thomas. > > Conrad > From: "Thomas Weigert" To: "'Mellor, Stephen'" , , "'uml2rtf'" Subject: RE: Issues 8031, 8032 Date: Wed, 22 Jun 2005 00:15:43 +0200 X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5LMPYhh012497 Stephen, Please remember that the UML is not constructed from action primitives. They are just there to define the detail of certain behaviors where needed. However, there is an object creation semantics that is completely independent of the actions. What these issues (which were submitted by Conrad) point out is that there are some improvements one could do to the formulation of some of those behaviors. We don't need to fix them, as far as I am concerned. But you will not make the fact go away that the actions are not fundamental to the UML, by resisting to fixing these issues. Cheers, Th. > -----Original Message----- > From: Mellor, Stephen [mailto:Stephen_Mellor@mentor.com] > Sent: Tuesday, June 21, 2005 11:08 PM > To: conrad.bock@nist.gov; uml2rtf > Subject: RE: Issues 8031, 8032 > > > I continue to disagree strongly with both these resolutions. They > both--as I read them--take away from the primitive nature of the > actions. There are multiple situations in which the automatic deletion > of objects/links is not the right thing to do. I can explain > why if you > insist, but I have done so already several times over. > > > -----Original Message----- > > From: Conrad Bock [mailto:conrad.bock@nist.gov] > > Sent: 2005-06-21, Tuesday 05:40 > > To: uml2rtf > > Subject: Issues 8031, 8032 > > > > Composers, > > > > See attached proposals for issues 8031 and 8032, and on wiki at: > > > > > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > > 1000000024 > > > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > > 1000000025 > > > > Summary: > > > > Issue 8031 is modified from the original to not destroy links that > > shouldn't be. > > > > Issue 8032 is written in a more minimalist way than I would have > > liked, but hopefully more acceptable to Thomas. > > > > Conrad > > > To: "Mellor, Stephen" Cc: conrad.bock@nist.gov, "uml2rtf" Subject: RE: Issues 8031, 8032 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 24 Jun 2005 02:49:34 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 06/24/2005 02:49:40, Serialize complete at 06/24/2005 02:49:40 Steve, Please note that these are really just the semantics of classifier properties that we are talking about: when an instance of a class is destroyed its structural features are removed along with it. So, the resolutions are merely repeating these semantics for the special case of links owned by a structured class. However, your comment and the proposed resolution helped me notice that we do have a problem in the original formulation when it says: "All instances corresponding to parts of a structured classifier are destroyed recursively,..." This is really the statement that you are objecting to I believe and I have a problem with it as well. This statement must be removed. While the you definitely destroy the slot in which part instances are contained, it should not necessarily mean that the instances themselves are destroyed. For example, in one of our products, object instances are merely "imported" (at run-time) into slots. This means that the objects are owned by some other container, but are temporarily "guests" inside the structured classifier instance. When the latter is destroyed, these parts are not. So, the only part instances that should be destroyed are those that are actually owned by the container. This is easily fixed by saying: "All instances corresponding to parts of a structured classifier that are owned by the instance of the structured classifier are destroyed recursively,..." I would still include Conrad's clarification on links, which I believe is valid. 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 e-mail: bselic@ca.ibm.com "Mellor, Stephen" 06/21/2005 05:08 PM To , "uml2rtf" cc Subject RE: Issues 8031, 8032 I continue to disagree strongly with both these resolutions. They both--as I read them--take away from the primitive nature of the actions. There are multiple situations in which the automatic deletion of objects/links is not the right thing to do. I can explain why if you insist, but I have done so already several times over. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: 2005-06-21, Tuesday 05:40 > To: uml2rtf > Subject: Issues 8031, 8032 > > Composers, > > See attached proposals for issues 8031 and 8032, and on wiki at: > > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000024 > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000025 > > Summary: > > Issue 8031 is modified from the original to not destroy links that > shouldn't be. > > Issue 8032 is written in a more minimalist way than I would have > liked, but hopefully more acceptable to Thomas. > > Conrad > Reply-To: From: "Thomas Weigert" To: "'Branislav Selic'" , "'Mellor, Stephen'" Cc: , "'uml2rtf'" Date: Fri, 24 Jun 2005 09:43:46 +0200 X-Mailer: Microsoft Outlook, Build 10.0.6626 Subject: RE: Issues 8031, 8032 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on mail-mx1.hia.no X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=HTML_40_50,HTML_MESSAGE, HTML_TAG_EXIST_TBODY autolearn=no version=3.0.2 Bran, your clarification is what was intended and it improves readability... Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, June 24, 2005 8:50 AM To: Mellor, Stephen Cc: conrad.bock@nist.gov; uml2rtf Subject: RE: Issues 8031, 8032 Steve, Please note that these are really just the semantics of classifier properties that we are talking about: when an instance of a class is destroyed its structural features are removed along with it. So, the resolutions are merely repeating these semantics for the special case of links owned by a structured class. However, your comment and the proposed resolution helped me notice that we do have a problem in the original formulation when it says: "All instances corresponding to parts of a structured classifier are destroyed recursively,..." This is really the statement that you are objecting to I believe and I have a problem with it as well. This statement must be removed. While the you definitely destroy the slot in which part instances are contained, it should not necessarily mean that the instances themselves are destroyed. For example, in one of our products, object instances are merely "imported" (at run-time) into slots. This means that the objects are owned by some other container, but are temporarily "guests" inside the structured classifier instance. When the latter is destroyed, these parts are not. So, the only part instances that should be destroyed are those that are actually owned by the container. This is easily fixed by saying: "All instances corresponding to parts of a structured classifier that are owned by the instance of the structured classifier are destroyed recursively,..." I would still include Conrad's clarification on links, which I believe is valid. 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 e-mail: bselic@ca.ibm.com "Mellor, Stephen" 06/21/2005 05:08 PM To , "uml2rtf" cc Subject RE: Issues 8031, 8032 I continue to disagree strongly with both these resolutions. They both--as I read them--take away from the primitive nature of the actions. There are multiple situations in which the automatic deletion of objects/links is not the right thing to do. I can explain why if you insist, but I have done so already several times over. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: 2005-06-21, Tuesday 05:40 > To: uml2rtf > Subject: Issues 8031, 8032 > > Composers, > > See attached proposals for issues 8031 and 8032, and on wiki at: > > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000024 > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000025 > > Summary: > > Issue 8031 is modified from the original to not destroy links that > shouldn't be. > > Issue 8032 is written in a more minimalist way than I would have > liked, but hopefully more acceptable to Thomas. > > Conrad > Subject: RE: Issues 8031, 8032 Date: Fri, 24 Jun 2005 13:15:30 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues 8031, 8032 Thread-Index: AcV4iOe48mAWnuF1RQCv/AxU/P8H8QAR0/lg From: "Mellor, Stephen" To: "Branislav Selic" Cc: , "uml2rtf" X-OriginalArrivalTime: 24 Jun 2005 20:15:31.0467 (UTC) FILETIME=[788DB5B0:01C578F9] OK. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 2005-06-23, Thursday 23:50 To: Mellor, Stephen Cc: conrad.bock@nist.gov; uml2rtf Subject: RE: Issues 8031, 8032 Steve, Please note that these are really just the semantics of classifier properties that we are talking about: when an instance of a class is destroyed its structural features are removed along with it. So, the resolutions are merely repeating these semantics for the special case of links owned by a structured class. However, your comment and the proposed resolution helped me notice that we do have a problem in the original formulation when it says: "All instances corresponding to parts of a structured classifier are destroyed recursively,..." This is really the statement that you are objecting to I believe and I have a problem with it as well. This statement must be removed. While the you definitely destroy the slot in which part instances are contained, it should not necessarily mean that the instances themselves are destroyed. For example, in one of our products, object instances are merely "imported" (at run-time) into slots. This means that the objects are owned by some other container, but are temporarily "guests" inside the structured classifier instance. When the latter is destroyed, these parts are not. So, the only part instances that should be destroyed are those that are actually owned by the container. This is easily fixed by saying: "All instances corresponding to parts of a structured classifier that are owned by the instance of the structured classifier are destroyed recursively,..." I would still include Conrad's clarification on links, which I believe is valid. 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 e-mail: bselic@ca.ibm.com "Mellor, Stephen" 06/21/2005 05:08 PM To , "uml2rtf" cc Subject RE: Issues 8031, 8032 I continue to disagree strongly with both these resolutions. They both--as I read them--take away from the primitive nature of the actions. There are multiple situations in which the automatic deletion of objects/links is not the right thing to do. I can explain why if you insist, but I have done so already several times over. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: 2005-06-21, Tuesday 05:40 > To: uml2rtf > Subject: Issues 8031, 8032 > > Composers, > > See attached proposals for issues 8031 and 8032, and on wiki at: > > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000024 > > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue > 1000000025 > > Summary: > > Issue 8031 is modified from the original to not destroy links that > shouldn't be. > > Issue 8032 is written in a more minimalist way than I would have > liked, but hopefully more acceptable to Thomas. > > Conrad > Reply-To: From: "Conrad Bock" To: "'uml2rtf'" Cc: Subject: RE: Issues 8031, 8032 Date: Tue, 28 Jun 2005 11:35:53 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Sorry if this is duplicated. Steve, et al, > I continue to disagree strongly with both these resolutions. They > both--as I read them--take away from the primitive nature of the > actions. There are multiple situations in which the automatic deletion > of objects/links is not the right thing to do. I can explain why if you > insist, but I have done so already several times over. Perhaps the wording needs to be changed then, but my intention was to preserve the primitiveness of actions, while defining the semantics composite structure around link deletion. The DestroyObjectActioin semantics is unaffected by these proposals (which intentionally do not refer to the actions directly). > [Bran] However, your comment and the proposed resolution helped me > notice that we do have a problem in the original formulation when it > says: > > "All instances corresponding to parts of a structured classifier > are destroyed recursively,..." > > This is really the statement that you are objecting to I believe and > I have a problem with it as well. This statement must be > removed. While the you definitely destroy the slot in which part > instances are contained, it should not necessarily mean that the > instances themselves are destroyed. For example, in one of our > products, object instances are merely "imported" (at run-time) into > slots. This means that the objects are owned by some other container, > but are temporarily "guests" inside the structured classifier > instance. When the latter is destroyed, these parts are not. I took "part" above in the technical sense it is defined in the composites chapter, namely, strong composition properties (see Figure 95, > So, the only part instances that should be destroyed are those > that are actually owned by the container. This is easily fixed > by saying: > > "All instances corresponding to parts of a structured classifier > that are owned by the instance of the structured classifier are > destroyed recursively,..." We could clarify as above, but it is a different issue (8031 and 8032 are about link deletion). Would probably be a good idea, because the composites chapter often uses parts informally. Shall I file an issue? > [Thomas] What these issues (which were submitted by Conrad) point out > is that there are some improvements one could do to the formulation > of some of those behaviors. Thomas, shall we take the posted document as the Composite WG proposals for 8031, 8032 in ballot 6? Conrad Reply-To: From: "Conrad Bock" To: "uml2rtf" Subject: RE: Issues 8031, 8032, updated proposal Date: Tue, 5 Jul 2005 15:17:04 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Thomas, et al, Here's a small update to the 8031 proposal, from Guus' comment that links may exist due to other connectors in other composites not being destroyed, and these should not be destroyed. See beginning of quote in revised text, and end of discussion. The 8032 proposal is included for reference. The document is attached to both issues on the twiki. Do these look OK for ballot 6? Conrad Issue 8032: Link maintenance in Structured Classifier? Issue summary Link maintenance in Structured Classifier? The semantics of Structured Classifier? should indicate that links are created/destroyed according to connectors when objects are added/removed from the connected properties. Extend Create/Destroy/ClearLinkAction and Add/Remove/ClearStructuralFeature with boolean properties that 'turn on' this semantics. Discussion This issue has two components: Link maintenance semantics for StructuredClassifier Support link maintenance in actions The item (1) has already been resolved as part of another issue. -- ThomasWeigert - 26 May 2005 Issue (2) requires that the link actions act according to the semantics of StructuredClassifier, when the CommonBehavior package is included. -- ThomasWeigert - 26 May 2005 Issue (1) isn't resolved, see my comments at Issue 8031, http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue1000000024 Issue (2) Do you mean the semantics of StructuredClassifier already specifies link maintenance? The spec only says All instances corresponding to parts of a structured classifier are destroyed recursively, when an instance of that structured classifier is deleted. The instance is removed from the extent of its classifier, and is itself destroyed. which only applies to strongly composed instances. The issue refers to all properties, including regular and weakly composed ones. The current semantics would not delete the links between the latter kind. Actually, it wouldn't even delete the links between values of strongly composed properties without assuming links are destroyed between destroyed instances, a semantics that is not stated anywhere that I can find, except for the option in Destroy Object Action?. -- ConradBock - 03 Jun 2005 Conrad, regarding your (1) above you are arguing circularly. You say: part (1) is not resolved because issue 8031 is not resolved. And you say issue 8301 is not resolved because part (2) is not resolved. But that is incorrect, because issue 8301 is identical to part (1). -- ThomasWeigert - 04 Jun 2005 Regarding your point (2), no. What I stated above is a requirement on a solution. The requirement is that the link actions behave in accordance with any stated semantics for StructuredClassifier. So if the LinkActions do not, they need to be updated... -- ThomasWeigert - 04 Jun 2005 Revised Test Resolution Reply-To: From: "Conrad Bock" To: "uml2rtf" Subject: RE: Issues 8031, 8032, updated proposal 2 Date: Sun, 17 Jul 2005 10:55:14 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) (Discussion from wiki, posted here for the RTF) Hi Thomas, 8031: > Aren't "links between roles that are non-composite properties" > included in "all links"? Why does this need to be highlighted? Didn't follow this exactly, except I guess removing "All" doesn't change the meaning. See attached update. > Why should links created by link actions not be destroyed when the > classifier is destroyed? There may be many links between the instances playing the roles that were not created due to the connectors of the composite that is being destroyed. They might have been created by other composites not being destroyed, for example, or link actions of unrelated behaviors. These might be destroyed because the instance playing the role is destroyed, but that is a separate matter from the current issue. And of course some of the instances playing roles will not be destroyed, because the role is a noncomposite property. See discussion in atached proposal. 8032: > What does it mean to "no longer play a role". This does not appear > to be a defined term in the specification. It means "no longer a value of the role". Perhaps role should be replaced with "property"? See updated revised text, attached. Conrad issueresolution-8031-80323.doc Issue 8032: Link maintenance in StructuredClassifier Click here for this issue's archive. Source: NIST (Mr. Conrad Bock, mailto:%20conrad.bock@nist.gov) Nature: Revision Severity: Minor Summary: Link maintenance in StructuredClassifier The semantics of StructuredClassifier should indicate that links are created/destroyed according to connectors when objects are added/removed from the connected properties. Extend Create/Destroy/ClearLinkAction and Add/Remove/ClearStructuralFeature with boolean properties that "turn on" this semantics. Resolution: Revised Text: In Section 9.3.13., subsection .Semantics.: In first paragraph, before .or a later time., add .or in the case of links, when an object is added as the value of a role,.. after the paragraph preceding the .Semantic variation point. heading, add: .Links created based on connectors between roles of the structured classifier are destroyed when one or both of their end objects are removed from the roles on the ends of the connectors, including roles that are non-composite properties.. Actions taken: December 30, 2004: received issue