Issue 6975: missing illustrations of graphical paths for create and destroy messages (uml2-rtf) Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com) Nature: Uncategorized Issue Severity: Summary: Table 15 does not include illustrations for - create message (a graphical path flowing into a Lifeline head). - create message to lost - create message from found More illustrations need to be added to Table 15 as the new sorts of messages are added, for example: - synch and async create - synch and async destroy Resolution: Revised Text: Actions taken: February 16, 2004: received issue Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== ubject: UML 2 Super/Interactions/missing illustrations of graphical paths for create and destroy messages Date: Mon, 16 Feb 2004 16:22:25 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2 Super/Interactions/missing OCL constraints Thread-Index: AcOiP5KGfYbXFBuaSOy1/0sMnACRTRSkq3Dg From: "Nikolai Mansurov" To: Cc: "Branislav Selic (E-mail)" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i1GLHGrh002996 Table 15 does not include illustrations for - create message (a graphical path flowing into a Lifeline head). - create message to lost - create message from found More illustrations need to be added to Table 15 as the new sorts of messages are added, for example: - synch and async create Issue 6975: missing illustrations of graphical paths for create and destroy messages (uml2-superstructure-ftf) Source: klocwork, inc. (Dr. Nikolai Mansurov, nikolai@klocwork.com nmansurov@klocwork.com Nikolai@klocwork.com) Nature: Uncategorized Issue Severity: Summary: Table 15 does not include illustrations for - create message (a graphical path flowing into a Lifeline head). - create message to lost - create message from found More illustrations need to be added to Table 15 as the new sorts of messages are added, for example: - synch and async create - synch and async destroy Discussion: Resolution for this issue is consolidated with the resolution for issue 6077: · Example for synchronous create message added to table 15 in the resolution for 6077 · Example of an asynchronous create with return added to table 15 in 6077 · Example of a lost asynchronous create message with Lifeline identification added to table 15in 6077 · Example of a found asynchronous destroy message added to table 15 in 6077 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 Reply-To: From: "Conrad Bock" To: , Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 13:04:54 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Comments on ballot 24 below. Conrad - 4932 (Starting state machine) Typo: replace "filter" with "filer". - 5979 (The description of DataType is plainly wrong in the specification) Typo: "considered the be the same". I assume the Figure 41 example will be included in the final document, even though it isn't in the resolution? The removal of presentation options and style guidelines is a separate issue isn't it? - 6171 (Operation) The new text should refer to Generalization::isSubstitutable, rather than say issues of substitutability are out of scope. - 6616 (UML Superstructure FTF : isRoot property disappeared) The resolution says that isRoot can be derived from whether a classifier has supertypes. This is incorrect, because isRoot is a record for modeler intent that no supertypes will be defined for the classifier. It is analogous to isLeaf, which declares there will be no subtypes, so compilers can optimize message passing into function invocation. I don't mind that isRoot was removed, but the issue should not say it is derivable. - 6902 (Identify sections specifying run-time semantics) Thanks for the update on this. Combined with Jim R's much improved description of events in common behavior, this will be OK for process modelers. (Since the separation of inter- and intra-object is not reflected much in actions and behaviors, it still seems a little confusing, but we don't have time for another update). Typo: "TThese". - 6975 (missing illustrations of graphical paths for create and destroy message) The issues asks for examples, not new notation. That seems reasonable, so this one can be deferred. - 7219 (Operations and derived attributes) One of the roles of FTF/RTF's is to answer questions, even if there is no change. If there is not time to answer these, they can be deferred. - 7438 (Section: 12.3.3) The resolution is incorrect (this should have been assigned to Activities). Here is the resolution: "Connectors are purely notational and have no name. The name displayed is the name of the edge. This is stated by the first sentence under Figure 207. However, there may be an issue that edges are not contained by ownedMember, to be restricted by the Activity namespace, but this requires more discussion to resolve." - synch and async destroy