Issue 6989: UML 2 Super/Interactions/Constraints for create messages (uml2-rtf) Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com) Nature: Uncategorized Issue Severity: Summary: page 429 Constraints for message need to include "no EventOccurences before receiving the create message". In the graphic notation this is handled by defining the create graphic path as flowing into the Lifeline head symbol, but since we do not want to introduce the concept of a Lifeline head in the meta-model, we need an additional constraint. Constraints need to be updated as new sorts of messages are added. Resolution: Revised Text: Actions taken: February 16, 2004: received issue August 23, 2006: closed issue Discussion: The following constraint could be added: “[9] No EventOccurences should occur before receiving the create message on the corresponding Lifeline” However this constraint does not allow modeling a situation where a create message may be sent to an existing entity either due to error or intent (e.g., to model erroneous behavior). The above constraint applies to valid interactions. It is unclear how this constraint applies to multivalued instances. Therefore, it seems safer to not add this constraint. Duplicate of Issue 8327 (even though this came first), see the resolution of 8327 Disposition: See issue 8327 for disposition End of Annotations:===== ubject: UML 2 Super/Interactions/Constraints for create messages Date: Mon, 16 Feb 2004 18:59:49 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2 Super/Interactions/missing OCL constraints Thread-Index: AcOiP5KGfYbXFBuaSOy1/0sMnACRTRSoEaNgAACETxAAAHEHQAABOfWQ From: "Nikolai Mansurov" To: Cc: "Branislav Selic (E-mail)" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i1GNqFrh004102 page 429 Constraints for message need to include "no EventOccurences before receiving the create message". In the graphic notation this is handled by defining the create graphic path as flowing into the Lifeline head symbol, but since we do not want to introduce the concept of a Lifeline head in the meta-model, we need an additional constraint. Constraints need to be updated as new sorts of messages are added. To: "Nikolai Mansurov" Cc: uml2-superstructure-ftf@omg.org Subject: Some concerns with your proposed resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 15 Mar 2004 15:52:44 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/15/2004 15:52:47, Serialize complete at 03/15/2004 15:52:47 Nick, I went through your proposed resolutions (I will do the same for all the others by tomorrow night). I have some concerns with a few of them (sorry!): Issue 6960. I think you misinterpreted the issue text. It is complaining about the fact that, on page 431, the list of association ends for MessageEnd includes the entry "interaction:Interaction[1]" but there is no such thing in the metamodel. The proper fix seems to be to remove this entry from the list. Issue 6981: I don't understand the resolution. After the first part which ocrrectly states how the problem should be fixed, the proposed resolution goes on further and mentions something about the inability to define (Is this part of the fix? If so, it seems unrelated to the reported problem.) Next it seems to repeat the fix, but for a problem that does not seem to exist in the spec. Finally, it says something about reusing the State symbol from the state machines chapter (minor nit: I don't like introducing couplings between chapters unless absolutely necessary). But, this has nothing to do with the issue that was raised. If there is a problem that needs to be fixed with this part of the spec, it should be raised explicitly. [Sorry to be bureaucratic, but it is dangerous to stray in this way because it is unclear what the boundary is. Fixes should only relate to the issues raised and should not throw in additional stuff -- even if it is correct technically.] Issue 6983: In my opinion, the state invariant should not necessarily be restricted to things that you listed in this resolution. That might be OK for a formal version of Interactions, but you must remember that there are informal ones. For instance, the state that I may want to show as an invariant on a lifeline may have nothing to do with the internal state of the object represented by the lifeline. I may want it to represent some external view of the object's state -- I may have no insight as to its internal state when describing the interaction. I suggest removing the restriction in your text. Issue 6984: I understand the problem with the use of the term "execute" but I find replacing it with "contribute" to be much more confusing. At least "execute", although technically incorrect, will give the right intuition, but the term "contribute" is much less likely to invoke teh right association. I suggest either leaving it as is or finding a better term than "contribute". Issue 6987: This proposal has me really confused. Why is there a discussion of "else" in here. I thought the original formulation that described the effect of "break" clear enough; i.e., it is equivalent to an "alt" with two operands -- one consisting of the contents of the break and the other of the contents of everything else in the fragment except the "break". Why introduce an "else" into this, there are only two choices. Either the break executes or all the other stuff. There is no third ("else") part here. I don't understand. Issue 6989: the problem I have with this is that it does not allow me to model a situation where I may either due to error or intent send a create message to an existing entity (e.g., I may want to model erroneous behavior). Therefore, it seems safer to not add this constraint. I am hoping that you can have some updates or responses to the above comments. Otherwise, I will not include these specific issues in ballot 10 until we've had a chance to discuss them further. The other ones seem OK. Regards, Bran "Nikolai Mansurov" 03/11/2004 05:36 PM To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject 20 interaction issue resolutions from Nick for ballot 10 Dear Colleagues, Please find attached resolutions for 20 Interaction issues for ballot 10. Most of the issues are simple typos and edits. The big number of issues and the short timeframe until ballot 10 calls for some executive overview of the issues. Here is goes (decreasing priority order): Real problems: 6987, 6989 Typos in the metamodel: 6425, 6925, 6928, 6941, 6985 Clartiy of the document (Nick's edits): 6981, 6982, 6983, 6984, 6986 Typos in the text: 6087, 6900, 6931, 6932, 6933, 6960, 6977 Duplicates: 6976 The "real" problems include more precision in the semantics of break CombinedFragment (6987) and an additional constraint for create message (6989). "Typos in the metamodel" - little obvious things changed in the meta-model (attribute names, etc.) "Nick's edits" category :-) are some improvements in the clarity of the document, based on 5+ years of experience in interpreting the related ITU specifications as the only tool vendor trying to build a standards-compliant tool. Even after 5 year - it's still fun. Best regards, Nick [attachment "mansurov_Interaction issues resolution 4.doc" deleted by Branislav Selic/Ottawa/IBM] Subject: RE: Some concerns with your proposed resolutions Date: Mon, 15 Mar 2004 17:32:05 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some concerns with your proposed resolutions Thread-Index: AcQKz5QToz8e5E+JTPeyHDwlWKtjlQAAkiTA From: "Nikolai Mansurov" To: "Branislav Selic" Cc: Bran, Please find comments below. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, March 15, 2004 3:53 PM To: Nikolai Mansurov Cc: uml2-superstructure-ftf@omg.org Subject: Some concerns with your proposed resolutions Nick, I went through your proposed resolutions (I will do the same for all the others by tomorrow night). I have some concerns with a few of them (sorry!): Issue 6960. I think you misinterpreted the issue text. It is complaining about the fact that, on page 431, the list of association ends for MessageEnd includes the entry "interaction:Interaction[1]" but there is no such thing in the metamodel. The proper fix seems to be to remove this entry from the list. [Nikolai Mansurov] OK, I agree, it's referring to page 431, not pages 428-429, however the Figure 328 is correct. Thanks for pointing it out. Add a paragraph: In the "Association" for MessageEnd on page 431 remove the following association: interaction:Interaction[1] The enclosing Interaction owning the MessageEnd Issue 6981: I don't understand the resolution. After the first part which ocrrectly states how the problem should be fixed, the proposed resolution goes on further and mentions something about the inability to define (Is this part of the fix? If so, it seems unrelated to the reported problem.) Next it seems to repeat the fix, but for a problem that does not seem to exist in the spec. Finally, it says something about reusing the State symbol from the state machines chapter (minor nit: I don't like introducing couplings between chapters unless absolutely necessary). But, this has nothing to do with the issue that was raised. If there is a problem that needs to be fixed with this part of the spec, it should be raised explicitly. [Sorry to be bureaucratic, but it is dangerous to stray in this way because it is unclear what the boundary is. Fixes should only relate to the issues raised and should not throw in additional stuff -- even if it is correct technically.] [Nikolai Mansurov] It is confusing, because all the text enclosed in "<" and ">" is missing from the issue statement, which unfortunately includes the most important part of the issue. Since I raised the issue myself, I first clarified the text of the issue. So, the text "it is unclear, how to define in Sequence diagrams." is the complete version of the text of the issue, not part of the resolution. I should have made it more explicit. Non-terminal is part of the grammar on page 434. The ambiguity of the "region-name" is therefore the part of the issue statement (as I have mentioned earlier, all the text between "<" and ">" got stripped out between my email to issues@omg.org and how the text appears in the OMG database). The usage of in the Interaction chapter is ambiguous when you look at Interactions as a stand-alone document, because it refers to the State Machines chapter. I believe that making the link explicit will improve the spec. Issue 6983: In my opinion, the state invariant should not necessarily be restricted to things that you listed in this resolution. That might be OK for a formal version of Interactions, but you must remember that there are informal ones. For instance, the state that I may want to show as an invariant on a lifeline may have nothing to do with the internal state of the object represented by the lifeline. I may want it to represent some external view of the object's state -- I may have no insight as to its internal state when describing the interaction. I suggest removing the restriction in your text. [Nikolai Mansurov] The phrase "eventual attributes of the Lifeline" is ambiguous. I recommend to make it more precise: "eventual attributes of the Lifeline"="attributes of the enclosing Classifier" or "State of the BehavioredClassifier of the enclosing Classifier" This only clarifies the "eventual attributes" with respect to the difference between a constraint on state and a constraint on the attributes (for which there is also different graphical notation available). I believe, that it is important enough point to clarify: Lifeline itself does not posess a state or attributes, rather it represents a certain Classifier. I would assume that an informal constraint will refer to the same entities (i.e. object state or object attributes). Granted, such state can be specified formally or informally, but you probably can not refer to anything else. page 433 "A StateInvariant is a constraint on the state of a Lifeline"; page 427 "a Lifeline represents an individual participant in the Interaction" (ConnectableElement). With these clarifications: do you think that the formula "eventual attributes of the Lifeline"="attributes of the enclosing Classifier" or "State of the BehavioredClassifier of the enclosing Classifier" is a restriction to the original text ? In this case we can pull out this resolution to have some discussion. Issue 6984: I understand the problem with the use of the term "execute" but I find replacing it with "contribute" to be much more confusing. At least "execute", although technically incorrect, will give the right intuition, but the term "contribute" is much less likely to invoke teh right association. I suggest either leaving it as is or finding a better term than "contribute". [Nikolai Mansurov] OK, I'll look for a more intuitive way to describe this. Issue 6987: This proposal has me really confused. Why is there a discussion of "else" in here. I thought the original formulation that described the effect of "break" clear enough; i.e., it is equivalent to an "alt" with two operands -- one consisting of the contents of the break and the other of the contents of everything else in the fragment except the "break". Why introduce an "else" into this, there are only two choices. Either the break executes or all the other stuff. There is no third ("else") part here. I don't understand. [Nikolai Mansurov] There is no third part, but the "everything else" part (the rest of the Interaction) should have an "else" guard. Without such guard, the alt becomes non-deterministic, since "An implicit true guard is implied if the operand has no guard" (page 410 on alternatives). The implicit "else" guard, rather than an implicit "true" guards better corresponds to the intuitive definition of the opt. However, formally this makes a difference, which we actually came across in our tool, that does a formal interpretation of MSCs, with the real customers. Issue 6989: the problem I have with this is that it does not allow me to model a situation where I may either due to error or intent send a create message to an existing entity (e.g., I may want to model erroneous behavior). Therefore, it seems safer to not add this constraint. [Nikolai Mansurov] How about refining this constraint further, but adding "in an Interaction, describing a valid trace" ? I am hoping that you can have some updates or responses to the above comments. Otherwise, I will not include these specific issues in ballot 10 until we've had a chance to discuss them further. The other ones seem OK. [Nikolai Mansurov] OK. Best regards, Issue 6989: UML 2 Super/Interactions/Constraints for create messages (uml2-superstructure-ftf) Source: klocwork, inc. (Dr. Nikolai Mansourov, nmansourov@klocwork.com) Nature: Uncategorized Issue Severity: Summary: page 429 Constraints for message need to include "no EventOccurences before receiving the create message". In the graphic notation this is handled by defining the create graphic path as flowing into the Lifeline head symbol, but since we do not want to introduce the concept of a Lifeline head in the meta-model, we need an additional constraint. Constraints need to be updated as new sorts of messages are added. Discussion: Add the following constraint: .[9] No EventOccurences should occur before receiving the create message on the corresponding Lifeline. Disposition: Resolved Nick Issue 6989: UML 2 Super/Interactions/Constraints for create messages (uml2-superstructure-ftf) Source: Klocwork, inc. (Dr. Nikolai Mansourov, nmansourov@klocwork.com) Nature: Uncategorized Issue Severity: Summary: page 429 Constraints for message need to include "no EventOccurences before receiving the create message". In the graphic notation this is handled by defining the create graphic path as flowing into the Lifeline head symbol, but since we do not want to introduce the concept of a Lifeline head in the meta-model, we need an additional constraint. Constraints need to be updated as new sorts of messages are added. Discussion: The following constraint should be added: .[9] No EventOccurences should occur before receiving the create message on the corresponding Lifeline. However this constraint does not allow modeling a situation where a create message may be sent to an existing entity either due to error or intent (e.g., to model erroneous behavior). The above constraint applies to valid interactions. It is unclear how this constraint applies to multivalued instances. Therefore, it seems safer to not add this constraint. Disposition: Defer