Issue 6463: UML 2 Issue: Message notation (uml2-rtf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: PROBLEM STATEMENT According to Superstructure, p. 430, the notation for messages in interaction diagrams is as follows (we put assumptions between parenthesis): asynchronous message - (solid line) open arrowhead synchronous message - (solid line) filled arrowhead reply message - dashed line (filled or open arrowhead?) object creation - dashed line open arrowhead However, the example given in Figure 333, p. 414, shows a different notation: asynchronous message - solid line open arrowhead (not shown in this diagram, but in others) synchronous message - solid line filled arrowhead reply message - dashed line OPEN arrowhead object creation - SOLID line open arrowhead Another confusing aspect of the notation is that in a reply message, which is not a true message, the message name is the name of the operation invoked on the callee (same as in the corresponding synchronous call), but it suggests instead that there is an operation with this name in the caller. In Figure 333, the reply labeled as "foo(_)" visually suggests that there is an operation named foo in class C1, which is wrong: foo is defined in C2, not in C1. It would make more sense to label a reply message with the name of the value returned. PROPOSED SOLUTION The simplest solution would be to fix Figure 333 using a dashed arrow to represent object creation, although this would yield the same notation for object creation and reply message. Therefore, beyond this simplest solution, we propose something more advanced: First, state explicitly the notation for all kinds of messages, leaving no place for assumptions. Second, use a filled arrowhead for reply messages, since this emphasizes the conceptual proximity to the synchronous message it is a reply from. Third, use the notation for object creation also for object deletion, which currently is not mentioned. That is: asynchronous message - SOLID LINE open arrowhead synchronous message - SOLID LINE filled arrowhead reply message - dashed line FILLED ARROWHEAD object creation OR DELETION - dashed line open arrowhead Or better, simply drop object creation as an special kind of message. Object creation (and deletion) was not considered a special kind of message in UML 1, and it is not at all clear why it should be in UML 2. Probably, an object creation is either synchronous or asynchronous, but not "something else" in the same meta-specialization row. In fact, the constraints and semantics of Message (Superstructure, p. 429) do not consider object creation as messages: "The signature must either refer an Operation (...) or a Signal", "A Message reflects either an Operation call (...) or a sending and reception of a Signal". Neither does the meta-attribute Message.messageSort, which has the following permitted values: synchCall, synchSignal, asynchCall, asynchSignal. By the way, what do synchSignal and asynchCall mean? The "sorts" of message are not defined in the Spec. Although calls are considered in other places to be either synchronous or asynchronous, signals are explicitly defined to be asynchronous (Superstructure, pp. 15, 371, 394 and 395), therefore at least synchSignal is banned. Finally, we also propose to label reply messages with the name of the value returned by the operation call, not the operation name itself. In Figure 333, this would leave the replies foo(_) and doit(_) without label, and the last reply would be labeled simply as "x". Resolution: see above Revised Text: Actions taken: November 7, 2003: received issue March 5, 2004: moved to the Superstructure FTF from Infrastructure August 23, 2006: closed issue Discussion: We have here 3 different problems: 1. There is an error in the illustration (partly due to Visio problems) 2. Notation needs to be fairly backward compatible 3. Notation needs to be fairly consistent with its semantics The first problem is easily fixed. The two latter problems are potentially in conflict. Here are the individual problems: 1. Create and reply messages use the same notation a. This is true, but it does not seem to trouble users of these constructs UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 6463 Document ptc/06-01-01 Page 44 b. They are distinguishable as the create message arrowhead always ends at the head of a new lifeline. That is never the case for any other message. 2. Reply message uses open arrowhead even though it is the reply of a synchronous call. a. Again this does not seem to bother users, but filled arrowhead would be preferable, but not backward compatible. 3. Textual notation for reply messages a. The current notation does include what is needed, and the suggested changes fail to address what is needed. In the example we have on the last reply message “x=bar(_):15” and this means the following: i. “x=” tells where the value of the reply should be stored. x is an attribute of the lifeline receiving the reply. ii. “bar” is the name of the operation and it is true that this may be redundant if we demand always to use execution occurrences to tie call and reply, but in fact we do not require this. It seems reasonable to indicate the name of the operation called to obtain the result. iii. “(_)” means that there is one parameter and it is not a return parameter and is therefore insignificant at the reply. There may have been return parameters and we would have needed this parenthesis. iv. “:15” gives the value of the operation returned. Since sequence diagrams describe very concrete runs, the returned value is important. 4. The create, delete and reply messages are not properly coded in the metamodel a. this is unfortunately the case and should be corrected. Conclusion: We do not do any changes of the notation, mainly because confusion is not so high and it is backwards compatible. We need to correct the figure and the coding of the special messages. Revised Text: Add to the enumeration of MessageSort the following items: • createMessage – the message designating the creation of another lifeline object • deleteMessage – the message designating the termination of another lifeline • reply – the message is a reply message to an operation call End of Annotations:===== ubject: Fw: UML 2 Issue: Message notation X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 7 Nov 2003 08:30:53 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 11/07/2003 08:31:00, Serialize complete at 11/07/2003 08:31:00 Issue raised by Gonzalo Genova. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com ----- Forwarded by Branislav Selic/Ottawa/IBM on 11/07/2003 07:48 AM ----- Gonzalo Genova 11/06/2003 01:34 PM To: "'issues@omg.org'" , Branislav Selic/Ottawa/IBM@IBMCA, "'joaquin@acm.org'" cc: "Juan Llorens (inf)" , "J.Miguel Fuentes Torres" Subject: UML 2 Issue: Message notation This issue refers to UML 2.0 Infrastructure Specification (ptc/03-09-15) and UML 2.0 Superstructure Specification (ptc/03-08-02). PROBLEM STATEMENT According to Superstructure, p. 430, the notation for messages in interaction diagrams is as follows (we put assumptions between parenthesis): asynchronous message - (solid line) open arrowhead synchronous message - (solid line) filled arrowhead reply message - dashed line (filled or open arrowhead?) object creation - dashed line open arrowhead However, the example given in Figure 333, p. 414, shows a different notation: asynchronous message - solid line open arrowhead (not shown in this diagram, but in others) synchronous message - solid line filled arrowhead reply message - dashed line OPEN arrowhead object creation - SOLID line open arrowhead Another confusing aspect of the notation is that in a reply message, which is not a true message, the message name is the name of the operation invoked on the callee (same as in the corresponding synchronous call), but it suggests instead that there is an operation with this name in the caller. In Figure 333, the reply labeled as "foo(_)" visually suggests that there is an operation named foo in class C1, which is wrong: foo is defined in C2, not in C1. It would make more sense to label a reply message with the name of the value returned. PROPOSED SOLUTION The simplest solution would be to fix Figure 333 using a dashed arrow to represent object creation, although this would yield the same notation for object creation and reply message. Therefore, beyond this simplest solution, we propose something more advanced: First, state explicitly the notation for all kinds of messages, leaving no place for assumptions. Second, use a filled arrowhead for reply messages, since this emphasizes the conceptual proximity to the synchronous message it is a reply from. Third, use the notation for object creation also for object deletion, which currently is not mentioned. That is: asynchronous message - SOLID LINE open arrowhead synchronous message - SOLID LINE filled arrowhead reply message - dashed line FILLED ARROWHEAD object creation OR DELETION - dashed line open arrowhead Or better, simply drop object creation as an special kind of message. Object creation (and deletion) was not considered a special kind of message in UML 1, and it is not at all clear why it should be in UML 2. Probably, an object creation is either synchronous or asynchronous, but not "something else" in the same meta-specialization row. In fact, the constraints and semantics of Message (Superstructure, p. 429) do not consider object creation as messages: "The signature must either refer an Operation (...) or a Signal", "A Message reflects either an Operation call (...) or a sending and reception of a Signal". Neither does the meta-attribute Message.messageSort, which has the following permitted values: synchCall, synchSignal, asynchCall, asynchSignal. By the way, what do synchSignal and asynchCall mean? The "sorts" of message are not defined in the Spec. Although calls are considered in other places to be either synchronous or asynchronous, signals are explicitly defined to be asynchronous (Superstructure, pp. 15, 371, 394 and 395), therefore at least synchSignal is banned. Finally, we also propose to label reply messages with the name of the value returned by the operation call, not the operation name itself. In Figure 333, this would leave the replies foo(_) and doit(_) without label, and the last reply would be labeled simply as "x". Issue 6463: UML 2 Issue: Message notation (uml2-superstructure-ftf) Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Nature: Uncategorized Issue Severity: Summary: PROBLEM STATEMENT According to Superstructure, p. 430, the notation for messages in interaction diagrams is as follows (we put assumptions between parenthesis): asynchronous message - (solid line) open arrowhead synchronous message - (solid line) filled arrowhead reply message - dashed line (filled or open arrowhead?) object creation - dashed line open arrowhead However, the example given in Figure 333, p. 414, shows a different notation: asynchronous message - solid line open arrowhead (not shown in this diagram, but in others) synchronous message - solid line filled arrowhead reply message - dashed line OPEN arrowhead object creation - SOLID line open arrowhead Another confusing aspect of the notation is that in a reply message, which is not a true message, the message name is the name of the operation invoked on the callee (same as in the corresponding synchronous call), but it suggests instead that there is an operation with this name in the caller. In Figure 333, the reply labeled as "foo(_)" visually suggests that there is an operation named foo in class C1, which is wrong: foo is defined in C2, not in C1. It would make more sense to label a reply message with the name of the value returned. PROPOSED SOLUTION The simplest solution would be to fix Figure 333 using a dashed arrow to represent object creation, although this would yield the same notation for object creation and reply message. Therefore, beyond this simplest solution, we propose something more advanced: First, state explicitly the notation for all kinds of messages, leaving no place for assumptions. Second, use a filled arrowhead for reply messages, since this emphasizes the conceptual proximity to the synchronous message it is a reply from. Third, use the notation for object creation also for object deletion, which currently is not mentioned. That is: asynchronous message - SOLID LINE open arrowhead synchronous message - SOLID LINE filled arrowhead reply message - dashed line FILLED ARROWHEAD object creation OR DELETION - dashed line open arrowhead Or better, simply drop object creation as an special kind of message. Object creation (and deletion) was not considered a special kind of message in UML 1, and it is not at all clear why it should be in UML 2. Probably, an object creation is either synchronous or asynchronous, but not "something else" in the same meta-specialization row. In fact, the constraints and semantics of Message (Superstructure, p. 429) do not consider object creation as messages: "The signature must either refer an Operation (...) or a Signal", "A Message reflects either an Operation call (...) or a sending and reception of a Signal". Neither does the meta-attribute Message.messageSort, which has the following permitted values: synchCall, synchSignal, asynchCall, asynchSignal. By the way, what do synchSignal and asynchCall mean? The "sorts" of message are not defined in the Spec. Although calls are considered in other places to be either synchronous or asynchronous, signals are explicitly defined to be asynchronous (Superstructure, pp. 15, 371, 394 and 395), therefore at least synchSignal is banned. Finally, we also propose to label reply messages with the name of the value returned by the operation call, not the operation name itself. In Figure 333, this would leave the replies foo(_) and doit(_) without label, and the last reply would be labeled simply as "x". Revised Text: Actions taken: November 7, 2003: received issue March 5, 2004: moved to the Superstructure FTF from Infrastructure Discussion: Resolution for this issue is consolidated with the resolution for issue 6077: · Arrow style fixed in 6077 · According to the resolution for 6077 Create is a special message. Constraint for message is updated as part of 6077, based on the suggestion above · synchSignal is deleted as part of the resolution for 6077 · proposal not to name return messages with the operation name added to the resolution for 6077, based on the suggestion above. Disposition: Duplicate 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 From: "Thomas Weigert" To: "'Branislav Selic'" , Subject: RE: Draft ballot 11 Date: Sun, 30 Oct 2005 22:10:05 -0600 X-Mailer: Microsoft Outlook, Build 10.0.6626 Comments below... Please note the change to 8993.... Issue 6463: I assume the replacement drawing is for figure 14.11 in formal/05-07-04. For one, there are the illustrating comments (in red) missing. I think the "_" in the return message names should be "-" (i.e., dashes). I don't think the return messages should have the operation names on them. Maybe it would be a good idea to add some narrative to clearly explain how to read this diagram? Issue 8956: The notation introduced here seems unwarranted. It is intrusive and does not really help. I think we should continue look for a better notation. Issue 9097: As I already said on Friday, I think it is not necessary to introduce new metaclasses to handle this situation: What about making Duration a ValuePin? Also, we could just use InputPins have a constraint on the respective actions to ensure the related value expressions are TimeExpression and DurationExpression, respectively. I don't think we should introduce new pin kinds as this will make the language more inflexible. Thanks for resolving 8989 and 8990, although I thought I had done this already once before... Thanks for resolving 8993. To be totally consistent, we should change the text on p.417 (Associations) under context as follows: Replace "For example, following this algorithm, the owner of an entry action in a state machine is the classifier that owns the state machine." by "For example, following this algorithm, the context of an entry action in a state machine is the classifier that owns the state machine." Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Sunday, October 30, 2005 8:30 PM To: uml2-rtf@omg.org Subject: Draft ballot 11 Attached, please find the draft of ballot 11 -- the last formally scheduled ballot of our RTF. The only resolutions we will consider after this are ones that are deemed absolutely critical (e.g., they may be needed to generate the XMI). There are 94 issues on the ballot, so we need to take 2 weeks for the soak before we release the official ballot. A couple of things I would like to draw your attention to on the resolutions in this ballot: (1) There are many resolution proposals from Kenn Hussey who is working on producing the XMI for UML 2.0. Each of these issues were uncovered relatively recently during the process of generating the XMI. Since the XMI is a mandatory part of the spec, we have no choice but to solve these issues before we release UML 2.1. This formal process uncovered numerous inconsistencies and incompletenesses in the spec that had to be resolved. In most cases, the resolution is simple and obvious. (2) I added a few mostly editorial minor issues that were spotted during various implementations. I took the liberty of proposing resolutions for them without asking the owners of the respective areas. So, this is a chance for the owners to review and comment on bthe resolution proposals: 8938, 8955, 8968 : State machines (Eran) 8976: Components (Thomas) Interactions (Oystein) 8989, 8990: Components (Thomas) 8993 : Common Behaviors (Thomas), StateMachines (Eran) 9077 : Interactions (Oystein) (3) Resolution 8956 proposas a solution to the long-standing problem of an explicit notation for association ends owned by an association. (4) Resolution 8963 defines the semantics of navigability in more detail. Regards, Bran Date: Mon, 31 Oct 2005 17:26:55 +0100 From: Oystein Haugen User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en To: Branislav Selic CC: Thomas Weigert , uml2-rtf@omg.org Subject: Re: Draft ballot 11 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.532, required 12, autolearn=disabled, AWL -1.08, HTML_20_30 0.50, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.04, UIO_MAIL_IS_INTERNAL -5.00) Thomas and Bran Firstly I thought we would still refer to ptc/04-10-02 in which the figure is 335 (but the issue says 333). Thomas is correct, however, that the given illustration does not replace the whole illustration, but only the background diagram. The thing is that the illustrating comments (in red) are placed upon the background diagram in the Framemaker version, while the diagram is made with Visio. Thomas is also correct that I mistakenly wrote "_" where it should be "-". Sorry. When it comes to the return message names, I am not sure whether Thomas expresses an opinion or refers to the already existing document. I think it is mostly probable that he expresses an opinion with which I disagree. If we remove the name on the return message and the message contains return parameters and/or the assignment to a variable (which is possible in the syntax), it will look very strange. The proposed notation is similar to programming language notation when using the result of a typed method call. Some explanatory text will probably not hurt. I can make an update, but I would like to know what would be the better strategy with respect to showing the illustration since it is closely related to Framemaker. I would also certainly like to have Thomas' and others' opinion on the return message notation. Regards, Oystein Branislav Selic wrote: Thanks, Thomas, for reviwing the resolutions. Here is some feedback on your comments: > Issue 6463: I assume the replacement drawing is for figure 14.11 in > formal/05-07-04. For one, there are the illustrating comments (in > red) missing. I think the "_" in the return message names should be > "-" (i.e., dashes). I don't think the return messages should have > the operation names on them. Maybe it would be a good idea to add > some narrative to clearly explain how to read this diagram? Oystein should comment on this. Oystein? -- 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