Sequence Diagram – What, when and who

Sequence Diagram – What, when and who

Reading Time: ~ 4 minutes

Hello my dear Softects,

It is me again: Archie!

Today we are going to discuss another tool in our UML box, the Sequence Diagram! So let’s jump right in it!

Why use a Sequence Diagram?

The sequence diagram it is used to show the interaction of different agents (or objects) during a task. It shows who the participants are and which messages they exchange among them.
Be aware that this is not a tool to show how the whole system works. For that there are better representations that can be used (such as the workflow diagram).
By using the sequence diagram a simple behavior can be shown visually in a way that the time-line (when talking about synchronous events) is clear. For async events it is also possible to use this diagram, however I personally think that the intent doesn’t become as clear.
We will see examples of it in the next sections

 

Life lines and Messages

Life lines are lines coming down from each participant, i.e. the square on the top of the diagram that depict where the object comes in play in the action.

The lines and arrows pointing from one life line to the other signify messages being passed between the participants.

PlantUML Syntax:<br />
Alice -> Bob: message 1<br />
Bob –> Alice: response 1<br />
|||<br />
Alice -> Bob: message 2<br />
||45||<br />
Alice -> Bob: message 3<br />
Bob –> Alice: response 2<br />

The bottom square with the name of the participant is not required, however when there are a lot of messages and the image has to be scrolled down (or even it is just on a really long page) it does help for you to locate where you are.

This simple example shows that Alice sends Bob 3 messages and receives 2 responses back.

Responses are usually depicted with a dotted line.

Calls can also be reflexive, i.e. the object can call itself. This can show an interaction where the object uses an internal method. Here is an example of it:

PlantUML Syntax:<br />
hide footbox<br />
User -> User: getMoneyFromWallet<br />

 

Activation Bars

I am a big fan of these! Unless I am drawing a Sequence Diagram for a sketch (while trying to understand part of a system) or drawing during a discussion on a white board, I add activation bars to the designs.
These show exactly where the object/user comes into play, be it via instantiation or simply getting called, into the analyzed action.
Bear in mind that activation bars are optional so it is up to your personal preference to use them or not.
On a programmer’s lingo, one can explain these bars as when the methods are on the stack.

<

p style=”text-align: center;”>

PlantUML Syntax:<br />
hide footbox<br />
participant User<br />
User -> Worker: DoWork<br />
activate Worker<br />
Worker -> Worker: Internal call<br />
activate Worker</p>
<p>Worker -> RequestCreator: << createRequest >><br />
activate RequestCreator</p>
<p>RequestCreator –> Worker: RequestCreated<br />
deactivate RequestCreator<br />
deactivate Worker<br />
Worker -> User: Done<br />
deactivate Worker<br />

 

Found message

This on is a simple concept! You’ll surely come across a Sequence Diagram where there is a message incoming from the “outside”, i.e. there is no originating life line.
This is called the life line in the UML lingo.
Here is the example from before “recycled” to use found messages:

<

p style=”text-align: center;”>

PlantUML Syntax:<br />
hide footbox<br />
[-> Worker: DoWork<br />
activate Worker</p>
<p>Worker -> Worker: Internal call<br />
activate Worker</p>
<p>Worker ->] : << createRequest >></p>
<p>Worker<–] : RequestCreated<br />
deactivate Worker<br />
[<- Worker: Done<br />
deactivate Worker<br />

 

Loops

You can of course use these diagrams to show a loop…

but why???

…however they tend to pollute the image and I am not a big fan.
I prefer to keep my graphs explaining an iteration of the action or maybe just the general idea instead of using these.
Here is an example. Maybe you’ll like it:

<

p style=”text-align: center;”>

PlantUML Syntax:<br />
Alice -> Bob: Authentication Request<br />
alt successful case</p>
<p>Bob -> Alice: Authentication Accepted</p>
<p>else some kind of failure</p>
<p>Bob -> Alice: Authentication Failure<br />
group My own label<br />
Alice -> Log : Log attack start<br />
loop 1000 times<br />
Alice -> Bob: DNS Attack<br />
end<br />
Alice -> Log : Log attack end<br />
end</p>
<p>else Another type of failure</p>
<p>Bob -> Alice: Please repeat</p>
<p>end<br />

As you can see, you can add to these boxes any label you want. Convention-wise we have:

  • loop – for loops (duhh)
  • alt – for conditions. This has multiple options and could be an if-else condition, where only one will run. The options are divided by a dotted line (like picture above)
  • opt – for conditions. Equivalent to the alt, however there is only one option (like a simple if)
  • par – parallel, where each fragment runs in parallel
  • region – critical region of the code
  • alt – for conditions. This could be an if-else condition

There are several more, but hey remember the Paretto Principle we talked about on the Class Diagram Post? Those are probably most of what you’ll see around.

 

Creation and Deletion

Another way you’ll see a Sequence Diagram in the wild, is with the blocks and life-lines only starting at the moment the objects get created.
Also sometimes there will be an explicit X denoting that the user was deleted.
Here is what we are talking about:

<

p style=”text-align: center;”>

PlantUML Syntax:<br />
hide footbox<br />
participant “ClassA” as A<br />
participant “ClassB” as B<br />
participant “ClassC” as C</p>
<p>[-> A: DoWork<br />
activate A</p>
<p>create B<br />
A -> B: Create Request<br />
activate B</p>
<p>create C<br />
B -> C: DoWork<br />
activate C<br />
C –> B: WorkDone<br />
destroy C</p>
<p>B –> A: Request Created<br />
deactivate B</p>
<p>A –>[ : Done<br />

 

Conclusion

The Sequence Diagram is a powerful tool to visualize interactions between objects/actors during an action. They can be wonderfully combined with user cases/stories and provide a visual way of seeing the action.
As in the case of any other UML tool, one should use discretion on the amount of information that gets packed into the description and the situations when applying the diagram is useful or not.

This is it for this rendition of Archie.
Write to you soon

 – Archie –

Leave your opinion, start a discussion, share an experience or just a compliment...

%d bloggers like this: