UML sequence diagram - how to represent async response

Question

If A sends an async message to B like for example, to load async images to UI from the web. Where should the response message go?

Should it be slant as well or direct? And where would the activation of the sender (A) would be?

Answer 1

There are two questions here: 1. The slanting of the arrow(s) and 2. what to do with the activation.

1. The arrows should be slanted if you want to represent in your diagram that it takes time for the message to travel from A to B or vice-versa.
   If you just want to indicate that the message is processed a-synchronously, it is enough to use an open arrow-head on the message.

2. When a message (sent from A to B) is processed a-synchronously, then the activation of A ends as soon as the message has been sent and starts again when the response from B is received.
   This is under the assumption that A does not block while waiting for the response, but it would be able to do some other processing while waiting for the response.

Answer 2

I used to draw these as part of my job. We had a set way we did them. I'm not going to tell you how because every dang shop has their own way of doing them. I can prove this with a google image search.

One thing you'll notice is that almost no one puts a slant on the arrows. In this metaphor a slant would be lag not asynchronicity.

The y axis represents time. Async doesn't really fit in this diagram because being async means you have your own damn y axis. So anything you draw here is a guess. But we try anyway.

Your "response here" line tells me that when B terminates you expect A to still be processing and, because you put it right at the end, to terminate when it see's B respond.

Your "or here" line tells me that when B terminates you expect A to have already terminated.

Most likely you don't even know which will happen. In those cases the safest depiction is no return arrow at all. If you have a call back to A it makes more sense to have a 'return' arrow. Really you have two different flows of control marching through A at that point.

Traditionally sequence diagrams have had two jobs. To depict flow of control and to predict object life time so you know when it's safe to delete them. When async is involved predicting object life time this way becomes very complicated.

The most important thing is that your shop have a standard way to do it so you can understand each other. If that standard comes out of some version of a UML book so much the better. That means you have a book to hand new employees. But we're not in your shop. We're on Software Engineering.

Answer 3

The term async doesn't really apply at this level. Async describes an event (message or otherwise) that happens independent of the main flow of the program (here, A or B). It is an adjective that describes implementation detail and timing of external events relative to the internal threading design of either a client or a server, and evokes strategies to handle such events as the main program may be doing something else at the time.

At the high level when talking about messages between client and server or two servers (and we are not diving into internal implementation details of either one) we can talk about one way messages, requests/commands (i.e. freely initiated messages), and replies. There is no such thing as sending an async message over the web -- it is just sending a message over the web, which is either request/command or a reply, if you will.

First, we should focus on behavior (is there one or more response for a given request/command) and timing (how much delay do we expect); this is the high level takeaway of the interaction between A & B.

If we want to describe the internal threading of one or the other, we can illustrate, say, a response being received out of the activation. However to be clear, this is not a property of the messaging or the interaction between the two but rather internal detail of how A, in this case, is implemented, which may actually be off topic depending on what the diagram is intended to depict.