umlenterprise-architecturearchimate

Modelling a Message Flow or Sequence between Applications

The question is similar to https://www.uml-diagrams.org/sequence-diagrams.html, but not the same.

I want to model a sequence diagram that shows some kind of message flow or sequence between applications: App1 > App2 > App1.

I see two possibilities:

  1. UML Sequence Diagram: https://www.uml-diagrams.org/sequence-diagrams.html shows my concerns which are mentioned below.
  2. Archimate “Application Component Sequence Diagram View”: like the one shown in Diagram similar to the UML Sequence Diagram with Archimate

The problem with Archimate is that it does not really show / model a sequence (which has already been mentioned by Geert in https://www.uml-diagrams.org/sequence-diagrams.html). The sequence is interpreted by the human because the sequence is read from top to bottom.

So, back to the well-known UML Sequence Diagram. The problem here is that App2 > App1 can only be modelled as a return (dashed line) or as a callback (which creates an overlapping execution box) (see picture below). But App2 > App1 is neither a return nor a callback. Because App2 calls App1 without the intention of calling App1 back or to return something. App2 just processes the flow.

Diagram according Standard

My questions are:

  1. Is there another standard diagram (other than Archimate or UML sequence diagram) available to model a simple (message) sequence between applications and that does not confused with callback or return?
  2. If not, how is it possible to use a UML sequence diagram without using a callback (because it is not a callback and the overlapping execution box even emphasizes this) or a return (because it is not a return and the dashed line even emphasizes this)? Interruptions would also useful, showing that the application has its job done (see the picture below as first draft).

Required Diagram (without overlappings and with interruptions showing that the Execution is terminated

Solution

  • Firstly, let me say that the term callback may be misinterpreted and I have seen two mutually exclusive definitions of it, one being a call to the originally calling application after the original operation finishes, the other being a call to the originally calling while the first application didn't finish its operation, causing an overlapping processing. The way the question is phrased suggests the latter is taken into consideration. This is what I will assume in this answer. Note also that uml-diagrams considers both situations as callbacks, leaving pretty much no other possibility, which begs the question, what specific scenario do you have in mind that is not a callback.

    Secondly, UML does not define a callback as such. The word does not show anywhere in the 2.5.1 version of the specification. I've checked. UML defines only three possible types of messages, one of them being a response to the original synchronous call (return). The other two are pretty much unbound by any conditions when they can be used (synchronous call, asynchronous call or signal - those two are not distinguished by UML notation in sd).

    Thirdly, whatever call is being used, the receiving application has to process it somehow and that explains the execution occurrence existence. The return is practically the only type of a message that typically does not need its individual execution occurrence as it is by definition expected and processed within the execution occurrence that has triggered the call. I can however imagine that the process creates a listener that is actually capturing further incoming calls, meaning there is in a way no separate execution occurrence (one can discuss if that actually is the case as each incoming call triggers some analysis of it).

    UML in no way prevents you from having a call from App2 to App1 that is neither a return nor a callback (whichever of the two definitions we take here). Note however, that some tools may make it... well, somewhat more difficult. Typically though for a good reason as this approach.

    I could imagine just one more or less standard scenario where the call from App2 to App1 occurring after the initial call from App1 to App2 is neither a return nor a callback (that is doesn't not cause an overlapping execution occurrence) and that is, when the App1 already has finished its action that triggered the call to App1 before App2 calls App1. It seems to be exactly what you are looking for.

    Now this can happen (and can be modelled) in two ways:

    1. Asynchronous call from App1 to App2.
    2. Implicit return after the synchronous call from App1 to App2.

    Let's analyse both cases.

    1. Asynchronous call/signal from App1 to App2.

    An asynchronous call/signal is depicted by the solid line with an open arrow. In such case no return is expected and the execution occurrence can finish immediately after the initial message from App1 to App2. As a result, the message coming from App2 to App1 will be below the original execution occurrence in App1. It will still start a new execution occurrence in App1, just not an overlapping one. This situation is depicted (and still called callback) in the diagram you've linked from uml-diagrams page (the <> after the <> on the first diagram). From Proxy perspective you may treat the call as asynchronous from window even though it was effectively processed (validated) by Comments.

    1. Implicit return after the synchronous call from App1 to App2.

    The specification states that the return to the synchronous call does not have to be explicitly depicted on the diagram. In such case the implicit return can happen and the execution occurrence can end without having an incoming return. Then, the call from App2 will again have to be below the original execution occurrence that started the initial call to App2.

    Note, that some tools may not support some of the situations described here, but UML supports it fully.

    One last note (not applicable after the question edit but left for others that might find this answer useful): it might also be the case that you are trying to model on a single diagram something, that essentially suits more as two separate integrations and theoretically should be depicted on two separate diagrams. You may still show it on one UML sequence diagram, but even less modelling tools will help you with that.

    Taking all this into consideration UML sequence diagram is a correct choice for you and the diagram you have in your questions is valid (of course the dashed lines should continue and the execution occurrences should start at the message ends, but I realise it's due to tools limitation). This is the option 2 I proposed (implicit return), based on comments I would also still consider the asynchronous call rather than synchronous (option 1).

    Like I've mentioned earlier, not all tools support such possibility and for those that do you may still need to do some "tricks" to actually create such diagrams. Finally I believe more tools support such model with asynchronous call.

    Two last things to consider: