Issue 6960: Inconsistency betw. Figure 328 and associations listed in s. Associations (uml2-superstructure-ftf) Source: (, ) Nature: Clarification Severity: Minor Summary: Inconsistency between Figure 328 and the associations listed in section "Associations". If there is an association between MessageEnd and Interaction according to • interaction: Interaction[1] The enclosing Interaction owning the MessageEnd then it is missing in Figure 328. Resolution: see above Revised Text: Actions taken: January 31, 2003: received issue March 8, 2005: closed issue Discussion: Remove the entire item for “interaction” , including its description, in the Associations list of MessageEnd on page 431. End of Annotations:===== m: webmaster@omg.org Date: 31 Jan 2004 17:01:02 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Karl Guggisberg Company: na mailFrom: karl.guggisberg@guggis.ch Notification: No Specification: Unified Modeling Language: Superstructure Section: 14.3.15 FormalNumber: ptc/03-08-02 Version: 2.0 RevisionDate: na Page: 431 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Description Inconsistency between Figure 328 and the associations listed in section "Associations". If there is an association between MessageEnd and Interaction according to . interaction: Interaction[1] The enclosing Interaction owning the MessageEnd then it is missing in Figure 328. Date: Sat, 14 Feb 2004 11:14:02 +0100 From: Oystein Haugen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Juergen Boldt CC: issues@omg.org, uml2-superstructure-ftf@omg.org Subject: Re:,ia, issue 6960 -- UML 2.0 Superstructure FTF issue X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12) Karl Guggisberg Your observation is correct. As far as I can see the correct resolution is to remove the association 'interaction' from MessageEnd because MessageEnds come in two variants, either Gates or EventOccurrences. The owner of Gates are given in Figure 330 and the owner EventOccurences is given by the fact that an EventOccurrence is an InteractiooFragment which are either owned by an Interactioo (Figure 326) or an InteractionOperand (Figure 329). /Oystein Haugen Juergen Boldt wrote: From: webmaster@omg.org Date: 31 Jan 2004 17:01:02 -0500 To: Subject: Issue/Bug Report ---------- * Name: Karl Guggisberg * Company: na * mailFrom: karl.guggisberg@guggis.ch * Notification: No * Specification: Unified Modeling Language: Superstructure * Section: 14.3.15 * FormalNumber: ptc/03-08-02 * Version: 2.0 * RevisionDate: na * Page: 431 * Nature: Clarification * Severity: Minor * HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Description Inconsistency between Figure 328 and the associations listed in section "Associations". If there is an association between MessageEnd and Interaction according to . interaction: Interaction[1] The enclosing Interaction owning the MessageEnd then it is missing in Figure 328. ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ -- Dr. Oystein Haugen Associate Professor Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo Norway Tel: +47 22 85 27 37 (office) Tel: +47 913 90 914 (mobile) http://folk.uio.no/oysteinh 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, Nick Issue 6960: Inconsistency betw. Figure 328 and associations listed in s. Associations (uml2-superstructure-ftf) Nature: Clarification Severity: Minor Summary: Inconsistency between Figure 328 and the associations listed in section "Associations". If there is an association between MessageEnd and Interaction according to . interaction: Interaction[1] The enclosing Interaction owning the MessageEnd then it is missing in Figure 328. Discussion: There is no direct association between MessageEnd and Interaction, therefore there is no inconsistency. MessageEnd is an abstract class that provides an association from messages to EventOccurences (or using the improved terminology .OccurenceSpecifications) or Gates. There is not much value in the Interaction to own the MessageEnds, or for a MessageEnd to know the enclosing Interaction. However, it is important for the enclosing interaction to own its Messages, and for a Message to be associated with particular points on a Lifeline. This could have been done directly, if it where not for a Gate: Message can not only go between two Lifelines, but also between Lifelines and Gate. Both Figure 328 and its description at page 428-429 are consistent. To: "Nikolai Mansurov" Cc: uml2-superstructure-ftf@omg.org Subject: RE: Some concerns with your proposed resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 16 Mar 2004 18:27:07 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/16/2004 18:27:10, Serialize complete at 03/16/2004 18:27:10 Nick, I accepted issue 6960 ( you can see the version in the draft ballot), but not the other ones since I still have some issues with your solutions. I think that we can probably work them all out for Ballot 11. My reasons for not including them on the ballot are given below: > 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 "i > t 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. OK, I restored the original text of the issue (note that the software that the OMG uses for its database for some reason removes things between pairs of "<>" braces. This is a problem when people use angular brackets to identify stereotypes -- they are automatically removed. In the draft report, I had to restore each of these by hand (there is a way to get to the original text of the message, fortunately)). Concerning the issue resolution: I have already mentioned that (1) it is not at all a good idea to make interactions dependent on state machines [I realize that this is not your proposal but one that you inherited] and (2) that these things do not necessarily have to represent regions or states of any specific state machine but could be some otherwise undefined state machine. Listing these things as they are currently in the spec with a formal BNF is highly misleading and should be removed altogether; i.e., Remove the entire section of text starting with the sentence: "The State symbol represents the equivalent of a constraint that checks the state of the classifierBehavior of the enclosing Classifier....." down to the sentence that ends with "...if the specified state information is true." > 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. I agree that the text is inadequate and misleading. What I objected to in your resolution is that, in trying to be more specific, you are again linking interactions to state machines. How about: "A StateInvariant is a runtime constraint on the participants in the interaction. It may used to specify a variety of different kinds of constraints, such as values of attributes or variables, internal or external states, and so on." I would leave it at that, without mentioning explicitly things such as behaviors of represented classifiers and the like. That is getting too specific. The more I work with interactions the more I get the impression that it is heavily biased in favour of Interactions as a formal language. While this is useful and necessary, it should not come at the expense of informal use of interactions modeling. For example, the current model REQUIRES each lifeline to have a corresponding ConnectableElement. If all I want to do is do a bit of informal modeling, this is too restrictive since it forces me to declare some structural element in some collaboration or classifier. This is not good if I want to do the proverbial "sketching". We need to loosen this up. > 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. I still don't understand. It still seems to me that you are talking about 3 possibilities. The stuff outside the break, the stuff inside it, and something else that I don't understand. I think that the actual condition for the "alt" equivalent is whether the "break" occurred or not. In that case, the third option does not exist. I must be missing you meaning completely. > 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" ? But, it's getting a bit too specific at this point. Do we really need this constraint? I'd rather leave it out. Regards, Subject: RE: Some concerns with your proposed resolutions Date: Tue, 16 Mar 2004 20:19:12 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some concerns with your proposed resolutions Thread-Index: AcQLrjWUf4tg2chbTO64ybG1ytGGWgAB6jkA From: "Nikolai Mansurov" To: "Branislav Selic" Cc: Hi Bran, I appreciate a good review, as always. I'll post the updated resolutions for Ballot 11 soon. I agree with all you suggestions, except 6989. But please see detailed comments below. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, March 16, 2004 6:27 PM To: Nikolai Mansurov Cc: uml2-superstructure-ftf@omg.org Subject: RE: Some concerns with your proposed resolutions Nick, I accepted issue 6960 ( you can see the version in the draft ballot), but not the other ones since I still have some issues with your solutions. I think that we can probably work them all out for Ballot 11. [Nikolai Mansurov] OK My reasons for not including them on the ballot are given below: > 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 "i > t 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. OK, I restored the original text of the issue (note that the software that the OMG uses for its database for some reason removes things between pairs of "<>" braces. This is a problem when people use angular brackets to identify stereotypes -- they are automatically removed. In the draft report, I had to restore each of these by hand (there is a way to get to the original text of the message, fortunately)). Concerning the issue resolution: I have already mentioned that (1) it is not at all a good idea to make interactions dependent on state machines [I realize that this is not your proposal but one that you inherited] and (2) that these things do not necessarily have to represent regions or states of any specific state machine but could be some otherwise undefined state machine. Listing these things as they are currently in the spec with a formal BNF is highly misleading and should be removed altogether; i.e., Remove the entire section of text starting with the sentence: "The State symbol represents the equivalent of a constraint that checks the state of the classifierBehavior of the enclosing Classifier....." down to the sentence that ends with "...if the specified state information is true." [Nikolai Mansurov] I agree with that. The original grammar in the spec is too detailed. From the meta-model viewpoint, this is just a Constraint, as as e.g. guard. I think, it's better to remove all of it. > 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. I agree that the text is inadequate and misleading. What I objected to in your resolution is that, in trying to be more specific, you are again linking interactions to state machines. How about: "A StateInvariant is a runtime constraint on the participants in the interaction. It may used to specify a variety of different kinds of constraints, such as values of attributes or variables, internal or external states, and so on." I would leave it at that, without mentioning explicitly things such as behaviors of represented classifiers and the like. That is getting too specific. [Nikolai Mansurov] I agree that going into the detailed of the ownership of the attributes may be going too far. The only remaining issue is to explain the two presentation options. The more I work with interactions the more I get the impression that it is heavily biased in favour of Interactions as a formal language. While this is useful and necessary, it should not come at the expense of informal use of interactions modeling. For example, the current model REQUIRES each lifeline to have a corresponding ConnectableElement. If all I want to do is do a bit of informal modeling, this is too restrictive since it forces me to declare some structural element in some collaboration or classifier. This is not good if I want to do the proverbial "sketching". We need to loosen this up. [Nikolai Mansurov] I don't disagree with you. In fact, I've start suggesting similar things elsewhere (see 6988 on ExecutionOccurences). Having said that, I'd suggest that we have all provisions in place for the formal use of Interactions, because there are more and more projects who choose this kind of notation for systems engineering in a lightweight, yet formal, executable way. I think that you'd agree, that a formal Interactions are less "heavy" that formal state machines (for the same system, i.e. not a single protocol-like state machine, but plain communicating state machines one for each interacting party). Overall, I agree with your wording for 6983. > 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. I still don't understand. It still seems to me that you are talking about 3 possibilities. The stuff outside the break, the stuff inside it, and something else that I don't understand. I think that the actual condition for the "alt" equivalent is whether the "break" occurred or not. In that case, the third option does not exist. I must be missing you meaning completely. [Nikolai Mansurov] How about simply describe the semantics of break explicitly: break operand without the guard MAY BE executed. Break operand with the guard is executed when the guard is true and not executed, when the guard is false. If you are OK with that - simply skip the next paragraph. [Nikolai Mansurov] Note, that the semantics of the break is defined via a transformation to an already defined alt ConbinedFragment. So, the question is: what exactly is the equivalient alt CombinedFragment ? This alt fragment indeed has only two branches, not three. The stuff outside the break (or the "rest" of the enclosing Interaction), the stuff inside the break, AND NOTHING ELSE. The issue is that branches in the alt CombinedFragment may have guards. It is obvious, that the "stuff inside the break" may or may not have its own guard in the original CombinedFragment, therefore it goes into the new alt CombinedFragment unchanged (guard or no guard). However, the stuff outside of the break DOES NOT HAVE ANY GUARD in the original Interaction (well, since guards are only assocaited with InteractionOperands, and that "stuff outside break" was just "the rest of Interaction", but not an InteractionOperand. But after the transformation it BECOMES an InteractionOperand of the new alt CombinedFragment. The question is then: should it have an "ELSE" guard, or should it have no guard at all (and hence - the implicit TRUE guard, as per the semantics of the alt CombinedFragment) ? I argue, that if the "stuff inside the break" had a guard before the transformation, the ELSE guard for the "stuff outside the original break" should be added in order to get the intuitive behavior. If the "stuff outside break" is transformed into the second branch of alt without a guard, it assumed an implicit TRUE guard. Then, there can be a situation when both guards are true, and the choice between branches is non-deterministic. And if the "stuff inside the break" did not have a guard before the transformation, it should be transformed without ELSE. Then both branches will assume implicit true guards, and the choice will be non-deterministic, as expected. This is consistent with the interpretation "deterministic, if break has a guard, non-deterministic without a guard". Actually, if we always add the ELSE guard, the interpretation will change into: "deterministic if break has guard, always breaks for break without a guard". If we never add the ELSE guard, the interpretation will change into: "non-deterministic if break has guard; non-deterministic, if break does not have a guard". > 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" ? But, it's getting a bit too specific at this point. Do we really need this constraint? I'd rather leave it out. [Nikolai Mansurov] I see the value in saying that events before create model erroneous behavior, but not adding this constraint will make such interactions valid unless we explicitily use "negative" - but I don't know what is the meaning of such interaction. MSCs have such a constraint (and no provisioning for explicitly describing an invalid interaction, like "negative"). Practically, this situation can not materialize, provided the create message always enter through the Lifeline head. However, with a general "create" message, I can write an Interaction: :A :B | a | -------------> | | - - - - - - -> | | (First send-receive message; then create). [Nikolai Mansurov] This may have sense though, in the multi-valued context (when selector for the second instance was omitted). Then this interaction means that "some instance of type B" receives, then a new instance is created". Overall, I believe that adding this constraint (and/or some clarifications) will make Interactions more formal, without sacrificing the "loosness". In a bargaining situation, I will trade 5 of these for a multi-Lifeline guard :-) Cheers, Nick Disposition: Closed, no change