Search code examples
umldiagramclass-diagramsequence-diagram

Is it a must to have a reply message for synchronous message in sequence diagrams

I just have 3 doubts regarding sequence diagrams.

  1. Is it a must to have reply message for every single synchronous message, where also i want to know whether reply message is a method or just a message?
  2. In my below diagram, can I use a synchronous message in a right to left rather than a reply direction (eg: 'showAllCompaniesView' and 'updateCompaniesView()')?

enter image description here

Solution
    1. A reply is not needed. If you omit it, the synchronous message will imply the return. You will use a return message in cases where the called object performs certain actions and only then returns to the caller were that comences with further actions. Here's a rough sketch where I omitted almost anything that's not needed: enter image description here
    • So in the above picture the first message does not show a return because it's trivial. The Object2 only performs some action.
    • The second message triggers something more complex in Object2 (that is a message to Object3). Still it's trivial enough to omit the return since Object1 can only commence after the execution of Object2 for the message has ended.
    • The third message has an explicit return. You would probably show that where you had some complex message structure during execution (I only showed one single message but you can imagine a forest here, I guess). Also you will show a return message if you have assignements or any other signature relevant to some return result. From p. 575 of UML 2.5:

    A reply-message-label is used for reply Messages. It has the following form:

    <reply-message-label> ::= [<assignment-target> ‘=’] <message-name> [‘(’ [<output-argument-list>] ‘)’] [‘:’ <value-specification>]

    1. Yes. You can use messages vice versa. If you have a call you will end up in a stack (as you can see also with the additional square on top of the object life line. From a programming perspective that will be more tricky since you have to somehow accept external calls while your program is running. Usually you will need to implement that using threading technology.

    Some more background to 1. My statement is more out of experience than out of specs. I started reading UML 2.5 again (chapter 17.4.3) to find the details - but could not find a direct statement. Here are the passages I found (in that order below the named chapter):

    • If the messageSort is reply, then the Message represents the return from a synchronous call to the Operation. The arguments of the Message correspond to the out, inout and return ownedParameters of the Operation, in the order of the ownedParameters.

    [...]

    A message is shown as a line from the sender MessageEnd to the receiver MessageEnd. The line must be such that every line fragment is either horizontal or downwards when traversed from send event to receive event. The send and receive events may both be on the same lifeline. The form of the line or arrowhead reflects properties of the message:

    [...]

    • A reply Message (messageSort equals reply) has a dashed line with either an open or filled arrow head.

    [...]

    The message-name appearing in a request-message-label is the name property of the Message. If the Message has a signature, this will be the name of the Operation or Signal referenced by the signature. Otherwise the name is unconstrained.

    So far the specs. There are more occurences for reply but only to describe what it must look like. Moreover the return arrow commonly used with the dashed line and open arrow is not listed in the table under 17.1 Graphic Nodes Included in Sequence Diagrams no under B.6 UML Notations and UML DI Representations. But it is used in example diagrams like 17.14 CombinedFragment.

    What made me especially frown is the statement A reply Message (messageSort equals reply) has a dashed line with either an open or filled arrow head. That looks like you can arbitrarily choose the form (filled or not) with no semantic difference.

    Well, the UML specs is made by humans and not free of errors (I already sent some bug reports). However, I'm human as well. Maybe someone else has spotted some details I could not find.

    As commented by AxelScheithauer the open/closed arrow might be as compatibility with the a-/synch notation. Though, a return from an asynch message seems just pointless. Well, we leave it to speculation unless one of the few OMG authors appears here to tell us the truth xD