Issue 6077: Message notation. Incorrect notation in Figure 333 p.414 (uml2-superstructure-ftf) Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no) Nature: Clarification Severity: Significant Summary: Firstly not even the original (which is in Visio) has the appropriate dashed line of creation (I thought the pdf just had not quite got it right which happens often, but now I checked the original). Secondly the reply messages should have filled arrowheads (again judging from the description of the message notation). The FTF should reconsider the concrete syntax for create and reply and update the figures accordingly. Originally reported by David Fado through Jim Odell. Resolution: This is a subset of the issue described in 6463. - duplicate Revised Text: Actions taken: August 28, 2003: received issue December 2, 2004: closed issue Discussion: End of Annotations:===== From: webmaster@omg.org Date: 28 Aug 2003 02:37:20 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Oystein Haugen Company: Ericsson mailFrom: oystein.haugen@ericsson.com Notification: Yes Specification: UML 2.0 Superstructure Section: 14.3.1 FormalNumber: ptc/03-08-02 Version: 2.0 RevisionDate: August 2003 Page: 414 Nature: Clarification Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description Message notation. Incorrect notation in Figure 333 p.414 Firstly not even the original (which is in Visio) has the appropriate dashed line of creation (I thought the pdf just had not quite got it right which happens often, but now I checked the original). Secondly the reply messages should have filled arrowheads (again judging from the description of the message notation). The FTF should reconsider the concrete syntax for create and reply and update the figures accordingly. OMG Issue No: 6077 Title: Message notation. Incorrect notation in Figure 333 p.414 Source: Ericsson (Dr. Oystein Haugen, oystein.haugen@ericsson.no oystein.haugen@ericsson.com Oystein.Haugen@eto.ericsson.se) Summary: Firstly not even the original (which is in Visio) has the appropriate dashed line of creation (I thought the pdf just had not quite got it right which happens often, but now I checked the original). Secondly the reply messages should have filled arrowheads (again judging from the description of the message notation). The FTF should reconsider the concrete syntax for create and reply and update the figures accordingly. Originally reported by David Fado through Jim Odell. Discussion: After discussions with Oystein, I have concluded the following: Allow both synchronous and asynchronous create and destroy messages, since both options seem to be supported by the action semantics (CreateObjectAction and DestroyObjectAction). However, the create action must always have a return message because this is how it is defined. Use a dashed arrow to denote both object creation and destruction messages. For synchronous versions of these messages, use the filled arrowhead and a stick arrowhead for asynchronous versions. For returns, the style of arrowhead should match the style that was used for the creation/destruction arrowhead. Thus, the return from an asynchronous call action would be a dashed line with a stick arrowhead, whereas a return from a synchronous call action would have a filled arrowhead. In fact, I suggest that the above convention be applied consistently for all return messages. (This is necessary because we support asynchronous calls in the action semantics.) This requires the following changes to the spec: Pg.407, fig. 328: add .synchCreate., .asynchCreate., .synchDestroy. , and .AsynchDestroy. to the list of the MessageSort enumeration item. Pg.407, fig. 328: remove .synchSignal. from the list of the MessageSort enumeration item (because there is no corresponding action in the action semantics) Pg. 414, fig. 333: replace the figure with the following diagram: Pg. 428, add: synchCreate,asynchCreate, synchDestroy, asynchDestroy at the end of the list of message sorts in the description of the messageSort:MessageSort attribute in the Attributes section of item 14.3.14 Pg. 429 replace the following paragraph in the .Semantics. section: A Message reflects either an Operation call and start of execution . or a sending or reception of a Signal With the following text: A Message reflects any of the following: o Operation call and start of execution, o Object creation action and the creation of the object o Object destruction and cessation of execution, o a sending and reception of a Signal and start of execution Pg. 429 add the following paragraphs to the end of the .Semantics. section: If the Message represents a CreateObjectAction, it may be either a synchCreate or an asynchCreate MessageSort and there will always be a return message from the called (receiving) Lifeline to the calling (sending) Lifeline. If the Message represents a DestroyObjectAction, then it may be either an asynchDestroy or synchDestroy MessageSort. A return message will only exist from the called Lifeline to the calling Lifeline if it is a synchDestroy message sort. When a Message represents a CreateObjectAction that has arguments the rule for arguments is the same as for Operation calls or Signal sends (depending on whether the call is synchronous or asynchronous). Pg. 430 replace the line: Object creation Message has a dashed line with an open arrow. With the following text: An Object creation Message is represented by a dashed line from the creating object.s Lifeline and terminating on the Lifeline rectangle symbol corresponding to the object that is created by the action. The corresponding return Message is represented by a dashed line emanating from the Lifeline rectangle and terminating on the creation object.s Lifeline. If the message sort is a synchCreate, then the arrowhead will be filled in both cases. If the message sort is asynchCreate, then the stick arrowhead is used in both cases. An Object destruction Message is represented by a dashed line emanating from the destroying object.s Lifeline and terminating on the Stop symbol on the Lifeline of the object that is destroyed. If the message sort is synchDestroy, then the arrowhead of the destruction message is filled and there is a corresponding reply message with a filled arrowhead emanating from the Stop symbol of the Lifeline of the object that is being destroyed back to the Lifeline of the destroying object. If the message sort is an asynchDestroy, a stick arrowhead is used and no return message exists. Pg. 430 replace the sentence: We also see a Message that represents the creation of an object. With the sentence: We also see a Message that creates an object synchronously and a message that destroys an object asynchronously. Pg. 438, table 15 Notation entry for Message: Add a dashed line with a filled arrowhead below the one with the stick arrowhead. Pg. 438, table 15 Reference entry for Message, replace the sentence: Here we show an asynchronous message, a call, and a reply. With the sentence: Here we show an asynchronous message, a synchronous message, a return message to an asynchronous operation call (or an asynchronous create object or destroy object message), and a return message to a synchronous operation call or object creation message. Disposition: Resolve OMG Issue No: 6077 Title: Message notation. Incorrect notation in Figure 333 p.414 Source: Ericsson (Dr. Oystein Haugen, oystein.haugen@ericsson.no oystein.haugen@ericsson.com Oystein.Haugen@eto.ericsson.se) Summary: Firstly not even the original (which is in Visio) has the appropriate dashed line of creation (I thought the pdf just had not quite got it right which happens often, but now I checked the original). Secondly the reply messages should have filled arrowheads (again judging from the description of the message notation). The FTF should reconsider the concrete syntax for create and reply and update the figures accordingly. Originally reported by David Fado through Jim Odell. Discussion: After discussions with Oystein, I have concluded the following: Allow both synchronous and asynchronous create and destroy messages, since both options seem to be supported by the action semantics (CreateObjectAction and DestroyObjectAction). However, the create action must always have a return message because this is how it is defined. Use a dashed arrow to denote both object creation and destruction messages. For synchronous versions of these messages, use the filled arrowhead and a stick arrowhead for asynchronous versions. For returns, the style of arrowhead should match the style that was used for the creation/destruction arrowhead. Thus, the return from an asynchronous call action would be a dashed line with a stick arrowhead, whereas a return from a synchronous call action would have a filled arrowhead. In fact, I suggest that the above convention be applied consistently for all return messages. (This is necessary because we support asynchronous calls in the action semantics.) This requires the following changes to the spec: Pg.407, fig. 328: add .synchCreate., .asynchCreate., .synchDestroy. , and .AsynchDestroy. to the list of the MessageSort enumeration item. Pg.407, fig. 328: remove .synchSignal. from the list of the MessageSort enumeration item (because there is no corresponding action in the action semantics) Pg. 414, fig. 333: replace the figure with the following diagram: Pg. 428, add: synchCreate,asynchCreate, synchDestroy, asynchDestroy at the end of the list of message sorts in the description of the messageSort:MessageSort attribute in the Attributes section of item 14.3.14 Pg. 429 replace the following paragraph in the .Semantics. section: A Message reflects either an Operation call and start of execution . or a sending or reception of a Signal With the following text: A Message reflects any of the following: o Operation call and start of execution, o Object creation action and the creation of the object o Object destruction and cessation of execution, o a sending and reception of a Signal and start of execution Pg. 429 add the following paragraphs to the end of the .Semantics. section: If the Message represents a CreateObjectAction, it may be either a synchCreate or an asynchCreate MessageSort and there will always be a return message from the called (receiving) Lifeline to the calling (sending) Lifeline. If the Message represents a DestroyObjectAction, then it may be either an asynchDestroy or synchDestroy MessageSort. A return message will only exist from the called Lifeline to the calling Lifeline if it is a synchDestroy message sort. When a Message represents a CreateObjectAction that has arguments the rule for arguments is the same as for Operation calls or Signal sends (depending on whether the call is synchronous or asynchronous). Pg. 430 replace the line: Object creation Message has a dashed line with an open arrow. With the following text: An Object creation Message is represented by a dashed line from the creating object.s Lifeline and terminating on the Lifeline rectangle symbol corresponding to the object that is created by the action. The corresponding return Message is represented by a dashed line emanating from the Lifeline rectangle and terminating on the creation object.s Lifeline. If the message sort is a synchCreate, then the arrowhead will be filled in both cases. If the message sort is asynchCreate, then the stick arrowhead is used in both cases. An Object destruction Message is represented by a dashed line emanating from the destroying object.s Lifeline and terminating on the Stop symbol on the Lifeline of the object that is destroyed. If the message sort is synchDestroy, then the arrowhead of the destruction message is filled and there is a corresponding reply message with a filled arrowhead emanating from the Stop symbol of the Lifeline of the object that is being destroyed back to the Lifeline of the destroying object. If the message sort is an asynchDestroy, a stick arrowhead is used and no return message exists. Pg. 430 replace the sentence: We also see a Message that represents the creation of an object. With the sentence: We also see a Message that creates an object synchronously and a message that destroys an object asynchronously. Pg. 438, table 15 Notation entry for Message: Add a dashed line with a filled arrowhead below the one with the stick arrowhead. Pg. 438, table 15 Reference entry for Message, replace the sentence: Here we show an asynchronous message, a call, and a reply. With the sentence: Here we show an asynchronous message, a synchronous message, a return message to an asynchronous operation call (or an asynchronous create object or destroy object message), and a return message to a synchronous operation call or object creation message. Disposition: Resolved Subject: Re: ,ia, ExecutionOccurence discussion related to 6077 and 6972 Date: Mon, 16 Feb 2004 14:26:14 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Issue 6077: questions Thread-Index: AcPxBQqTRPSUL3SgR/6vcFQDcp8DYgBQGlsQAJmzVzA= From: "Nikolai Mansurov" To: "Branislav Selic" , , "Moore, Alan" Cc: Dear colleagues, Following-up the discussion on issue 6972 as well as the discussion regarding 6077, it occures to me that there is some inconsistency in the current specification regarding the nature of the ExecutionOccurence. In section 14.3.4 we say that "An ExecutionOccurence is an instantiation of a unit of behavior within the Lifeline". This is consistent with the meta-model, where an ExecutionOccurence is defined as a separate class (as a leaf subclass of InteractionFragment, and not as a CombinedFragment). Then we say, that "since the ExecutionOccurence will have some duration, it is represented by two EventOccurences, the start EventOccurence and the finish EventOccurence." However later we are saying, that "there may be other EventOccurences between [start and finish]". This seems to contradict the above concept of an ExecutionOccurence as a unit of behavior, and a leaf subclass of InteractionFragment. For example, on Figure 333 ExecutionOccurences for ob1, ob2 and ob3 are not quite units, because they cover some InteractionFragments, even a CombinedFragment in case of ob1. The way the meta-model is constructed, there is no logical relation between the InteractionFragments covered by the ExecutionOccurence symbol (i.e. between the ExecutionOccurence and those EventOccurences between start and stop). Instead, there is only a temporal relation. The following several questions can be raised: 1) Are there any missing semantic constraints on what events may or may not occur between start and finish? In particular, how start and finish are related to the InteractionOperands of the CombinedFragments? Is it propser nesting, or do we also allow non-nestable overlaps? 2) The second question was raised in 6972: can ExecutionOccurences themselves be nested ? And should they always be properly nested ? The way how ExecutionOccurence is defined today, there seems to be no constraint whatsoever to have non-nestable partially overlapping ExecutionOccurences: start1 start2 finish1 finish2 Following-up on the discussion on 6077: 3) How ExecutionOccurences are related to Calls and associated replies ? In particular, are replies always emanate from an ExecutionOccurence ? The illustrations in the specification suggest that. Is a synch Call always associated with an ExecutionOccurence ? Again the illustrations suggest that. Is ExecutionOccurence always triggered by a Call ? For example, can it be triggered by an asynch Signal ? I have created a small illustration that goes beyond Figure 333 in highlighting the above questions (attached). The above issues can be solved by - making ExecutionOccurence a subclass of the CombinedFragment, - associating the ExecutionOccurence with an optional trigger EventOccurence (call, signal, create or destroy) - associating replies with the ExecutionOccurence. This will disambiguate nesting of ExecutionOccurences and other InteractionFragments at the cost of disallowing situations a), e) and f) in the attached example. I suggest that the modified example is included in the spec. This can be a resolution for 6972, but it is related to the proposed resolutions on 6077 and few other issues. Any comments? Best regards, Nick Subject: RE: ,ia, issue 6077 Date: Mon, 16 Feb 2004 15:21:05 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Yet more proposed resolutions from Bran Thread-Index: AcP0HP3Ms56oDxfdQESBxTdW0hkQwwApeP+g From: "Nikolai Mansurov" To: "Branislav Selic" , Hi Bran, In your resolution to 6077 you suggest that there always be a return message from the created Lifeline, as well as a return message from an synchDestroy message. May I suggest that the return messages from created or destroyed Lifelines are made optional. The suggested graphical notation with return messages looks too complex. On the other hand, it is not possible to fully utilize the return of the CreateObjectAction without further changes in the Interaction diagrams. The return from synchDestroy seems to be least useful the suggested returns. The optional return message from created Lifeline and Stop symbol can be introduced as special graphical symbols: - create message as a dashed line flowing into the Lifeline head; - reply emanaing from the Lifeline head (?) - destroy message, flowing into the Stop symbol - reply from a synchDestroy, as emanating from the Stop symbol (?!) I'll raise the issue add these entries into table 15. Here are the detailed arguments for makinf returns from create and destroy optional: You suggest the following: Allow both synchronous and asynchronous create and destroy messages, since both options seem to be supported by the action semantics (CreateObjectAction and DestroyObjectAction). However, the create action must always have a return message because this is how it is defined. Pg. 429 add the following paragraphs to the end of the .Semantics. section: If the Message represents a CreateObjectAction, it may be either a synchCreate or an asynchCreate MessageSort and there will always be a return message from the called (receiving) Lifeline to the calling (sending) Lifeline. If the Message represents a DestroyObjectAction, then it may be either an asynchDestroy or synchDestroy MessageSort. A return message will only exist from the called Lifeline to the calling Lifeline if it is a synchDestroy message sort. Section 11 does define "CreateObjectAction is an action that creates an object that conforms to a statically specified classifier and puts it on an output pin at runtime." This classifier can then be used as an input pin e.g. for DestroyObjectAction, but also in SendSignalAction, CallOperationAction, SendObjectAction, etc. One would also expect to be able to pass such classifiers as message parameters maybe also store them in some datastructures (lists, tables, sets, etc.). However, in Sequence Diagrams the identity of the interaction partner is always explicit (i.e. the Lifeline to which a message is addressed). This is a fundamental feature (limitation?) of sequence diagrams. In Sequence Diagrams the returned classifier corresponds to the name of the Lifeline, therefore ther return line is somewhat redundant. In order to fully utilize returned classifiers, more changes need to be done, that in my opinion are outside of the FTF scope. In particular, there should be a general mechanisms to - get object identities, e.g. via the OutputPin of the CreateObjectAction, ReadSelfAction, or TestIdentityAction, - to use object identities as message parameters, - to store them in attiributes of Lifelines - to use them, corresponding to the use of the InputPin, e.g. for DestroyObjectAction, but also in SendSignalAction, CallOperationAction, SendObjectAction, etc. These changes go well beyond the Interaction section itself. Without these changes, the benefits of always having the return message from the created Lifeline seems to be quite limited indeed. Cheers, Nick -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: February 15, 2004 6:33 PM To: uml2-superstructure-ftf@omg.org Subject: Yet more proposed resolutions from Bran I have added resolutions to the following issues to my list of proposed resolutions for ballot 8: 6018, 6077, 6085, 6164, 6230, 6643, 6874, 6911 They are included in the attached document and identified by the change bars from the resolutions I have already published in earlier versions of this document. All of them require trivial, obvious, and non-contentious resolutions and I do not expect any objections to them. However, please DO check them out, just in case. I am desperately hoping to get at least another dozen or so similar simple and non-contentious resolution proposals from the rest of the FTF members, so that we can have a respectable number of resolutions on ballot 8, which starts of Wednesday. Otherwise, we will be dropping behind the resolutions pace that we had set as our objective (cca. 30 resolutions every 2 weeks) -- which means further schedule slippage (aargh!). Regards, Bran To: "Nikolai Mansurov" Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 16 Feb 2004 19:35:29 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/16/2004 19:35:33, Serialize complete at 02/16/2004 19:35:33 I would certainly like to make return messages optional, since that is how many systems do these things. However, this is something that, in my view, is dictated by the action semantics. We should ask Conrad whether it is possible to define a return-free create-object action. Of course, it should also be possible to model things at an abstract level where one can ignore the detail that a return message comes back from these operations. Bran "Nikolai Mansurov" 02/16/2004 03:21 PM To: Branislav Selic/Ottawa/IBM@IBMCA, cc: Subject: RE: ,ia, issue 6077 Hi Bran, In your resolution to 6077 you suggest that there always be a return message from the created Lifeline, as well as a return message from an synchDestroy message. May I suggest that the return messages from created or destroyed Lifelines are made optional. The suggested graphical notation with return messages looks too complex. On the other hand, it is not possible to fully utilize the return of the CreateObjectAction without further changes in the Interaction diagrams. The return from synchDestroy seems to be least useful the suggested returns. The optional return message from created Lifeline and Stop symbol can be introduced as special graphical symbols: - create message as a dashed line flowing into the Lifeline head; - reply emanaing from the Lifeline head (?) - destroy message, flowing into the Stop symbol - reply from a synchDestroy, as emanating from the Stop symbol (?!) I'll raise the issue add these entries into table 15. Here are the detailed arguments for makinf returns from create and destroy optional: You suggest the following: Allow both synchronous and asynchronous create and destroy messages, since both options seem to be supported by the action semantics (CreateObjectAction and DestroyObjectAction). However, the create action must always have a return message because this is how it is defined. Pg. 429 add the following paragraphs to the end of the ..Semantics. section: If the Message represents a CreateObjectAction, it may be either a synchCreate or an asynchCreate MessageSort and there will always be a return message from the called (receiving) Lifeline to the calling (sending) Lifeline. If the Message represents a DestroyObjectAction, then it may be either an asynchDestroy or synchDestroy MessageSort. A return message will only exist from the called Lifeline to the calling Lifeline if it is a synchDestroy message sort. Section 11 does define "CreateObjectAction is an action that creates an object that conforms to a statically specified classifier and puts it on an output pin at runtime." This classifier can then be used as an input pin e.g. for DestroyObjectAction, but also in SendSignalAction, CallOperationAction, SendObjectAction, etc. One would also expect to be able to pass such classifiers as message parameters maybe also store them in some datastructures (lists, tables, sets, etc.). However, in Sequence Diagrams the identity of the interaction partner is always explicit (i.e. the Lifeline to which a message is addressed). This is a fundamental feature (limitation?) of sequence diagrams. In Sequence Diagrams the returned classifier corresponds to the name of the Lifeline, therefore ther return line is somewhat redundant. In order to fully utilize returned classifiers, more changes need to be done, that in my opinion are outside of the FTF scope. In particular, there should be a general mechanisms to - get object identities, e.g. via the OutputPin of the CreateObjectAction, ReadSelfAction, or TestIdentityAction, - to use object identities as message parameters, - to store them in attiributes of Lifelines - to use them, corresponding to the use of the InputPin, e.g. for DestroyObjectAction, but also in SendSignalAction, CallOperationAction, SendObjectAction, etc. These changes go well beyond the Interaction section itself. Without these changes, the benefits of always having the return message from the created Lifeline seems to be quite limited indeed. Cheers, Nick -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: February 15, 2004 6:33 PM To: uml2-superstructure-ftf@omg.org Subject: Yet more proposed resolutions from Bran I have added resolutions to the following issues to my list of proposed resolutions for ballot 8: 6018, 6077, 6085, 6164, 6230, 6643, 6874, 6911 They are included in the attached document and identified by the change bars from the resolutions I have already published in earlier versions of this document. All of them require trivial, obvious, and non-contentious resolutions and I do not expect any objections to them. However, please DO check them out, just in case. I am desperately hoping to get at least another dozen or so similar simple and non-contentious resolution proposals from the rest of the FTF members, so that we can have a respectable number of resolutions on ballot 8, which starts of Wednesday. Otherwise, we will be dropping behind the resolutions pace that we had set as our objective (cca. 30 resolutions every 2 weeks) -- which means further schedule slippage (aargh!). Regards, Bran Date: Tue, 17 Feb 2004 09:30:56 +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: Nikolai Mansurov CC: Branislav Selic , oysteinh@ifi.uio.no, "Moore, Alan" , uml2-superstructure-ftf@omg.org Subject: Re: ,ia, ExecutionOccurence discussion related to 6077 and 6972 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=1.119, required 12, HTML_20_30 0.47, HTML_FONTCOLOR_BLUE 0.10, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.54) X-UiO-Spam-score: s Nick I think that there is not much of a problem here after all. Firstly, a "unit" does not at all mean an "atomic unit". An execution occurrence is just something that models some behavior which is seen on the lifeline as making up some conceptual whole. Typically an execution occurrence is a representation of the execution of a method. Of course a method may contain sending and receiving of other messages and even nested calls on other internal methods. In the metamodel it did not have to be an interaction fragment, but it felt natural since it is a unit of behavior and that is basically the intuition of an interaction fragment. It is obviously the case that execution occurrence could have been modeled otherwise, but one should keep in mind the interaction semantics of what it represents. Then to your questions. 1) I do not think there are many missing constraints. When you think of a method, there are no restrictions to which actions it may contain. 2) But there is probably missing a constraint that execution occurrences should be propertly nested. 3) It is possible to make closer connections between message calls and replies and corresponding execution occurrences, but I advise against it. The reason is flexibility. Some designers think the execution occurrences are a nuisance and prefer to do without them. I find that all right since if we are talking about calls and replies of methods there is not much added information in the execution occurrences. On the other hand, execution occurrences can also be used to designate units of behavior that the lifeline performs and that we like to describe. In those situations there are no calls/replies associated with the execution occurrence. Both situations work well with the current metamodel. In my opinion only the added constraint of properly nesting execution occurrences should be necessary. /Oystein Nikolai Mansurov wrote: Dear colleagues, Following-up the discussion on issue 6972 as well as the discussion regarding 6077, it occures to me that there is some inconsistency in the current specification regarding the nature of the ExecutionOccurence. In section 14.3.4 we say that "An ExecutionOccurence is an instantiation of a unit of behavior within the Lifeline". This is consistent with the meta-model, where an ExecutionOccurence is defined as a separate class (as a leaf subclass of InteractionFragment, and not as a CombinedFragment). Then we say, that "since the ExecutionOccurence will have some duration, it is represented by two EventOccurences, the start EventOccurence and the finish EventOccurence." However later we are saying, that "there may be other EventOccurences between [start and finish]". This seems to contradict the above concept of an ExecutionOccurence as a unit of behavior, and a leaf subclass of InteractionFragment. For example, on Figure 333 ExecutionOccurences for ob1, ob2 and ob3 are not quite units, because they cover some InteractionFragments, even a CombinedFragment in case of ob1. The way the meta-model is constructed, there is no logical relation between the InteractionFragments covered by the ExecutionOccurence symbol (i.e. between the ExecutionOccurence and those EventOccurences between start and stop). Instead, there is only a temporal relation. The following several questions can be raised: 1) Are there any missing semantic constraints on what events may or may not occur between start and finish? In particular, how start and finish are related to the InteractionOperands of the CombinedFragments? Is it propser nesting, or do we also allow non-nestable overlaps? 2) The second question was raised in 6972: can ExecutionOccurences themselves be nested ? And should they always be properly nested ? The way how ExecutionOccurence is defined today, there seems to be no constraint whatsoever to have non-nestable partially overlapping ExecutionOccurences: start1 start2 finish1 finish2 Following-up on the discussion on 6077: 3) How ExecutionOccurences are related to Calls and associated replies ? In particular, are replies always emanate from an ExecutionOccurence ? The illustrations in the specification suggest that. Is a synch Call always associated with an ExecutionOccurence ? Again the illustrations suggest that. Is ExecutionOccurence always triggered by a Call ? For example, can it be triggered by an asynch Signal ? I have created a small illustration that goes beyond Figure 333 in highlighting the above questions (attached). The above issues can be solved by - making ExecutionOccurence a subclass of the CombinedFragment, - associating the ExecutionOccurence with an optional trigger EventOccurence (call, signal, create or destroy) - associating replies with the ExecutionOccurence. This will disambiguate nesting of ExecutionOccurences and other InteractionFragments at the cost of disallowing situations a), e) and f) in the attached example. I suggest that the modified example is included in the spec. This can be a resolution for 6972, but it is related to the proposed resolutions on 6077 and few other issues. Any comments? Best regards, Nick -- 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 Date: Tue, 17 Feb 2004 14:40:31 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: Branislav Selic CC: Nikolai Mansurov , uml2-superstructure-ftf@omg.org Subject: Re: ,ia, issue 6077 Bran, > Of course, it should also be possible to model things at an abstract level where one can ignore the detail that a return message comes back from these operations. Agreed that this is needed, for general return messages. Thanks, guus Branislav Selic wrote: I would certainly like to make return messages optional, since that is how many systems do these things. However, this is something that, in my view, is dictated by the action semantics. We should ask Conrad whether it is possible to define a return-free create-object action. Of course, it should also be possible to model things at an abstract level where one can ignore the detail that a return message comes back from these operations. Bran "Nikolai Mansurov" 02/16/2004 03:21 PM To: Branislav Selic/Ottawa/IBM@IBMCA, cc: Subject: RE: ,ia, issue 6077 Hi Bran, In your resolution to 6077 you suggest that there always be a return message from the created Lifeline, as well as a return message from an synchDestroy message. May I suggest that the return messages from created or destroyed Lifelines are made optional. The suggested graphical notation with return messages looks too complex. On the other hand, it is not possible to fully utilize the return of the CreateObjectAction without further changes in the Interaction diagrams. The return from synchDestroy seems to be least useful the suggested returns. The optional return message from created Lifeline and Stop symbol can be introduced as special graphical symbols: - create message as a dashed line flowing into the Lifeline head; - reply emanaing from the Lifeline head (?) - destroy message, flowing into the Stop symbol - reply from a synchDestroy, as emanating from the Stop symbol (?!) I'll raise the issue add these entries into table 15. Here are the detailed arguments for makinf returns from create and destroy optional: You suggest the following: Allow both synchronous and asynchronous create and destroy messages, since both options seem to be supported by the action semantics (CreateObjectAction and DestroyObjectAction). However, the create action must always have a return message because this is how it is defined. Pg. 429 add the following paragraphs to the end of the ..Semantics. section: If the Message represents a CreateObjectAction, it may be either a synchCreate or an asynchCreate MessageSort and there will always be a return message from the called (receiving) Lifeline to the calling (sending) Lifeline. If the Message represents a DestroyObjectAction, then it may be either an asynchDestroy or synchDestroy MessageSort. A return message will only exist from the called Lifeline to the calling Lifeline if it is a synchDestroy message sort. Section 11 does define "CreateObjectAction is an action that creates an object that conforms to a statically specified classifier and puts it on an output pin at runtime." This classifier can then be used as an input pin e.g. for DestroyObjectAction, but also in SendSignalAction, CallOperationAction, SendObjectAction, etc. One would also expect to be able to pass such classifiers as message parameters maybe also store them in some datastructures (lists, tables, sets, etc.). However, in Sequence Diagrams the identity of the interaction partner is always explicit (i.e. the Lifeline to which a message is addressed). This is a fundamental feature (limitation?) of sequence diagrams. In Sequence Diagrams the returned classifier corresponds to the name of the Lifeline, therefore ther return line is somewhat redundant. In order to fully utilize returned classifiers, more changes need to be done, that in my opinion are outside of the FTF scope. In particular, there should be a general mechanisms to - get object identities, e.g. via the OutputPin of the CreateObjectAction, ReadSelfAction, or TestIdentityAction, - to use object identities as message parameters, - to store them in attiributes of Lifelines - to use them, corresponding to the use of the InputPin, e.g. for DestroyObjectAction, but also in SendSignalAction, CallOperationAction, SendObjectAction, etc. These changes go well beyond the Interaction section itself. Without these changes, the benefits of always having the return message from the created Lifeline seems to be quite limited indeed. Cheers, Nick -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: February 15, 2004 6:33 PM To: uml2-superstructure-ftf@omg.org Subject: Yet more proposed resolutions from Bran I have added resolutions to the following issues to my list of proposed resolutions for ballot 8: 6018, 6077, 6085, 6164, 6230, 6643, 6874, 6911 They are included in the attached document and identified by the change bars from the resolutions I have already published in earlier versions of this document. All of them require trivial, obvious, and non-contentious resolutions and I do not expect any objections to them. However, please DO check them out, just in case. I am desperately hoping to get at least another dozen or so similar simple and non-contentious resolution proposals from the rest of the FTF members, so that we can have a respectable number of resolutions on ballot 8, which starts of Wednesday. Otherwise, we will be dropping behind the resolutions pace that we had set as our objective (cca. 30 resolutions every 2 weeks) -- which means further schedule slippage (aargh!). Regards, Bran -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 To: uml2-superstructure-ftf@omg.org, oysteinh@ifi.uio.no Subject: Issue 6077 -- pull or leave on ballot: X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 17 Feb 2004 09:57:33 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/17/2004 10:03:00, Serialize complete at 02/17/2004 10:03:00 With the flurry of discussion on 6077, I am no longer sure if there is agreement on the current proposal to solve this issue or not. The current proposal is in the set of draft resolutions I published last night. If you think that it needs more discussion, please tell me and I will pull it from the ballot. If I don't hear form you, I will assume that you think it is appropriate and sufficient. Thanks, Bran Subject: RE: ,ia, issue 6077 Date: Tue, 17 Feb 2004 11:53:24 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,ia, issue 6077 Thread-Index: AcP07g6MYZfycs3jQ5uC8EkQudUStwAgz8DQ From: "Nikolai Mansurov" To: "Branislav Selic" Cc: I don't think it is possible to define a return-free create-object action, since the output PIN is essential for performing further operations on this object. However, in a Sequence Diagram, all subsequent operations to the newly created Lifeline are represented as graphical paths FLOWING INTO THAT Lifelife. Therefore, within one diagrams at least, the identity of the created object is implicit. Explicit return from the create-object action introduces explicit identities of objects, which may conflict with the implicit identities as Lifelines. I'll prepare an illustration shortly. One way to align with the action semantic, yet keep it optional was taken in ITU standards: 4 implicit attributes were introduced - CHILD, PARENT, SENDER and SELF of sort PId, which is the predefined object identity sort. CHILD is implicitly set to the identity of the last created object (or NULL, if none were created) PARENT is implicitly set to the identity of the parent (or NULL, if the object is static) SENDER is implicitly set is the identity of the sender of the last received message SELF is the identity of the object itself. This approach may eliminate the need of an explicit return message, but still leaves us with the conflict between the explicit object identities and the lifelineidents. My point is that a mere return message from create is not sufficient for solving the issue of DYNAMIC ADDRESSING in Sequence Diagrams, which at this point have only static addressing via graphic paths to lifelines. I suggest to postpone the vote on 6077 and revisit it since there is a number of other issues that can be consolidated into 6077 (like 6260 and 6019). Postponing 6077 for a round will give us a chance to check that we have addressed them all properly. In this case 6260 and 6019 can be closed in tis round. Cheers, Nick -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: February 16, 2004 7:35 PM To: Nikolai Mansurov Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 I would certainly like to make return messages optional, since that is how many systems do these things. However, this is something that, in my view, is dictated by the action semantics. We should ask Conrad whether it is possible to define a return-free create-object action. Of course, it should also be possible to model things at an abstract level where one can ignore the detail that a return message comes back from these operations. Bran "Nikolai Mansurov" 02/16/2004 03:21 PM To: Branislav Selic/Ottawa/IBM@IBMCA, cc: Subject: RE: ,ia, issue 6077 Hi Bran, In your resolution to 6077 you suggest that there always be a return message from the created Lifeline, as well as a return message from an synchDestroy message. May I suggest that the return messages from created or destroyed Lifelines are made optional. The suggested graphical notation with return messages looks too complex. On the other hand, it is not possible to fully utilize the return of the CreateObjectAction without further changes in the Interaction diagrams. The return from synchDestroy seems to be least useful the suggested returns. The optional return message from created Lifeline and Stop symbol can be introduced as special graphical symbols: - create message as a dashed line flowing into the Lifeline head; - reply emanaing from the Lifeline head (?) - destroy message, flowing into the Stop symbol - reply from a synchDestroy, as emanating from the Stop symbol (?!) I'll raise the issue add these entries into table 15. Here are the detailed arguments for makinf returns from create and destroy optional: You suggest the following: Allow both synchronous and asynchronous create and destroy messages, since both options seem to be supported by the action semantics (CreateObjectAction and DestroyObjectAction). However, the create action must always have a return message because this is how it is defined. Pg. 429 add the following paragraphs to the end of the ..Semantics. section: If the Message represents a CreateObjectAction, it may be either a synchCreate or an asynchCreate MessageSort and there will always be a return message from the called (receiving) Lifeline to the calling (sending) Lifeline. If the Message represents a DestroyObjectAction, then it may be either an asynchDestroy or synchDestroy MessageSort. A return message will only exist from the called Lifeline to the calling Lifeline if it is a synchDestroy message sort. Section 11 does define "CreateObjectAction is an action that creates an object that conforms to a statically specified classifier and puts it on an output pin at runtime." This classifier can then be used as an input pin e.g. for DestroyObjectAction, but also in SendSignalAction, CallOperationAction, SendObjectAction, etc. One would also expect to be able to pass such classifiers as message parameters maybe also store them in some datastructures (lists, tables, sets, etc.). However, in Sequence Diagrams the identity of the interaction partner is always explicit (i.e. the Lifeline to which a message is addressed). This is a fundamental feature (limitation?) of sequence diagrams. In Sequence Diagrams the returned classifier corresponds to the name of the Lifeline, therefore ther return line is somewhat redundant. In order to fully utilize returned classifiers, more changes need to be done, that in my opinion are outside of the FTF scope. In particular, there should be a general mechanisms to - get object identities, e.g. via the OutputPin of the CreateObjectAction, ReadSelfAction, or TestIdentityAction, - to use object identities as message parameters, - to store them in attiributes of Lifelines - to use them, corresponding to the use of the InputPin, e.g. for DestroyObjectAction, but also in SendSignalAction, CallOperationAction, SendObjectAction, etc. These changes go well beyond the Interaction section itself. Without these changes, the benefits of always having the return message from the created Lifeline seems to be quite limited indeed. Cheers, Nick -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: February 15, 2004 6:33 PM To: uml2-superstructure-ftf@omg.org Subject: Yet more proposed resolutions from Bran I have added resolutions to the following issues to my list of proposed resolutions for ballot 8: 6018, 6077, 6085, 6164, 6230, 6643, 6874, 6911 They are included in the attached document and identified by the change bars from the resolutions I have already published in earlier versions of this document. All of them require trivial, obvious, and non-contentious resolutions and I do not expect any objections to them. However, please DO check them out, just in case. I am desperately hoping to get at least another dozen or so similar simple and non-contentious resolution proposals from the rest of the FTF members, so that we can have a respectable number of resolutions on ballot 8, which starts of Wednesday. Otherwise, we will be dropping behind the resolutions pace that we had set as our objective (cca. 30 resolutions every 2 weeks) -- which means further schedule slippage (aargh!). Regards, Bran To: "Nikolai Mansurov" Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 17 Feb 2004 12:27:24 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/17/2004 12:27:29, Serialize complete at 02/17/2004 12:27:29 I will pull out the proposed resolution to issue 6077 from ballot 8. However, to ensure that such discussions do not go on forever (cluttering up inboxes and taking up inordinate amounts of time), the chairs will impose relatively short time limits after which resolutions will go to a vote. More information to follow later today. Bran To: "Nikolai Mansurov" Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 17 Feb 2004 12:31:32 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/17/2004 12:31:36, Serialize complete at 02/17/2004 12:31:36 Nick, While such a level of precision is definitely required in some cases, it is definitely not required in all. Some people will want to model things at a very high level of abstraction ignoring things such as "child", "parent", return messages and the like. A return-free create message is easily achieved if the metamodel makes the link between a create message and a create action optional. So, contrary to what I said in a previous e-mail, the coupling between action semantics and messages should not be mandatory. Bran Selic 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 "Nikolai Mansurov" 02/17/2004 11:53 AM To: Branislav Selic/Ottawa/IBM@IBMCA cc: Subject: RE: ,ia, issue 6077 I don't think it is possible to define a return-free create-object action, since the output PIN is essential for performing further operations on this object. However, in a Sequence Diagram, all subsequent operations to the newly created Lifeline are represented as graphical paths FLOWING INTO THAT Lifelife. Therefore, within one diagrams at least, the identity of the created object is implicit. Explicit return from the create-object action introduces explicit identities of objects, which may conflict with the implicit identities as Lifelines. I'll prepare an illustration shortly. One way to align with the action semantic, yet keep it optional was taken in ITU standards: 4 implicit attributes were introduced - CHILD, PARENT, SENDER and SELF of sort PId, which is the predefined object identity sort. CHILD is implicitly set to the identity of the last created object (or NULL, if none were created) PARENT is implicitly set to the identity of the parent (or NULL, if the object is static) SENDER is implicitly set is the identity of the sender of the last received message SELF is the identity of the object itself. This approach may eliminate the need of an explicit return message, but still leaves us with the conflict between the explicit object identities and the lifelineidents. My point is that a mere return message from create is not sufficient for solving the issue of DYNAMIC ADDRESSING in Sequence Diagrams, which at this point have only static addressing via graphic paths to lifelines. I suggest to postpone the vote on 6077 and revisit it since there is a number of other issues that can be consolidated into 6077 (like 6260 and 6019). Postponing 6077 for a round will give us a chance to check that we have addressed them all properly. In this case 6260 and 6019 can be closed in tis round. Cheers, Nick -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: February 16, 2004 7:35 PM To: Nikolai Mansurov Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 I would certainly like to make return messages optional, since that is how many systems do these things. However, this is something that, in my view, is dictated by the action semantics. We should ask Conrad whether it is possible to define a return-free create-object action. Of course, it should also be possible to model things at an abstract level where one can ignore the detail that a return message comes back from these operations. Bran "Nikolai Mansurov" 02/16/2004 03:21 PM To: Branislav Selic/Ottawa/IBM@IBMCA, cc: Subject: RE: ,ia, issue 6077 Hi Bran, In your resolution to 6077 you suggest that there always be a return message from the created Lifeline, as well as a return message from an synchDestroy message. May I suggest that the return messages from created or destroyed Lifelines are made optional. The suggested graphical notation with return messages looks too complex. On the other hand, it is not possible to fully utilize the return of the CreateObjectAction without further changes in the Interaction diagrams. The return from synchDestroy seems to be least useful the suggested returns. The optional return message from created Lifeline and Stop symbol can be introduced as special graphical symbols: - create message as a dashed line flowing into the Lifeline head; - reply emanaing from the Lifeline head (?) - destroy message, flowing into the Stop symbol - reply from a synchDestroy, as emanating from the Stop symbol (?!) I'll raise the issue add these entries into table 15. Here are the detailed arguments for makinf returns from create and destroy optional: You suggest the following: Allow both synchronous and asynchronous create and destroy messages, since both options seem to be supported by the action semantics (CreateObjectAction and DestroyObjectAction). However, the create action must always have a return message because this is how it is defined. Pg. 429 add the following paragraphs to the end of the ..Semantics. section: If the Message represents a CreateObjectAction, it may be either a synchCreate or an asynchCreate MessageSort and there will always be a return message from the called (receiving) Lifeline to the calling (sending) Lifeline. If the Message represents a DestroyObjectAction, then it may be either an asynchDestroy or synchDestroy MessageSort. A return message will only exist from the called Lifeline to the calling Lifeline if it is a synchDestroy message sort. Section 11 does define "CreateObjectAction is an action that creates an object that conforms to a statically specified classifier and puts it on an output pin at runtime." This classifier can then be used as an input pin e.g. for DestroyObjectAction, but also in SendSignalAction, CallOperationAction, SendObjectAction, etc. One would also expect to be able to pass such classifiers as message parameters maybe also store them in some datastructures (lists, tables, sets, etc.). However, in Sequence Diagrams the identity of the interaction partner is always explicit (i.e. the Lifeline to which a message is addressed). This is a fundamental feature (limitation?) of sequence diagrams. In Sequence Diagrams the returned classifier corresponds to the name of the Lifeline, therefore ther return line is somewhat redundant. In order to fully utilize returned classifiers, more changes need to be done, that in my opinion are outside of the FTF scope. In particular, there should be a general mechanisms to - get object identities, e.g. via the OutputPin of the CreateObjectAction, ReadSelfAction, or TestIdentityAction, - to use object identities as message parameters, - to store them in attiributes of Lifelines - to use them, corresponding to the use of the InputPin, e.g. for DestroyObjectAction, but also in SendSignalAction, CallOperationAction, SendObjectAction, etc. These changes go well beyond the Interaction section itself. Without these changes, the benefits of always having the return message from the created Lifeline seems to be quite limited indeed. Cheers, Nick -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: February 15, 2004 6:33 PM To: uml2-superstructure-ftf@omg.org Subject: Yet more proposed resolutions from Bran I have added resolutions to the following issues to my list of proposed resolutions for ballot 8: 6018, 6077, 6085, 6164, 6230, 6643, 6874, 6911 They are included in the attached document and identified by the change bars from the resolutions I have already published in earlier versions of this document. All of them require trivial, obvious, and non-contentious resolutions and I do not expect any objections to them. However, please DO check them out, just in case. I am desperately hoping to get at least another dozen or so similar simple and non-contentious resolution proposals from the rest of the FTF members, so that we can have a respectable number of resolutions on ballot 8, which starts of Wednesday. Otherwise, we will be dropping behind the resolutions pace that we had set as our objective (cca. 30 resolutions every 2 weeks) -- which means further schedule slippage (aargh!). Regards, Bran Subject: RE: ,ia, issue 6077 Date: Tue, 17 Feb 2004 15:13:13 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,ia, issue 6077 Thread-Index: AcP1e+bTWGIYrBfWQpiuz53oyCE7iQAFgSlg From: "Nikolai Mansurov" To: "Branislav Selic" Cc: Hi Bran, See my comments below. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: February 17, 2004 12:32 PM To: Nikolai Mansurov Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 Nick, While such a level of precision is definitely required in some cases, it is definitely not required in all. Some people will want to model things at a very high level of abstraction ignoring things such as "child", "parent", return messages and the like. [Nikolai Mansurov] This is exactly the benefit of having some implicit attributes - you can ignore them when you don't need them. A return-free create message is easily achieved if the metamodel makes the link between a create message and a create action optional. So, contrary to what I said in a previous e-mail, the coupling between action semantics and messages should not be mandatory. [Nikolai Mansurov] I'm fine with this. In this case we can define a separate graphic path for return from a synch create a emanating from the Lifeline head. This settls the issue for me. Cheers, Nick Bran Selic 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 "Nikolai Mansurov" 02/17/2004 11:53 AM To: Branislav Selic/Ottawa/IBM@IBMCA cc: Subject: RE: ,ia, issue 6077 I don't think it is possible to define a return-free create-object action, since the output PIN is essential for performing further operations on this object. However, in a Sequence Diagram, all subsequent operations to the newly created Lifeline are represented as graphical paths FLOWING INTO THAT Lifelife. Therefore, within one diagrams at least, the identity of the created object is implicit. Explicit return from the create-object action introduces explicit identities of objects, which may conflict with the implicit identities as Lifelines. I'll prepare an illustration shortly. One way to align with the action semantic, yet keep it optional was taken in ITU standards: 4 implicit attributes were introduced - CHILD, PARENT, SENDER and SELF of sort PId, which is the predefined object identity sort. CHILD is implicitly set to the identity of the last created object (or NULL, if none were created) PARENT is implicitly set to the identity of the parent (or NULL, if the object is static) SENDER is implicitly set is the identity of the sender of the last received message SELF is the identity of the object itself. This approach may eliminate the need of an explicit return message, but still leaves us with the conflict between the explicit object identities and the lifelineidents. My point is that a mere return message from create is not sufficient for solving the issue of DYNAMIC ADDRESSING in Sequence Diagrams, which at this point have only static addressing via graphic paths to lifelines. I suggest to postpone the vote on 6077 and revisit it since there is a number of other issues that can be consolidated into 6077 (like 6260 and 6019). Postponing 6077 for a round will give us a chance to check that we have addressed them all properly. In this case 6260 and 6019 can be closed in tis round. Cheers, Nick -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: February 16, 2004 7:35 PM To: Nikolai Mansurov Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 I would certainly like to make return messages optional, since that is how many systems do these things. However, this is something that, in my view, is dictated by the action semantics. We should ask Conrad whether it is possible to define a return-free create-object action. Of course, it should also be possible to model things at an abstract level where one can ignore the detail that a return message comes back from these operations. Bran "Nikolai Mansurov" 02/16/2004 03:21 PM To: Branislav Selic/Ottawa/IBM@IBMCA, cc: Subject: RE: ,ia, issue 6077 Hi Bran, In your resolution to 6077 you suggest that there always be a return message from the created Lifeline, as well as a return message from an synchDestroy message. May I suggest that the return messages from created or destroyed Lifelines are made optional. The suggested graphical notation with return messages looks too complex. On the other hand, it is not possible to fully utilize the return of the CreateObjectAction without further changes in the Interaction diagrams. The return from synchDestroy seems to be least useful the suggested returns. The optional return message from created Lifeline and Stop symbol can be introduced as special graphical symbols: - create message as a dashed line flowing into the Lifeline head; - reply emanaing from the Lifeline head (?) - destroy message, flowing into the Stop symbol - reply from a synchDestroy, as emanating from the Stop symbol (?!) I'll raise the issue add these entries into table 15. Here are the detailed arguments for makinf returns from create and destroy optional: You suggest the following: Allow both synchronous and asynchronous create and destroy messages, since both options seem to be supported by the action semantics (CreateObjectAction and DestroyObjectAction). However, the create action must always have a return message because this is how it is defined. Pg. 429 add the following paragraphs to the end of the ..Semantics. section: If the Message represents a CreateObjectAction, it may be either a synchCreate or an asynchCreate MessageSort and there will always be a return message from the called (receiving) Lifeline to the calling (sending) Lifeline. If the Message represents a DestroyObjectAction, then it may be either an asynchDestroy or synchDestroy MessageSort. A return message will only exist from the called Lifeline to the calling Lifeline if it is a synchDestroy message sort. Section 11 does define "CreateObjectAction is an action that creates an object that conforms to a statically specified classifier and puts it on an output pin at runtime." This classifier can then be used as an input pin e.g. for DestroyObjectAction, but also in SendSignalAction, CallOperationAction, SendObjectAction, etc. One would also expect to be able to pass such classifiers as message parameters maybe also store them in some datastructures (lists, tables, sets, etc.). However, in Sequence Diagrams the identity of the interaction partner is always explicit (i.e. the Lifeline to which a message is addressed). This is a fundamental feature (limitation?) of sequence diagrams. In Sequence Diagrams the returned classifier corresponds to the name of the Lifeline, therefore ther return line is somewhat redundant. In order to fully utilize returned classifiers, more changes need to be done, that in my opinion are outside of the FTF scope. In particular, there should be a general mechanisms to - get object identities, e.g. via the OutputPin of the CreateObjectAction, ReadSelfAction, or TestIdentityAction, - to use object identities as message parameters, - to store them in attiributes of Lifelines - to use them, corresponding to the use of the InputPin, e.g. for DestroyObjectAction, but also in SendSignalAction, CallOperationAction, SendObjectAction, etc. These changes go well beyond the Interaction section itself. Without these changes, the benefits of always having the return message from the created Lifeline seems to be quite limited indeed. Cheers, Nick -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: February 15, 2004 6:33 PM To: uml2-superstructure-ftf@omg.org Subject: Yet more proposed resolutions from Bran I have added resolutions to the following issues to my list of proposed resolutions for ballot 8: 6018, 6077, 6085, 6164, 6230, 6643, 6874, 6911 They are included in the attached document and identified by the change bars from the resolutions I have already published in earlier versions of this document. All of them require trivial, obvious, and non-contentious resolutions and I do not expect any objections to them. However, please DO check them out, just in case. I am desperately hoping to get at least another dozen or so similar simple and non-contentious resolution proposals from the rest of the FTF members, so that we can have a respectable number of resolutions on ballot 8, which starts of Wednesday. Otherwise, we will be dropping behind the resolutions pace that we had set as our objective (cca. 30 resolutions every 2 weeks) -- which means further schedule slippage (aargh!). Regards, Bran Reply-To: From: "Conrad Bock" To: Subject: RE: ,ia, issue 6077 Date: Tue, 17 Feb 2004 17:26:40 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i1HMJ4rh014682 > We should ask Conrad whether it is possible to define a > return-free create-object action. CreateObjectAction always returns a value and must always have a return pin. You don't need to have an object flow coming out of the pin, however, ie, you don't need to have any other action dependent on the returned value. OTOH, the containing activity cannot complete if the CreateObjectAction hasn't returned. Conrad Reply-To: From: "Conrad Bock" To: Subject: RE: ,ia, issue 6077 Date: Tue, 17 Feb 2004 17:29:08 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i1HMLTrh014706 Bran, > A return-free create message is easily achieved if the metamodel makes > the link between a create message and a create action optional. So, > contrary to what I said in a previous e-mail, the coupling between > action semantics and messages should not be mandatory. Agreed, but you don't want the the sequence diagram to specify a behavior that is not implementable in actions. Conrad Subject: RE: ,ia, issue 6077 Date: Tue, 17 Feb 2004 17:59:23 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,ia, issue 6077 Thread-Index: AcP1pX+sN0FGgGrTSyC6Gx4Rc7b3nQAA7MRI From: "Karl Frank" To: , X-OriginalArrivalTime: 17 Feb 2004 22:59:24.0541 (UTC) FILETIME=[AFDEFAD0:01C3F5A9] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i1HMplrh014867 See below. Karl -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Tue 2/17/2004 5:29 PM To: uml2-superstructure-ftf@omg.org Cc: Subject: RE: ,ia, issue 6077 Bran, > A return-free create message is easily achieved if the metamodel makes > the link between a create message and a create action optional. So, > contrary to what I said in a previous e-mail, the coupling between > action semantics and messages should not be mandatory. Agreed, but you don't want the the sequence diagram to specify a behavior that is not implementable in actions. Conrad I would guess that the sequence diagram can show an action handling a message without showing the return, a simple elision will keep the diagram simple, and if an action is bound to handle the message, the action can have a return that is created by default by the modeling tool, without the modeler having to think at that level of detail. Or??? Karl Frank Borland To: Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 17 Feb 2004 18:07:24 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/17/2004 18:07:27, Serialize complete at 02/17/2004 18:07:27 This sounds like the create object action is overspecified. I know many systems -- particlarly distributed ones -- where the creation action is asynchronous and does not imply any blocking on the creator's part. Conrad's statement tells me that we cannot model such systems in UML, except perhaps by using trickery with surrogates, etc. I am beginning to believe that it is not a good idea to tie actions and messages closely at this stage of the game. It requires a substantial amount of thinking that is likely out of scope. Bran "Conrad Bock" 02/17/2004 05:26 PM Please respond to conrad.bock To: cc: Subject: RE: ,ia, issue 6077 > We should ask Conrad whether it is possible to define a > return-free create-object action. CreateObjectAction always returns a value and must always have a return pin. You don't need to have an object flow coming out of the pin, however, ie, you don't need to have any other action dependent on the returned value. OTOH, the containing activity cannot complete if the CreateObjectAction hasn't returned. Conrad Subject: RE: ,ia, issue 6077 Date: Tue, 17 Feb 2004 18:19:06 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ,ia, issue 6077 Thread-Index: AcP1pefRFRcPWjojS4S+X0V8hFIFPAAA6dGg From: "Nikolai Mansurov" To: , Cc: "Branislav Selic (E-mail)" I apologize for spending what seems to be an unproportional time on the 6077 discussion, the only justification being that this is also related to bigger issues 6264 and 6153 on aligning various behavior semantics, so this is sort of important. I'd like to have some feedback from Behavior experts on the following: The semantics for CreateObjectAction says (page 234), that "the new object has no structural feature values and participates in no links". From the Interactions perspective does it make sense to 1) describe the Create message as more abstract than that, by implying that all the necessary structural feature values and links are created, when a Lifeline receives a create message, or 2) do we need to be able to also model CreateLinkAction explicitly, in order for the new lifeline to participate in interactions that may involve such links. I'm also attaching an example of several situations, where Interactions can benefit from closer ties with Actions, but also the list of issues to make this happen. The illustration focuses on identities of objects and their correspondence to Lifelines, as per my previous message. Cheers, Nick -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: February 17, 2004 5:29 PM To: uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 Bran, > A return-free create message is easily achieved if the metamodel makes > the link between a create message and a create action optional. So, > contrary to what I said in a previous e-mail, the coupling between > action semantics and messages should not be mandatory. Agreed, but you don't want the the sequence diagram to specify a behavior that is not implementable in actions. Conrad create.doc Subject: RE: ,ia, issue 6077 Date: Tue, 17 Feb 2004 18:34:28 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,ia, issue 6077 Thread-Index: AcP1q9UqbBrw/PFdTxmjcLn7rlLHjwAAPq5g From: "Nikolai Mansurov" To: "Branislav Selic" , Cc: When it comes to Actions - we need to know the identity of the dynamically created object in order to work with it further. In this case, an asynchronous create probably implies, that we will eventually receive an asynchronous signal with this identity, or a notification that the create action has failed. However, in Interactions the identity of the new object is already represented as the name if the lifeline being created. Therefore no other identity is required, unless we want to fully support "dynamic addressing" as in Actions. Dynamic addressing in Interactions is probably outside of the FTF's scope, however - a rather desirable feature. Cheers, Nick -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: February 17, 2004 6:07 PM To: conrad.bock@nist.gov Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 This sounds like the create object action is overspecified. I know many systems -- particlarly distributed ones -- where the creation action is asynchronous and does not imply any blocking on the creator's part. Conrad's statement tells me that we cannot model such systems in UML, except perhaps by using trickery with surrogates, etc. I am beginning to believe that it is not a good idea to tie actions and messages closely at this stage of the game. It requires a substantial amount of thinking that is likely out of scope. Bran "Conrad Bock" 02/17/2004 05:26 PM Please respond to conrad.bock To: cc: Subject: RE: ,ia, issue 6077 > We should ask Conrad whether it is possible to define a > return-free create-object action. CreateObjectAction always returns a value and must always have a return pin. You don't need to have an object flow coming out of the pin, however, ie, you don't need to have any other action dependent on the returned value. OTOH, the containing activity cannot complete if the CreateObjectAction hasn't returned. Conrad From: "Thomas Weigert" To: "Nikolai Mansurov" , , Cc: "Branislav Selic \(E-mail\)" Subject: RE: ,ia, issue 6077 Date: Tue, 17 Feb 2004 17:47:57 -0600 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i1HNknrh015123 Dear Nikolai, you are entering a rat hole here that goes back to UML 1.5. There were two "schools of thought" concerning the issue of creation of objects: i. an object is created fully initialized and satisfying all constraints put upon it. ii. an object is created completely uninitialized and any initialization has to be programmed up in terms of the action semantics. There have been endless arguments on either side. The action semantics spec and thus also the UML 2 adopted (ii) as driven by Conrad. The desire, I believe, was that the action semantics be some sort of fundamental "programming notation" in which all kinds of semantics could be implemented, whether that satisfied larger constraints on the UML model or not. At the MSC level, you do not want to get bogged down in these details, as I believe is also expressed in Bran's concerns. At the MSC, you want to say that at this point an object is created and fully initialized. At some point, we had a "CreateFullyInitializedObjectAction" that was supposed to create an object that was not just a bare-bone empty object as is created by CreateObjectAction, but also satisfied the semantic constraints of the UML and was fully initialized by executing initializers defined for it, if any. That "CreateFullyInitializedObjectAction" is actually what you want to map to at the sequence diagram level. All the best, Th. > -----Original Message----- > From: Nikolai Mansurov [mailto:nmansurov@klocwork.com] > Sent: Tuesday, February 17, 2004 5:19 PM > To: conrad.bock@nist.gov; uml2-superstructure-ftf@omg.org > Cc: Branislav Selic (E-mail) > Subject: RE: ,ia, issue 6077 > > > I apologize for spending what seems to be an unproportional time > on the 6077 discussion, the only justification being that this is > also related to bigger issues 6264 and 6153 on aligning various > behavior semantics, so this is sort of important. > > I'd like to have some feedback from Behavior experts on the following: > The semantics for CreateObjectAction says (page 234), that "the > new object has no structural feature values and participates in > no links". > > From the Interactions perspective does it make sense to > 1) describe the Create message as more abstract than that, by > implying that all the necessary structural feature values and > links are created, when a Lifeline receives a create message, > or > 2) do we need to be able to also model CreateLinkAction > explicitly, in order for the new lifeline to participate in > interactions that may involve such links. > > I'm also attaching an example of several situations, where > Interactions can benefit from closer ties with Actions, but also > the list of issues to make this happen. The illustration focuses > on identities of objects and their correspondence to Lifelines, > as per my previous message. > > Cheers, > Nick > > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: February 17, 2004 5:29 PM > To: uml2-superstructure-ftf@omg.org > Subject: RE: ,ia, issue 6077 > > > > Bran, > > > A return-free create message is easily achieved if the metamodel makes > > the link between a create message and a create action optional. So, > > contrary to what I said in a previous e-mail, the coupling between > > action semantics and messages should not be mandatory. > > Agreed, but you don't want the the sequence diagram to specify a > behavior that is not implementable in actions. > > Conrad > > From: "Moore, Alan" To: "'Branislav Selic'" , conrad.bock@nist.gov Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 Date: Wed, 18 Feb 2004 14:08:57 -0000 X-Mailer: Internet Mail Service (5.5.2653.19) It probably is out of scope, but it's certainly a very interesting issue. I recall that in the SPT model of time, we had a TimedAction, whose start and end were marked by a TimedEvent. I always felt that this basic structure of Action and Event should be embedded in the UML, with TimedAction and TimedEvent as subclasses of these basic concepts. This structure would then be reflected in Interactions where EventOccurrences referenced Events and ExecutionOccurrences referenced Actions (including invocation actions, and hence their invoked behaviours). I don't think this covers everything - for example it may be that some events of interest do not relate to actions, although given the detailed nature of the Action model I'm not sure; behaviours may also be started as a result of Receiving a signal rather than a direct invocation, which is a more complex situation, with an initial send, some form of queuing and perhaps dispatching, and then a reception. This approach certainly doesn't aid in the construction of high-level abstractions of events and executions. However, it does meet my need to model scenarios at a detailed level of granularity and I have heard requests for the Action model to be integrated into Interactions and for there to be an Event concept in the UML 2 superstructure. Alan. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 17 February 2004 23:07 To: conrad.bock@nist.gov Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 This sounds like the create object action is overspecified. I know many systems -- particlarly distributed ones -- where the creation action is asynchronous and does not imply any blocking on the creator's part. Conrad's statement tells me that we cannot model such systems in UML, except perhaps by using trickery with surrogates, etc. I am beginning to believe that it is not a good idea to tie actions and messages closely at this stage of the game. It requires a substantial amount of thinking that is likely out of scope. Bran "Conrad Bock" 02/17/2004 05:26 PM Please respond to conrad.bock To: cc: Subject: RE: ,ia, issue 6077 > We should ask Conrad whether it is possible to define a > return-free create-object action. CreateObjectAction always returns a value and must always have a return pin. You don't need to have an object flow coming out of the pin, however, ie, you don't need to have any other action dependent on the returned value. OTOH, the containing activity cannot complete if the CreateObjectAction hasn't returned. Conrad To: "Moore, Alan" Cc: conrad.bock@nist.gov, uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 18 Feb 2004 09:34:44 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/18/2004 09:34:46, Serialize complete at 02/18/2004 09:34:46 I absolutely agree with Alan that this is very important, since it goes to the heart of the run-time semantics of UML. It was a lot easier to deal with in 1.4, where Action was rather amorphous and could therefore model almost anything. We now have the action semantics incorporated into the spec and those semantics appear to be overspecified for some systems that people want to model with UML. So, we now have a problem that we did not have in 1.4; although it did exist in 1.5 -- but no one paid attention to that version. Perhaps the solution is to use the ExecutionOccurrence for the more general stuff and provide the optional link to Action as I had suggested for the more precise modeling where it is needed? We would still have to revisit the action semantics, however. It may be too specific. Bran "Moore, Alan" 02/18/2004 09:08 AM To: Branislav Selic/Ottawa/IBM@IBMCA, conrad.bock@nist.gov cc: uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 It probably is out of scope, but it's certainly a very interesting issue. I recall that in the SPT model of time, we had a TimedAction, whose start and end were marked by a TimedEvent. I always felt that this basic structure of Action and Event should be embedded in the UML, with TimedAction and TimedEvent as subclasses of these basic concepts. This structure would then be reflected in Interactions where EventOccurrences referenced Events and ExecutionOccurrences referenced Actions (including invocation actions, and hence their invoked behaviours). I don't think this covers everything - for example it may be that some events of interest do not relate to actions, although given the detailed nature of the Action model I'm not sure; behaviours may also be started as a result of Receiving a signal rather than a direct invocation, which is a more complex situation, with an initial send, some form of queuing and perhaps dispatching, and then a reception. This approach certainly doesn't aid in the construction of high-level abstractions of events and executions. However, it does meet my need to model scenarios at a detailed level of granularity and I have heard requests for the Action model to be integrated into Interactions and for there to be an Event concept in the UML 2 superstructure. Alan. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 17 February 2004 23:07 To: conrad.bock@nist.gov Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,ia, issue 6077 This sounds like the create object action is overspecified. I know many systems -- particlarly distributed ones -- where the creation action is asynchronous and does not imply any blocking on the creator's part. Conrad's statement tells me that we cannot model such systems in UML, except perhaps by using trickery with surrogates, etc. I am beginning to believe that it is not a good idea to tie actions and messages closely at this stage of the game. It requires a substantial amount of thinking that is likely out of scope. Bran "Conrad Bock" 02/17/2004 05:26 PM Please respond to conrad.bock To: cc: Subject: RE: ,ia, issue 6077 > We should ask Conrad whether it is possible to define a > return-free create-object action. CreateObjectAction always returns a value and must always have a return pin. You don't need to have an object flow coming out of the pin, however, ie, you don't need to have any other action dependent on the returned value. OTOH, the containing activity cannot complete if the CreateObjectAction hasn't returned. Conrad Reply-To: From: "Conrad Bock" To: Subject: RE: ,ia, issue 6077 Date: Wed, 18 Feb 2004 10:53:37 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Bran, > This sounds like the create object action is overspecified. Or rather it doesn't provide a desired functionality. We could promote the isSynchronous attribute up to to actions in general, and add a constraint that asynchronous actions and their pins can't have outgoing edges. An issue can be filed on this, but I would rather have the FTF close on its deadline than address issues of functionality. The RTF opens immediately after the FTF closes. > I am beginning to believe that it is not a good idea to tie > actions and messages closely at this stage of the game. It > requires a substantial amount of thinking that is likely out of > scope. The alignment of the behavior models is a major undertaking. Conrad Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: ,ia, issue 6077 Date: Wed, 18 Feb 2004 10:56:42 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i1IFn0rh020262 Karl, > I would guess that the sequence diagram can show an action > handling a message without showing the return, a simple elision > will keep the diagram simple, and if an action is bound to > handle the message, the action can have a return that is created > by default by the modeling tool, without the modeler having to > think at that level of detail. I think this is the best way to handle it. If semantics is that there is a return, then it should at least be in the metamodel. Conrad From: "Moore, Alan" To: "'conrad.bock@nist.gov'" , uml2ftf Subject: RE: ,ia, issue 6077 Date: Wed, 18 Feb 2004 16:01:09 -0000 X-Mailer: Internet Mail Service (5.5.2653.19) I'm confused. Firstly, does Karl mean behaviour when he says action, given that there isn't (currently) an interaction fragment that relates to actions? Secondly, does Conrad mean the semantics of the action model, or of the interaction model? Alan. -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: 18 February 2004 15:57 To: uml2ftf Subject: RE: ,ia, issue 6077 Karl, > I would guess that the sequence diagram can show an action > handling a message without showing the return, a simple elision > will keep the diagram simple, and if an action is bound to > handle the message, the action can have a return that is created > by default by the modeling tool, without the modeler having to > think at that level of detail. I think this is the best way to handle it. If semantics is that there is a return, then it should at least be in the metamodel. Conrad Reply-To: From: "Conrad Bock" To: Subject: RE: ,ia, issue 6077 Date: Wed, 18 Feb 2004 11:03:11 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i1IFtTrh020445 Thomas, et al, > There were two "schools of thought" concerning the issue of > creation of objects: > i. an object is created fully initialized and satisfying all > constraints put upon it. > ii. an object is created completely uninitialized and any > initialization has to be programmed up in terms of the action semantics. And these aren't mutually exclusive. Another layer of actions can be defined that have the various forms of "full" funcitonality, which are different in every language. The current actions are the most primitive, allowing them to be composed into the many more complex ones that reflect the variety of existing languages. There was wide agreement about this in the action semantics submission team and thereafter, I didn't "drive" it. Conrad Subject: RE: ,ia, issue 6077 Date: Wed, 18 Feb 2004 12:57:13 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,ia, issue 6077 Thread-Index: AcP2OKOCHVCAd+5zTjCXqwWuTTb8lQADe0PW From: "Karl Frank" To: "Moore, Alan" , , "uml2ftf" X-OriginalArrivalTime: 18 Feb 2004 17:57:14.0592 (UTC) FILETIME=[A3FE0E00:01C3F648] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i1IHntrh022248 leaving open a strong possibility that I am the originator of the confusion, my understanding was that the interactions required messages on a diagram to be connected uniquely with actions in a complete behavioral model, as follows: 1. An EventOccurrence is a MessageEnd and has ExecutionOccurrences in the roles of startExec and finishExed (Figure 328 in Interactions chapter) 2. A startExec and finishExec on a lifeline should be associated with an operation defined for a classifier, which operation in turn can be asosciated with one behavior that defines what behaviors are performed when the operation handles a message, but Behavior is abstract, and Activity is the relevant concrete subclass. 3. Activities must come down to Actions in the end, as Actions are the atomic elements combined with control nodes and edges etc to define an Activity (and hence a behavior). - Karl -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wed 2/18/2004 11:01 AM To: 'conrad.bock@nist.gov'; uml2ftf Cc: Subject: RE: ,ia, issue 6077 I'm confused. Firstly, does Karl mean behaviour when he says action, given that there isn't (currently) an interaction fragment that relates to actions? Secondly, does Conrad mean the semantics of the action model, or of the interaction model? Alan. -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: 18 February 2004 15:57 To: uml2ftf Subject: RE: ,ia, issue 6077 Karl, > I would guess that the sequence diagram can show an action > handling a message without showing the return, a simple elision > will keep the diagram simple, and if an action is bound to > handle the message, the action can have a return that is created > by default by the modeling tool, without the modeler having to > think at that level of detail. I think this is the best way to handle it. If semantics is that there is a return, then it should at least be in the metamodel. Conrad Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: ,ia, issue 6077 Date: Wed, 18 Feb 2004 13:47:10 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i1IIdVrh022986 Karl, > 1. An EventOccurrence is a MessageEnd and has > ExecutionOccurrences in the roles of startExec and finishExed > (Figure 328 in Interactions chapter) > > 2. A startExec and finishExec on a lifeline should be associated > with an operation defined for a classifier, which operation in > turn can be asosciated with one behavior that defines what > behaviors are performed when the operation handles a message, > but Behavior is abstract, and Activity is the relevant concrete subclass. > > 3. Activities must come down to Actions in the end, as Actions > are the atomic elements combined with control nodes and edges > etc to define an Activity (and hence a behavior). This is helpful metamodel navigating, but I've lost track of the issue. A couple I noticed: - If ExecOcc points to Behavior, how does it handle operations? The dispatched behavior will depend on the instance receiving the message, which is not fully determined by the lifeline. - the multiplicity from ExecOcc to Behavior is missing. Conrad From: "Moore, Alan" To: "'Karl Frank'" , conrad.bock@nist.gov, uml2ftf Subject: RE: ,ia, issue 6077 Date: Thu, 19 Feb 2004 11:55:24 -0000 X-Mailer: Internet Mail Service (5.5.2653.19) Hi Karl, Just to be clear - you're not concerned with relating the message to the action that caused it, just the set of actions that are performed by the receiver of the message? Alan. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 18 February 2004 17:57 To: Moore, Alan; conrad.bock@nist.gov; uml2ftf Subject: RE: ,ia, issue 6077 leaving open a strong possibility that I am the originator of the confusion, my understanding was that the interactions required messages on a diagram to be connected uniquely with actions in a complete behavioral model, as follows: 1. An EventOccurrence is a MessageEnd and has ExecutionOccurrences in the roles of startExec and finishExed (Figure 328 in Interactions chapter) 2. A startExec and finishExec on a lifeline should be associated with an operation defined for a classifier, which operation in turn can be asosciated with one behavior that defines what behaviors are performed when the operation handles a message, but Behavior is abstract, and Activity is the relevant concrete subclass. 3. Activities must come down to Actions in the end, as Actions are the atomic elements combined with control nodes and edges etc to define an Activity (and hence a behavior). - Karl -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wed 2/18/2004 11:01 AM To: 'conrad.bock@nist.gov'; uml2ftf Cc: Subject: RE: ,ia, issue 6077 I'm confused. Firstly, does Karl mean behaviour when he says action, given that there isn't (currently) an interaction fragment that relates to actions? Secondly, does Conrad mean the semantics of the action model, or of the interaction model? Alan. -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: 18 February 2004 15:57 To: uml2ftf Subject: RE: ,ia, issue 6077 Karl, > I would guess that the sequence diagram can show an action > handling a message without showing the return, a simple elision > will keep the diagram simple, and if an action is bound to > handle the message, the action can have a return that is created > by default by the modeling tool, without the modeler having to > think at that level of detail. I think this is the best way to handle it. If semantics is that there is a return, then it should at least be in the metamodel. Conrad Subject: RE: ,ia, issue 6077 Date: Thu, 19 Feb 2004 07:50:07 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,ia, issue 6077 Thread-Index: AcP233ZFrWQENRybR4qY78scfQcGSwABcQwO From: "Karl Frank" To: "Moore, Alan" , , "uml2ftf" X-OriginalArrivalTime: 19 Feb 2004 12:50:08.0716 (UTC) FILETIME=[E7BA40C0:01C3F6E6] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i1JCoHre030627 Alan, thanks for the clarifying question. Yes, my concern is with actions performed by the receiver. My concern there began with the observation contributed by someone else on the thread, that a createObject action required a return. The reason for my concern is that I fear making the modeler attend to low-level programming details, especially when those details seem to be specific to assumptions of synchronous call semantics amongst collaborating objects. Such limitations would make a mockery of UML as a tool for business process modelers. Because of the loose linkage and broken-up presentation of the various Behavior chapters, I don't have a real grasp of how Operations and Behaviors (as Activities resolving to Actions) (whose connection is clear) on on side, relate to Interactions on the other side. I have been in the habit of thinking of the lifeline as identical with the object, and the connection between the object (which does not own methods, only slots for attribute values) that gets a message and its Classifier, which has the operations assigned to behaviors, to finally handle the message, is opaque (imho), but (again imho) must be there to make sense of an interaction diagram / message chart. - Karl -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Thu 2/19/2004 6:55 AM To: Karl Frank; conrad.bock@nist.gov; uml2ftf Cc: Subject: RE: ,ia, issue 6077 Hi Karl, Just to be clear - you're not concerned with relating the message to the action that caused it, just the set of actions that are performed by the receiver of the message? Alan. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 18 February 2004 17:57 To: Moore, Alan; conrad.bock@nist.gov; uml2ftf Subject: RE: ,ia, issue 6077 leaving open a strong possibility that I am the originator of the confusion, my understanding was that the interactions required messages on a diagram to be connected uniquely with actions in a complete behavioral model, as follows: 1. An EventOccurrence is a MessageEnd and has ExecutionOccurrences in the roles of startExec and finishExed (Figure 328 in Interactions chapter) 2. A startExec and finishExec on a lifeline should be associated with an operation defined for a classifier, which operation in turn can be asosciated with one behavior that defines what behaviors are performed when the operation handles a message, but Behavior is abstract, and Activity is the relevant concrete subclass. 3. Activities must come down to Actions in the end, as Actions are the atomic elements combined with control nodes and edges etc to define an Activity (and hence a behavior). - Karl -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wed 2/18/2004 11:01 AM To: 'conrad.bock@nist.gov'; uml2ftf Cc: Subject: RE: ,ia, issue 6077 I'm confused. Firstly, does Karl mean behaviour when he says action, given that there isn't (currently) an interaction fragment that relates to actions? Secondly, does Conrad mean the semantics of the action model, or of the interaction model? Alan. -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: 18 February 2004 15:57 To: uml2ftf Subject: RE: ,ia, issue 6077 Karl, > I would guess that the sequence diagram can show an action > handling a message without showing the return, a simple elision > will keep the diagram simple, and if an action is bound to > handle the message, the action can have a return that is created > by default by the modeling tool, without the modeler having to > think at that level of detail. I think this is the best way to handle it. If semantics is that there is a return, then it should at least be in the metamodel. Conrad Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: ,ia, issue 6077 Date: Thu, 19 Feb 2004 12:55:54 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i1JHusre003594 Karl, > The reason for my concern is that I fear making the modeler > attend to low-level programming details, especially when those > details seem to be specific to assumptions of synchronous call > semantics amongst collaborating objects. A couple clarifications: - The invocation actions (these invoke operations and send signals) can be asynchronous. - Creating an object is often not implemented as sending a message to an object, and in cases where it is, the above functionality for asynchronous invocation can be used. > Because of the loose linkage and broken-up presentation of the > various Behavior chapters, I don't have a real grasp of how > Operations and Behaviors (as Activities resolving to Actions) > (whose connection is clear) on on side, relate to Interactions > on the other side. I thought the models were independent. The UML 2 interaction model doesn't link messages to actions as it did in UML 1.x. You can link a message to a behavior, but that doesn't do much good in using the interaction as a view on the execution of methods that send multiple messages. Would be glad for correction on this. The above presumably would be good from the perspective of developing the models independently , but it also raises the issue of how they are kept consistent, or even how you can tell if they are. Conrad To: Cc: "uml2ftf" Subject: RE: ,ia, issue 6077 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 19 Feb 2004 13:53:57 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/19/2004 13:53:58, Serialize complete at 02/19/2004 13:53:58 Conrad, you said: > - Creating an object is often not implemented as sending a message to > an object, and in cases where it is, the above functionality for > asynchronous invocation can be used. This is nonsense: you cannot send a message to an object that has not been created yet. I think that the problem lies partly in dealing with object creation as a "message". What we really want is to show symbolically that some object A is the initiator of an action that creates object B. In the limited language of sequence charts, this is represented by an arrow that looks like a message. What that arrow really represents is the invocation of an object creation action. This action should be executable either synchronously or asynchronously to allow different ways of creating objects. Bran Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: ,ia, issue 6077 Date: Thu, 19 Feb 2004 15:05:00 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Bran, > > - Creating an object is often not implemented as sending a message to > > an object, and in cases where it is, the above functionality for > > asynchronous invocation can be used. > > This is nonsense: you cannot send a message to an object that > has not been created yet. Sure, but that isn't what I said. Creating objects is usually a primitive in the language (like the "new" statement), or done by sending a message to a factory. > I think that the problem lies partly > in dealing with object creation as a "message". What we really > want is to show symbolically that some object A is the initiator > of an action that creates object B. In the limited language of > sequence charts, this is represented by an arrow that looks like > a message. What that arrow really represents is the invocation > of an object creation action. Exactly, and even if there is a message involved (eg to a factory), then the receiving method will need a way to actually make the object, which is what CreateObjectAction is for. Conrad To: "Nikolai Mansurov" Cc: "Moore, Alan" , oysteinh@ifi.uio.no, uml2-superstructure-ftf@omg.org Subject: Re: ,ia, ExecutionOccurence discussion related to 6077 and 6972 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 16 Feb 2004 19:32:40 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/16/2004 19:32:43, Serialize complete at 02/16/2004 19:32:43 Nick, You raise very good points, but I am not sure that I agree with your interpretation of "unit". I don't think it was intended to imply anything but logical cohesion -- not some kind of indivisibility. However, I agree that it would be nice to solve some of the problems that your note describes. I am not sure, though, whether they fall within FTF scope or not. Some quick feedback on your cases: (a) linking an execution occurrence with a trigger sounds like a good idea, but it may come with some unwanted baggage such as the need to introduce the complex notion of causality (at the moment, there is no assumption of causality in interactions). (d) Is it not possible for this type of situation to occur if Db is a parallel machine? -- seems reasonable to me (also, remember that a lifeline could be decomposed) (f) I am not sure I understand this one: as far as I am concerned, there are two separate execution occurrences in this case, one corresponding to each alternative. They both have the same start event, but separate and mutually exclusive stop events. So, I am not sure how the problem of overlap can come up at all. (NB: This is a rather rushed reply, so I may have easily overlooked something fundamental). Bran "Nikolai Mansurov" 02/16/2004 02:26 PM To: Branislav Selic/Ottawa/IBM@IBMCA, , "Moore, Alan" cc: Subject: Re: ,ia, ExecutionOccurence discussion related to 6077 and 6972 Dear colleagues, Following-up the discussion on issue 6972 as well as the discussion regarding 6077, it occures to me that there is some inconsistency in the current specification regarding the nature of the ExecutionOccurence. In section 14.3.4 we say that "An ExecutionOccurence is an instantiation of a unit of behavior within the Lifeline". This is consistent with the meta-model, where an ExecutionOccurence is defined as a separate class (as a leaf subclass of InteractionFragment, and not as a CombinedFragment). Then we say, that "since the ExecutionOccurence will have some duration, it is represented by two EventOccurences, the start EventOccurence and the finish EventOccurence." However later we are saying, that "there may be other EventOccurences between [start and finish]". This seems to contradict the above concept of an ExecutionOccurence as a unit of behavior, and a leaf subclass of InteractionFragment. For example, on Figure 333 ExecutionOccurences for ob1, ob2 and ob3 are not quite units, because they cover some InteractionFragments, even a CombinedFragment in case of ob1. The way the meta-model is constructed, there is no logical relation between the InteractionFragments covered by the ExecutionOccurence symbol (i.e. between the ExecutionOccurence and those EventOccurences between start and stop). Instead, there is only a temporal relation. The following several questions can be raised: 1) Are there any missing semantic constraints on what events may or may not occur between start and finish? In particular, how start and finish are related to the InteractionOperands of the CombinedFragments? Is it propser nesting, or do we also allow non-nestable overlaps? 2) The second question was raised in 6972: can ExecutionOccurences themselves be nested ? And should they always be properly nested ? The way how ExecutionOccurence is defined today, there seems to be no constraint whatsoever to have non-nestable partially overlapping ExecutionOccurences: start1 start2 finish1 finish2 Following-up on the discussion on 6077: 3) How ExecutionOccurences are related to Calls and associated replies ? In particular, are replies always emanate from an ExecutionOccurence ? The illustrations in the specification suggest that. Is a synch Call always associated with an ExecutionOccurence ? Again the illustrations suggest that. Is ExecutionOccurence always triggered by a Call ? For example, can it be triggered by an asynch Signal ? I have created a small illustration that goes beyond Figure 333 in highlighting the above questions (attached). The above issues can be solved by - making ExecutionOccurence a subclass of the CombinedFragment, - associating the ExecutionOccurence with an optional trigger EventOccurence (call, signal, create or destroy) - associating replies with the ExecutionOccurence. This will disambiguate nesting of ExecutionOccurences and other InteractionFragments at the cost of disallowing situations a), e) and f) in the attached example. I suggest that the modified example is included in the spec. This can be a resolution for 6972, but it is related to the proposed resolutions on 6077 and few other issues. Any comments? Best regards, Nick #### operations2.doc has been removed from this note on February 16, 2004 by Branislav Selic OMG Issue No: 6077 Title: Message notation. Incorrect notation in Figure 333 p.414 Source: Ericsson (Dr. Oystein Haugen, oystein.haugen@ericsson.no oystein.haugen@ericsson.com Oystein.Haugen@eto.ericsson.se) Summary: Firstly not even the original (which is in Visio) has the appropriate dashed line of creation (I thought the pdf just had not quite got it right which happens often, but now I checked the original). Secondly the reply messages should have filled arrowheads (again judging from the description of the message notation). The FTF should reconsider the concrete syntax for create and reply and update the figures accordingly. Originally reported by David Fado through Jim Odell. Discussion: Bran.s text is red. Nick.s edits are blue. These edits address discussion on 6077, and the issues that were consolidated into 6077: 6260, 6263, 6463, and 6975 Allow both synchronous and asynchronous create and destroy messages, since both options seem to be supported by the action semantics (CreateObjectAction and DestroyObjectAction). Allow an optional return message from the create action. Use a dashed arrow to denote both object creation and destruction messages. For synchronous versions of these messages, use the filled arrowhead and a stick arrowhead for asynchronous versions. For returns, the style of arrowhead should match the style that was used for the creation/destruction arrowhead. Thus, the return from an asynchronous call action would be a dashed line with a stick arrowhead, whereas a return from a synchronous call action would have a filled arrowhead. In fact, I suggest that the above convention be applied consistently for all return messages. (This is necessary because we support asynchronous calls in the action semantics.) Return messages do not have a signature. The arguments of the create message corresponds to the attributes and parameters of the Classifier, represented by the created (receiving) Lifeline. Create message may have a signature, identifying the Classifier being created. This is useful in case of a lost create message, when the Lifeline head is not available. Parameters of the return message correspond to the return value and the return parameters of the corresponding Operation synchReturn and asynchReturn are added to messageSort This requires the following changes to the spec: Pg.407, fig. 328: add .synchCreate., .asynchCreate., .synchDestroy. , and .AsynchDestroy., as well as .synchReturn., and .asynchReturn. to the list of the MessageSort enumeration item. Pg.407, fig. 328: remove .synchSignal. from the list of the MessageSort enumeration item (because there is no corresponding action in the action semantics) Pg. 414, fig. 333: replace the figure with the following diagram: Pg. 428, add: synchCreate, asynchCreate, synchDestroy, asynchDestroy, synchReturn, asynchReturn at the end of the list of message sorts in the description of the messageSort:MessageSort attribute in the Attributes section of item 14.3.14 Pg. 428 remove synchSignal from the list of message sorts in the description of the messageSort:MessageSort attribute in the Attributes section of item 14.3.14 Pg. 429 change constraint [2] From [2] The signature must either refer an Operation (in which case messageSoft is either synchCall or asynchCall) or a Signal (in which case messageSort is either synchSignal or asynchSignal). The name of the NamedElement referenced by signature must be the same as that of the Message. Into the following: [2] The signature must either refer to an Operation (in which case messageSoft is either synchCall or asynchCall) or a Signal (in which case messageSort is asynchSignal) or an identification of the Classifier being created (in which case messageSort is either synchCreate or asynchCreate). The name of the NamedElement referenced by signature must be the same as that of the Message. Pg. 429 add the following constraint: [9] Return messages must not have a signature Pg. 429 add the following constraint: [10] The arguments of the Create message (in which case the messageSort is either synchCreate or asynchCreate) must correspond to the attributes of the created (receiving) Lifeline or parameters owned by it. Pg. 429 add the following constraint: [11] The arguments of the return message must correspond to the return value and the return parameters of the Operation. Pg. 429 add the following before the first paragraph of the .Semantics. section: Assume the sendEvent and receiveEvent represent the event occurrences at the ends of the Message, corresponding to the messageSort. Pg. 429 replace the following paragraph in the .Semantics. section: A Message reflects either an Operation call and start of execution . or a sending or reception of a Signal With the following text: A Message reflects any of the following: o Operation call and start of execution (sendEvent=call; receiveEvent=start), o Object creation action and the creation of the object (sendEvent=create;receiveEvent=created), o Object destruction and termination of execution (sendEvent=destroy;receiveEvent=destroyed), o a sending and receiving of a Signal (sendEvent=send;receiveEvent=receive), o Return from an Operation and termination of execution (sendEvent=return and finish; receiveEvent= endcall), o Return from object creation (sendEvent=created; receiveEvent= endcreate) Pg. 429 add the following paragraphs to the end of the .Semantics. section: If the Message represents a CreateObjectAction, it may be either a synchCreate or an asynchCreate MessageSort. There may be a return message from the called (receiving) Lifeline to the calling (sending) Lifeline. If the Message represents a DestroyObjectAction, then it may be either an asynchDestroy or synchDestroy MessageSort. A return message may exist from the called Lifeline to the calling Lifeline if it is a synchDestroy message sort. When a Message represents a CreateObjectAction that has arguments the rule for arguments is the same as for Operation calls or Signal sends (depending on whether the call is synchronous or asynchronous). Pg. 430 replace the line: Object creation Message has a dashed line with an open arrow. With the following text: An Object creation Message is represented by a dashed line from the creating object.s Lifeline and terminating on the Lifeline .head. (rectangle) symbol corresponding to the object that is created by the action. The corresponding return Message is represented by a dashed line emanating from the Lifeline rectangle and terminating on the creation object.s Lifeline. If the message sort is a synchCreate, then the arrowhead will be filled in both cases. If the message sort is asynchCreate, then the stick arrowhead is used in both cases. An Object destruction Message is represented by a dashed line emanating from the destroying object.s Lifeline and terminating on the Stop symbol on the Lifeline of the object that is destroyed. If the message sort is synchDestroy, then the arrowhead of the destruction message is filled and there is a corresponding reply message with a filled arrowhead emanating from the Stop symbol of the Lifeline of the object that is being destroyed back to the Lifeline of the destroying object. If the message sort is an asynchDestroy, a stick arrowhead is used and no return message exists. Pg. 430 replace the textual grammar: messageident::= [attribute=] signal-or-operation-name [ (arguments) ] [: return-value] | .*. arguments::=argument [, arguments] argument::= [parameter-name=] argument-value | attribute=out-parameter-name [ : argument-value ] | - with the following: messageident::= signal-or-operation-or-classifier-name [ (arguments) ] | .*. | return-values arguments::=argument [, arguments] argument::= [parameter-name=] argument-value | - return-values::=return-value [, return-values ] return-value::=attribute=out-parameter-name : attribute-value | attribute = attribute-value Pg. 430 replace the sentence: Return-value and attribute assignment are used only for reply messages. With the following: Return-value and attribute assignment are used only for return messages. Pg. 430 replace the sentence: We also see a Message that represents the creation of an object. With the sentence: We also see a Message that creates an object synchronously and a message that destroys an object asynchronously. Pg. 430, replace second example: v=mymsg(16,variab):96 // this is a reply message carrying the return value 96 assigning it to v With the following: v=96 // this is a reply message carrying the return value 96 assigning it to v Pg. 438, table 15 Notation entry for Message: Add a dashed line with a filled arrowhead below the one with the stick arrowhead. Pg. 438, table 15 Notation entry for Message: Add a new entry for create message (dashed line with filled arrowhead terminating at the Lifeline .head.) and the following description text: Create message terminates at the .head. symbol of the created (receiving) Lifeline. There are synchronous and asynchronous create messages. Here we show a synchronous create message. Pg. 438, table 15 Notation entry for Message: Add a new entry for a return message from create (dashed line with filled arrowhead emanating from the Lifeline .head.) and the following description text: Create message may have an optional return message that emanates from the .head. symbol of the created (receiving) Lifeline. There are synchronous and asynchronous return message for create, which should match the sort of the corresponding create message. Here we show an asynchronous create message, accompanied by a return message. Pg. 438, table 15 Notation entry for Message: Add a new entry for a lost asynchronous create message (dashed line with open arrowhead emanating from a Lifeline, ending in a filled circle, with the identification of the Lifeline that was intended to be created) and the following description text: Create message may be lost. Here we show a lost asynchronous create message. Note that there is a need to specify which Lifeline was intended to be created by adding a messageident to the create message. Pg. 438, table 15 Notation entry for Message: Add a new entry for a found synchronous destroy message (dashed line with open arrowhead emanating from a filled circle and terminating at the stop symbol on the destroyed (receiving) Lifeline) and the following description text: Synchronous and asynchronous destroy messages may be found. Here we show a found synchronous destroy message. Pg. 438, table 15 Reference entry for Message, replace the sentence: Here we show an asynchronous message, a call, and a reply. With the sentence: Here we show an asynchronous message, a synchronous message, a return message to an asynchronous operation call (or an asynchronous create object or destroy object message), and a return message to a synchronous operation call or object creation message. Disposition: Resolved To: "Nikolai Mansurov" Cc: "Branislav Selic" , uml2-superstructure-ftf@omg.org Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Wed, 31 Mar 2004 11:49:01 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 03/31/2004 11:49:04 NOTATION FOR CALL/CREATION AND RETURNS ON SEQUENCE DIAGRAMS I think the proposal for changing call/return/creation notation is unnecessary and it also includes a mistaken assumption. I am sorry I missed the extensive discussions in February but this is now up for comment so here it is: 1. There is no such thing as a return from an asynchronous call. By definition, an asynchronous call is a one-way message that does not return! Therefore all the discussion about adding new return types and distinguishing return arrows is mistaken. The only kind of return is a return from a synrchonous call. 2. It would be extremely confusing to use dashed lines for both creation/destruction and for returns. Note that you don't actually NEED the dashed lines for either, because they are clear enough on close inspection (creation goes to a head box, detruction to an X, and return comes from the bottom of an activation rectangle on the lifeline), so the point of the dashed lines is to provide some visual clarity, so let's not throw out their main value. The proposal makes unnecessary changes to the specification and to the UML1 notation, for little gain. I would suggest the following recommendations based on the foregoing facts: Adopt the following notation, which is close to the notation in UML1 and in the UML2 diagrams (perhaps accidentally, but maybe not badly): a. A synchronous call is shown by a solid line with a filled arrowhead. The filled arrowhead carries the connotation that "something follows", also that the call itself has addition information (namely the hidden return control information that is implicitly part of a synchronous call). A synchronous call with go to the top of an activation rectangle on the lifeline, in the common case in which the target object is not continuously active, because it activates the object. b. An asynchronous call is shown by a solid line with a stick arrowhead. The stick arrowhead is also used for any one-way message, so this fits nicely. An aschronous call will usually go to the middle of an activation rectangle for a continuously active object, although it could also start one, and in the case of a data object it may not show any activation (I suppose in principle there might be a little one to store data, but I would skip it if the only purpose is to store values). c. A return (note that ALL returns are in response to synchronous calls) is shown by a dashed line with a stick arrowhead. The arrow will usually leave the bottom of an activation rectangle, although there may be cases in which the called object continues after returning (but it can't return again after that). The reason for these choices is: - dashed line to show that the return is an IMPLICIT message in response to completing execution of a procedure, whereas all other messages (including calls, signals, and creation/destruction) are explicit actions. In fact, return messages can be suppressed with no loss of information (although a considerable loss in clarity, in my view), so the solid lines indicate the messages that need to be shown. - Stick arrowhead to show a one-way message with no addition hidden information or future followup. This reserves the filled arrowhead for synchonous calls, all of which are paired with future returns. We are already showing the returns as dashed lines, so there is no need to double up on the graphic markers, and doing so dilutes the point of the filled arrowhead on the call, which is that it implies future consequences. Also there is no need to distinguish synchronous and asynronous returns, because there is no such thing as an asynchrous return. d. Creation and destruction are shown as solid lines with stick or filled arrowheads depending on whether they are asynchronous or synronous messages/calls. This suggestion was already made in issue 6463, and it should have been taken. - There is no need for a special notation for creation/destruction. As calls, they are just ordinary calls, so why mess up the flow-of-control symbolism? The notation should show the distinction in message/control flow, not the different RESULTS of the messages (if you try to notation the results, you would need a lot of other distinctions). In any case, creation is clear enough: The arrow goes right to the object head box, rather that the lifeline. Couldn't be any clearer, so why confuse the issue with a separate kind of call, which it isn't? The same thing for destruction: it goes right to a big fat X that is hard to overlook. So basically the ONLY change would need to be changing the text for creation/destruction actions to say that they are ordinary solid lines because they are ordinary calls. The diagrams are already correct. This also accords with the notation in UML1. I don't really see why a change was proposed when it isn't needed and it gratuitously changes past notation with no gain. This would be a bad idea for an FTF. e. Allow returns for synchronous creation. The simplest convention is to point the call at the top of the object head box and take the return arrow from the bottom of the head box, f. Clarify the syntax on returns. This probably needs to accommodate both position notation for values (WITHOUT parameter names, which is the most common case) of the form "value, ..." as well as a "parameter=value,..." form. Clarify if you are allowed to assign values to variables/attributes of the target object/procedure, but if you do that, make sure to do it for both call parameters and return parameters, not just return parameters. Assignment isn't part of the message but it is part of its handling by the recipient, so you could go either way on showing it. - Jim Rumbaugh "Nikolai Mansurov" 03/31/2004 07:42 AM To "Branislav Selic" , cc Subject RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 Hello all, Please find attached proposed resolutions for the block of issues on the notation for create/destroy/return, consolidated into the single issue 6077. All other issues are closed as duplicates to 6077. The proposed resolution originally came from Bran, and was extensively discussed in the middle of February. I volonteered to incorporate the corresponding changes. I have also added the resolution for related issue 6463. In the text of the resolution my changes to the original text are made distinct. Best regards, Nick Reply-To: From: "Conrad Bock" To: , "'uml2ftf'" Subject: RE: Problems with Information flow resolutions, 6351 (InformationFlow realization) Date: Sun, 9 May 2004 21:03:08 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Philippe, > The reason why is that I am missing Use Cases. What the metamodel > addresses corresponds to use cases that I have encountered. I'll provide some. > Connectors was intended to be adressed, but the IF metamodel did not > follow the connector's metamodel evolutions. Activity edges and > messages are two other important cases that you mention. So > specicially adressing these cases is a good option. What is the use case for connectors? > Whidely opening the Information flow realization ability shall make > sense both notationnaly and semantically for each case. Where are the cases laid out for the current functionality? Conrad X-Sender: siegel@192.67.184.64 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 10 May 2004 11:14:32 -0400 To: "Nikolai Mansurov" , "James E Rumbaugh" From: Jon Siegel Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 Cc: "Branislav Selic" , Hi Everyone -- About returns from asynchronous calls -- At 07:39 PM 5/8/04, James E Rumbaugh wrote: >1. There is no such thing as a return from an asynchronous call. By definition, an asynchronous call is a one-way message that does not return! Therefore all the discussion about adding new return types and distinguishing return arrows is mistaken. The only kind of return is a return from a synrchonous call. CORBA defines asynchronous calls that return control to the client application immediately and return values via either callback or polling. Ch 22 of CORBA 3.0.3 covers the spec in detail; section 22.4 gives a good introduction. Calls that do not return are declared ONEWAY, a different beast from Asynchronous. For info on ONEWAY, see section 3.13.1. Hope this helps. Jon Siegel OMG ================================================================== Dr. Jon Siegel email: siegel@omg.org Vice President, Technology Transfer http://www.omg.org Object Management Group First Needham Place Phone: +1 781-444-0404 250 First Avenue, Suite 100 Fax: +1 781-444-0320 Needham, MA 02494 USA PGP Signature: 6882 D54B 3F3A 13CA 8098 1B02 D6B8 4FBD ================================================================== Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 Date: Mon, 10 May 2004 09:53:32 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 Thread-Index: AcQ2obRn93ZfkrmmTnGakXSKXRVxgQADMsvw From: "Pidcock, Woody" To: "Jon Siegel" , "Nikolai Mansurov" , "James E Rumbaugh" Cc: "Branislav Selic" , X-OriginalArrivalTime: 10 May 2004 16:53:33.0146 (UTC) FILETIME=[541B2BA0:01C436AF] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4AGul8k032082 Boeing had a requirement for CORBA to support asynchronous calls with a response. Boeing has long-running, compound transactions that cannot leave the caller in a wait state waiting for a synchronous response. However, if the asynchronous response to one of the transactions in a compound transaction indicates a failure of the transaction, then all the other transactions in the compound transaction need to be backed out. Boeing implemented custom code to do this type of two-phase commit since it wasn't initially supported in CORBA. -Woody -----Original Message----- From: Jon Siegel [mailto:siegel@omg.org] Sent: Monday, May 10, 2004 8:15 AM To: Nikolai Mansurov; James E Rumbaugh Cc: Branislav Selic; uml2-superstructure-ftf@omg.org Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 Hi Everyone -- About returns from asynchronous calls -- At 07:39 PM 5/8/04, James E Rumbaugh wrote: >1. There is no such thing as a return from an asynchronous call. By >definition, an asynchronous call is a one-way message that does not return! Therefore all the discussion about adding new return types and distinguishing return arrows is mistaken. The only kind of return is a return from a synrchonous call. CORBA defines asynchronous calls that return control to the client application immediately and return values via either callback or polling. Ch 22 of CORBA 3.0.3 covers the spec in detail; section 22.4 gives a good introduction. Calls that do not return are declared ONEWAY, a different beast from Asynchronous. For info on ONEWAY, see section 3.13.1. Hope this helps. Jon Siegel OMG ================================================================== Dr. Jon Siegel email: siegel@omg.org Vice President, Technology Transfer http://www.omg.org Object Management Group First Needham Place Phone: +1 781-444-0404 250 First Avenue, Suite 100 Fax: +1 781-444-0320 Needham, MA 02494 USA PGP Signature: 6882 D54B 3F3A 13CA 8098 1B02 D6B8 4FBD ================================================================== From: "Thomas Weigert" To: "Pidcock, Woody" , "Jon Siegel" , "Nikolai Mansurov" , "James E Rumbaugh" Cc: "Branislav Selic" , Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 Date: Mon, 10 May 2004 13:19:10 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) The construct explained by Jon below (asynchronous calls that return control to the client application immediately and return values via either callback or polling) can be implemented using the model elements of UML 2. Transaction processing would have to be defined in a profile; it certainly is not part of the generic UML applicable to all domains. Th. > -----Original Message----- > From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] > Sent: Monday, May 10, 2004 11:54 AM > To: Jon Siegel; Nikolai Mansurov; James E Rumbaugh > Cc: Branislav Selic; uml2-superstructure-ftf@omg.org > Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and > 6975 > > > Boeing had a requirement for CORBA to support asynchronous calls > with a response. Boeing has long-running, compound transactions > that cannot leave the caller in a wait state waiting for a > synchronous response. However, if the asynchronous response to > one of the transactions in a compound transaction indicates a > failure of the transaction, then all the other transactions in > the compound transaction need to be backed out. Boeing > implemented custom code to do this type of two-phase commit since > it wasn't initially supported in CORBA. > > -Woody > > -----Original Message----- > From: Jon Siegel [mailto:siegel@omg.org] > Sent: Monday, May 10, 2004 8:15 AM > To: Nikolai Mansurov; James E Rumbaugh > Cc: Branislav Selic; uml2-superstructure-ftf@omg.org > Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, > 6463, and 6975 > > > Hi Everyone -- > > About returns from asynchronous calls -- > > At 07:39 PM 5/8/04, James E Rumbaugh wrote: > >1. There is no such thing as a return from an asynchronous call. By > >definition, an asynchronous call is a one-way message that does > not return! Therefore all the discussion about adding new return > types and distinguishing return arrows is mistaken. The only > kind of return is a return from a synrchonous call. > CORBA defines asynchronous calls that return control to the > client application immediately and return values via either > callback or polling. Ch 22 of CORBA 3.0.3 covers the spec in > detail; section 22.4 gives a good introduction. > > Calls that do not return are declared ONEWAY, a different beast > from Asynchronous. For info on ONEWAY, see section 3.13.1. > > Hope this helps. > > Jon Siegel > OMG > > > > ================================================================== > Dr. Jon Siegel email: siegel@omg.org > Vice President, Technology Transfer http://www.omg.org > Object Management Group > First Needham Place Phone: +1 781-444-0404 > 250 First Avenue, Suite 100 Fax: +1 781-444-0320 > Needham, MA 02494 USA > PGP Signature: 6882 D54B 3F3A 13CA 8098 1B02 D6B8 4FBD > ================================================================== > > To: "Pidcock, Woody" Cc: "Branislav Selic" , "Nikolai Mansurov" , "Jon Siegel" , uml2-superstructure-ftf@omg.org Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Mon, 10 May 2004 11:29:08 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 05/10/2004 12:29:14, Serialize complete at 05/10/2004 12:29:14 There may be a difference in terminology from CORBA, but in UML a call in which the caller proceeds immediately after issuing the call has been called "asynchronous" and a call in which the caller waits until the invoked procedure completes and returns control has been called "synchronous". In the current semantics of UML, it is not possible for an "asynchronous" call to return a value. So, Nick, you should NOT add a notation for a return arrow from an asynchronous call, because it does not currently exist. Your answer to me totally missed the point. It is incompatible with the current semantics. Now, maybe someone wants to add a new kind of call, called it a "deferred response" call, in which the caller proceeds after the call, but some point in the future waits for a return. In that case, you would need to distinguish a third kind of call (it's NOT asynchonous nor synchonous), which requires a third notation for the call, but a return arrow at the future point would make sense using the same notation. I actually don't think you need this third approach. It is just as easy to model it by forking before making the original call. One fork makes the call and then waits for the response. The other fork does whatever you would have done after making the call and then just dies. It model the situation very cleanly, more cleanly than the deferred response, without any additional constructs. The CORBA approach does not seem to fit this paradigm. It is a plain asynchonous (one-way, if you wish) call in which the called procedure later calls the original object. A callback is easy to model and doesn't require anything new. It's an asynchonous call, followed later by either a synchronous or asynchronous call in the reverse direction. Similarly, polling is just an original asynchronous call, followed by a later synchronous call (the poll) in the original direction. In Woody's case, we need a transaction mechanism with rollback. This is an important construct, but not something that basic UML provides. It is a feature for a more advanced specification that includes all kinds of transaction capabilities, not just deferred responses. The need for rollback puts it way out of scope for UML. I think that we can do everything we need in ordinary UML with the synchronous and asynchronous (our use of the term, not CORBA's) calls without expanding their definitions. I think people are getting modeling constructs mixed up with programming languages. It is quite easy to model the - Jim Rumbaugh "Pidcock, Woody" 05/10/2004 09:53 AM To "Jon Siegel" , "Nikolai Mansurov" , James E Rumbaugh/Cupertino/IBM@IBMUS cc "Branislav Selic" , Subject RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 Boeing had a requirement for CORBA to support asynchronous calls with a response. Boeing has long-running, compound transactions that cannot leave the caller in a wait state waiting for a synchronous response. However, if the asynchronous response to one of the transactions in a compound transaction indicates a failure of the transaction, then all the other transactions in the compound transaction need to be backed out. Boeing implemented custom code to do this type of two-phase commit since it wasn't initially supported in CORBA. -Woody -----Original Message----- From: Jon Siegel [mailto:siegel@omg.org] Sent: Monday, May 10, 2004 8:15 AM To: Nikolai Mansurov; James E Rumbaugh Cc: Branislav Selic; uml2-superstructure-ftf@omg.org Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 Hi Everyone -- About returns from asynchronous calls -- At 07:39 PM 5/8/04, James E Rumbaugh wrote: >1. There is no such thing as a return from an asynchronous call. By >definition, an asynchronous call is a one-way message that does not return! Therefore all the discussion about adding new return types and distinguishing return arrows is mistaken. The only kind of return is a return from a synrchonous call. CORBA defines asynchronous calls that return control to the client application immediately and return values via either callback or polling. Ch 22 of CORBA 3.0.3 covers the spec in detail; section 22.4 gives a good introduction. Calls that do not return are declared ONEWAY, a different beast from Asynchronous. For info on ONEWAY, see section 3.13.1. Hope this helps. Jon Siegel OMG ================================================================== Dr. Jon Siegel email: siegel@omg.org Vice President, Technology Transfer http://www.omg.org Object Management Group First Needham Place Phone: +1 781-444-0404 250 First Avenue, Suite 100 Fax: +1 781-444-0320 Needham, MA 02494 USA PGP Signature: 6882 D54B 3F3A 13CA 8098 1B02 D6B8 4FBD ================================================================== Date: Mon, 10 May 2004 14:45:46 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard SGBU/MSO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: James E Rumbaugh Cc: "Pidcock, Woody" , Branislav Selic , Nikolai Mansurov , Jon Siegel , uml2-superstructure-ftf@omg.org Subject: Re: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 I generally agree with Jim's position. It is unfortunate that CORBA chose to use the term "asynchronous" to refer to something that is often referred to in literature as "deferred synchronous" or similar. I believe all of the three/four rendezvous models in CORBA asynch messaging spec (local dispatch, remote dispatch and remote invocation) + pure oneway can be modeled using the existing constructs in UML2, albeit with some pain for the rendezvous models in the asynch messaging spec. Jishnu. James E Rumbaugh wrote: There may be a difference in terminology from CORBA, but in UML a call in which the caller proceeds immediately after issuing the call has been called "asynchronous" and a call in which the caller waits until the invoked procedure completes and returns control has been called "synchronous". In the current semantics of UML, it is not possible for an "asynchronous" call to return a value. So, Nick, you should NOT add a notation for a return arrow from an asynchronous call, because it does not currently exist. Your answer to me totally missed the point. It is incompatible with the current semantics. Now, maybe someone wants to add a new kind of call, called it a "deferred response" call, in which the caller proceeds after the call, but some point in the future waits for a return. In that case, you would need to distinguish a third kind of call (it's NOT asynchonous nor synchonous), which requires a third notation for the call, but a return arrow at the future point would make sense using the same notation. I actually don't think you need this third approach. It is just as easy to model it by forking before making the original call. One fork makes the call and then waits for the response. The other fork does whatever you would have done after making the call and then just dies. It model the situation very cleanly, more cleanly than the deferred response, without any additional constructs. The CORBA approach does not seem to fit this paradigm. It is a plain asynchonous (one-way, if you wish) call in which the called procedure later calls the original object. A callback is easy to model and doesn't require anything new. It's an asynchonous call, followed later by either a synchronous or asynchronous call in the reverse direction. Similarly, polling is just an original asynchronous call, followed by a later synchronous call (the poll) in the original direction. In Woody's case, we need a transaction mechanism with rollback. This is an important construct, but not something that basic UML provides. It is a feature for a more advanced specification that includes all kinds of transaction capabilities, not just deferred responses. The need for rollback puts it way out of scope for UML. I think that we can do everything we need in ordinary UML with the synchronous and asynchronous (our use of the term, not CORBA's) calls without expanding their definitions. I think people are getting modeling constructs mixed up with programming languages. It is quite easy to model the - Jim Rumbaugh *"Pidcock, Woody" * 05/10/2004 09:53 AM To "Jon Siegel" , "Nikolai Mansurov" , James E Rumbaugh/Cupertino/IBM@IBMUS cc "Branislav Selic" , Subject RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 Boeing had a requirement for CORBA to support asynchronous calls with a response. Boeing has long-running, compound transactions that cannot leave the caller in a wait state waiting for a synchronous response. However, if the asynchronous response to one of the transactions in a compound transaction indicates a failure of the transaction, then all the other transactions in the compound transaction need to be backed out. Boeing implemented custom code to do this type of two-phase commit since it wasn't initially supported in CORBA. -Woody -----Original Message----- From: Jon Siegel [mailto:siegel@omg.org] Sent: Monday, May 10, 2004 8:15 AM To: Nikolai Mansurov; James E Rumbaugh Cc: Branislav Selic; uml2-superstructure-ftf@omg.org Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 Hi Everyone -- About returns from asynchronous calls -- At 07:39 PM 5/8/04, James E Rumbaugh wrote: >1. There is no such thing as a return from an asynchronous call. By >definition, an asynchronous call is a one-way message that does not return! Therefore all the discussion about adding new return types and distinguishing return arrows is mistaken. The only kind of return is a return from a synrchonous call. CORBA defines asynchronous calls that return control to the client application immediately and return values via either callback or polling. Ch 22 of CORBA 3.0.3 covers the spec in detail; section 22.4 gives a good introduction. Calls that do not return are declared ONEWAY, a different beast from Asynchronous. For info on ONEWAY, see section 3.13.1. Hope this helps. Jon Siegel OMG ================================================================== Dr. Jon Siegel email: siegel@omg.org Vice President, Technology Transfer http://www.omg.org Object Management Group First Needham Place Phone: +1 781-444-0404 250 First Avenue, Suite 100 Fax: +1 781-444-0320 Needham, MA 02494 USA PGP Signature: 6882 D54B 3F3A 13CA 8098 1B02 D6B8 4FBD ================================================================== To: "Nikolai Mansurov" Cc: "Branislav Selic" , uml2-superstructure-ftf@omg.org Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Mon, 10 May 2004 14:01:37 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 05/10/2004 15:01:42, Serialize complete at 05/10/2004 15:01:42 Comments from Jim Rumbaugh: "Nikolai Mansurov" wrote on 05/08/2004 04:39:44 PM: > Dear Jim, > > With sincere appologies for a long overdue response .. > [picture of Nick looking apologetic from under a pile of paperwork] > please find my comments below, and an updated resolution to 6077 > (with these comments implemented) attached. > -----Original Message----- > From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] > Sent: Wednesday, March 31, 2004 1:49 PM > To: Nikolai Mansurov > Cc: Branislav Selic; uml2-superstructure-ftf@omg.org > Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 > > NOTATION FOR CALL/CREATION AND RETURNS ON SEQUENCE DIAGRAMS > > I think the proposal for changing call/return/creation notation is > unnecessary and it also includes a mistaken assumption. I am sorry > I missed the extensive discussions in February but this is now up > for comment so here it is: > > 1. There is no such thing as a return from an asynchronous call. By > definition, an asynchronous call is a one-way message that does not > return! Therefore all the discussion about adding new return types > and distinguishing return arrows is mistaken. The only kind of > return is a return from a synrchonous call. > [Nikolai Mansurov] Matching the style of arrowhead for operation > call and reply has been identified as an issue and the resolution is > attempting to solve it. This goes back to the discussion in February > (after half an hour digging into the backtrail of emails). > Therefore - the meaning of a "return from an asynchronous call" is > simply an "asynchronous return message sent as the result of > handling an asynchronous operation call". The primary intention here > is to be able to have a RETURN from any operation call; the > secondary one is to match the sort of return with the sort of the call. > I suggest to keep this part of the resolution, i.e. no change. Bad idea. If you make an asynchronous call, the receiver can send any kind of asynchronous message it wants at a later time. There might be zero replies, or one reply, or multiple replies, and they might be of any type. They are not constrained by the original call. It is arbitrary to identify a subsequent asynchronous message as a "return" of the first message. That concept makes sense in the synchronous case, because the caller always waits, there must always be exactly one return message, and the type of the return message is specified by the operation that was called. None of these apply to the example you cite. There is no reason to apply the "return" concept in the case of a subsequent asynchronous message following an asynchronous call, and plenty of reason not to do it. A return from a synchronous call has strong semantics. The proposal to show "returns" from asynchronous calls can mean practically anything, depending on what the receiver chooses to do, so there is no advantage to making it a UML concept. > > 2. It would be extremely confusing to use dashed lines for both > creation/destruction and for returns. Note that you don't actually > NEED the dashed lines for either, because they are clear enough on > close inspection (creation goes to a head box, detruction to an X, > and return comes from the bottom of an activation rectangle on the > lifeline), so the point of the dashed lines is to provide some > visual clarity, so let's not throw out their main value. > > [Nikolai Mansurov] I agree with the idea to use normal lines for > create and destroy. However, I'd suggest to keep dashed lines for > returns. This would help handling the issue 5433 on exception > handling, since both returns and exceptions are instances of > "reverse flow of communication", while messages (including create > and destroy) are forms of "direct flow of communication". > Yes, use dashed lines for returns and exceptions, not for create/destroy. > > The proposal makes unnecessary changes to the specification and to > the UML1 notation, for little gain. > Actually, the intention of the proposed resolution was to keep the > notation unchanged as much as possible, at least compared to the > adopted draft. Your proposed change does involve the change in the > notation, which may raise objections from vendors. > > I would suggest the following recommendations based on the foregoing facts: > > Adopt the following notation, which is close to the notation in UML1 > and in the UML2 diagrams (perhaps accidentally, but maybe not badly): > > a. A synchronous call is shown by a solid line with a filled > arrowhead. The filled arrowhead carries the connotation that > "something follows", also that the call itself has addition > information (namely the hidden return control information that is > implicitly part of a synchronous call). A synchronous call with go > to the top of an activation rectangle on the lifeline, in the common > case in which the target object is not continuously active, because > it activates the object. > > [Nikolai Mansurov] This is in the proposed resolution, except there > is no requirement for the call to go to the top of the activation > rectangle. Just to be clear - there is no meta-model association > between the call and the ExecutionOccurence either. There is > interest to specify e.g. delays between the call and the activation. Certainly a call cannot go to the middle of an activation rectangle, because then you are calling an existing execution, which doesn't make sense. I suppose there might be some delay in starting an execution shown by a gap, provided the next activation is the result of the call. If you can't tell which activation goes with which call, there would be confusion. > > c. A return (note that ALL returns are in response to synchronous > calls) is shown by a dashed line with a stick arrowhead. The arrow > will usually leave the bottom of an activation rectangle, although > there may be cases in which the called object continues after > returning (but it can't return again after that). The reason for > these choices is: > > [Nikolai Mansurov] This is in the proposed resolution, except there > is no restriction on the absence of returns from asynchronous calls. > In case of a return from an asynchronous call, the line is dashed > and the arrowhead is filled, matching the arrowhead of the call. Same comment as before. I don't think it makes sense to identify a subsequest message in the reverse direction as a "return" message, simply because it happens to follow an asynchronous call. It's just another asynchronous message. No need to use a special notation. And what is the nonsense about different kinds of arrowheads on a return? That's a real bad idea that leads to incompatibility with previous notation. The return itself is always one-way, so need need to have different kinds of arrowheads. > > - Stick arrowhead to show a one-way message with no addition hidden > information or future followup. This reserves the filled arrowhead > for synchonous calls, all of which are paired with future returns. > We are already showing the returns as dashed lines, so there is no > need to double up on the graphic markers, and doing so dilutes the > point of the filled arrowhead on the call, which is that it implies > future consequences. Also there is no need to distinguish > synchronous and asynronous returns, because there is no such thing > as an asynchrous return. > > [Nikolai Mansurov] See above, the intention of the proposed > resolution is to match the sort of the return with the sort of the call. Terrible idea which I would strongly oppose. It makes an ordinary return look more complicated. In any case, why is there any need to change the notatation for return even if it could match more than one kind of call (which I oppose)? In all cases, it matches the previous call, so don't add complexity for no good reason. In addition, the return ITSELF is asynchronous, so it would be bad to show it with a "synchronous" arrowhead. > > > "Nikolai Mansurov" > 03/31/2004 07:42 AM > > To > > "Branislav Selic" , > > cc > > Subject > > RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 > > > > > Hello all, > > Please find attached proposed resolutions for the block of issues on > the notation for create/destroy/return, consolidated into the single > issue 6077. All other issues are closed as duplicates to 6077. > The proposed resolution originally came from Bran, and was > extensively discussed in the middle of February. > > I volonteered to incorporate the corresponding changes. I have also > added the resolution for related issue 6463. > > In the text of the resolution my changes to the original text are > made distinct. > > Best regards, > Nick > > [attachment "mansurov_Interaction issues resolution 6v2.doc" deleted > by James E Rumbaugh/Cupertino/IBM] Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 May 2004 16:32:17 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 The construct explained by Jon below (asynchronous calls that return control to the client application immediately and return values via either callback or polling) can be implemented using the model elements of UML 2. 1. That's not what UML 2 means by 'asynchronous' (for example at 11.3.1, 11.3.7, and elsewhere), right? 2. In the case of the CORBA call we are discussing, can the result be obtained by a ReplyAction? Is there some other action intended for that case? 3. Can UML 2 express each of the three kinds of CORBA calls exactly, without specifying the means an implementation uses to obtain the result? Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 May 2004 16:32:17 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 The construct explained by Jon below (asynchronous calls that return control to the client application immediately and return values via either callback or polling) can be implemented using the model elements of UML 2. 1. That's not what UML 2 means by 'asynchronous' (for example at 11.3.1, 11.3.7, and elsewhere), right? 2. In the case of the CORBA call we are discussing, can the result be obtained by a ReplyAction? Is there some other action intended for that case? 3. Can UML 2 express each of the three kinds of CORBA calls exactly, without specifying the means an implementation uses to obtain the result? Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 May 2004 18:13:20 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 Thanks, Jim. It seems you have already provided a clear answer to my third question: 3. Can UML 2 express each of the three kinds of CORBA calls exactly, without specifying the means an implementation uses to obtain the result? UML 2 can express the case of a call that waits for control to return, with a possible result, and the case of a call that proceeds immediately and does not return a result. UML 2 cannot express the case of a call that proceeds immediately and but does return a result. (UML 2 can express a call that proceeds immediately, followed by some other action that obtains the result, but only by specifying how that is implemented, for example, by polling or by callback. So it is not possible to express in UML 2 the third kind of call; UML 2 can only express one or another of the possible implementations of such a call.) I'm confident someone will correct me if i am wrong. Cordially, Joaquin There may be a difference in terminology from CORBA, but in UML a call in which the caller proceeds immediately after issuing the call has been called "asynchronous" and a call in which the caller waits until the invoked procedure completes and returns control has been called "synchronous". In the current semantics of UML, it is not possible for an "asynchronous" call to return a value. So, Nick, you should NOT add a notation for a return arrow from an asynchronous call, because it does not currently exist. Your answer to me totally missed the point. It is incompatible with the current semantics. Now, maybe someone wants to add a new kind of call, called it a "deferred response" call, in which the caller proceeds after the call, but some point in the future waits for a return. In that case, you would need to distinguish a third kind of call (it's NOT asynchonous nor synchonous), which requires a third notation for the call, but a return arrow at the future point would make sense using the same notation. I actually don't think you need this third approach. It is just as easy to model it by forking before making the original call. One fork makes the call and then waits for the response. The other fork does whatever you would have done after making the call and then just dies. It model the situation very cleanly, more cleanly than the deferred response, without any additional constructs. The CORBA approach does not seem to fit this paradigm. It is a plain asynchonous (one-way, if you wish) call in which the called procedure later calls the original object. A callback is easy to model and doesn't require anything new. It's an asynchonous call, followed later by either a synchronous or asynchronous call in the reverse direction. Similarly, polling is just an original asynchronous call, followed by a later synchronous call (the poll) in the original direction. In Woody's case, we need a transaction mechanism with rollback. This is an important construct, but not something that basic UML provides. It is a feature for a more advanced specification that includes all kinds of transaction capabilities, not just deferred responses. The need for rollback puts it way out of scope for UML. I think that we can do everything we need in ordinary UML with the synchronous and asynchronous (our use of the term, not CORBA's) calls without expanding their definitions. I think people are getting modeling constructs mixed up with programming languages. It is quite easy to model the - Jim Rumbaugh "Pidcock, Woody" 05/10/2004 09:53 AM To "Jon Siegel" , "Nikolai Mansurov" , James E Rumbaugh/Cupertino/IBM@IBMUS cc "Branislav Selic" , Subject RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 Boeing had a requirement for CORBA to support asynchronous calls with a response. Boeing has long-running, compound transactions that cannot leave the caller in a wait state waiting for a synchronous response. However, if the asynchronous response to one of the transactions in a compound transaction indicates a failure of the transaction, then all the other transactions in the compound transaction need to be backed out. Boeing implemented custom code to do this type of two-phase commit since it wasn't initially supported in CORBA. -Woody -----Original Message----- From: Jon Siegel [mailto:siegel@omg.org] Sent: Monday, May 10, 2004 8:15 AM To: Nikolai Mansurov; James E Rumbaugh Cc: Branislav Selic; uml2-superstructure-ftf@omg.org Subject: RE: ,ia, proposed resolutions for 6077, 6260, 6263, 6463, and 6975 Hi Everyone -- About returns from asynchronous calls -- At 07:39 PM 5/8/04, James E Rumbaugh wrote: >1. There is no such thing as a return from an asynchronous call. By >definition, an asynchronous call is a one-way message that does not return! Therefore all the discussion about adding new return types and distinguishing return arrows is mistaken. The only kind of return is a return from a synrchonous call. CORBA defines asynchronous calls that return control to the client application immediately and return values via either callback or polling. Ch 22 of CORBA 3.0.3 covers the spec in detail; section 22.4 gives a good introduction. Calls that do not return are declared ONEWAY, a different beast from Asynchronous. For info on ONEWAY, see section 3.13.1. Hope this helps. Jon Siegel OMG ================================================================== Dr. Jon Siegel email: siegel@omg.org Vice President, Technology Transfer http://www.omg.org Object Management Group First Needham Place Phone: +1 781-444-0404 250 First Avenue, Suite 100 Fax: +1 781-444-0320 Needham, MA 02494 USA PGP Signature: 6882 D54B 3F3A 13CA 8098 1B02 D6B8 4FBD ================================================================== OMG Issue No: 6077 Title: Message notation. Incorrect notation in Figure 333 p.414 Source: Ericsson (Dr. Oystein Haugen, oystein.haugen@ericsson.no oystein.haugen@ericsson.com Oystein.Haugen@eto.ericsson.se) Summary: Firstly not even the original (which is in Visio) has the appropriate dashed line of creation (I thought the pdf just had not quite got it right which happens often, but now I checked the original). Secondly the reply messages should have filled arrowheads (again judging from the description of the message notation). The FTF should reconsider the concrete syntax for create and reply and update the figures accordingly. Originally reported by David Fado through Jim Odell. Discussion: This is a subset of the issue described in 6463. Disposition: Duplicate Originally reported by David Fado through Jim Odell.