UML Sequence Diagrams give you a way to visually express a scenario in the operation of a system, focusing on the order of interaction between objects and processes in it. This article presents the basic concepts to help you get started with sequence diagramming. They are a good way to communicate with fellow coders and make your boss look stupid. If there is need to help with that, of course.

What is a UML Sequence Diagram?

A Sequence Diagram is like a film trailer. It tells you a snippet of a story and leaves you to draw your own conclusions. Remember the trailer for The Hangover Part II? It’s a bit like that. Just less exciting.

A small office. Tuesday afternoon. The main character (me) is working hard to make a dent in the bug backlog and even harder not to eavesdrop on one side of a phone conversation coming from the far end of the room:

“To be honest with you, it will be available to everyone in the next release, but surely we could do a special build for you before that. Let’s say… end of next week?”

The voice is a sexy baritone and belongs to Martin Fibbs, salesman, presently making promises to one of our bigger clients.

An important part of a sequence diagram in UML is who takes part in the story. Let me introduce…

The Participants

… which is what the entities in the diagram are often called, though this is not part of the UML standard.

  • A participant would often, though not always, be an object in a software program and is represented with a box, containing the participant’s name, its type or both.

  • An actor is an external participant – in interaction with the system being modelled, but not part of it. Actors are shown with stick figures and are often used to represent customers or users.Our client is my token actor here. You may notice that the client is only represented with a type and no name. However, if you want to be explicit, here is a fuller notation:

Name[ Qualifier ] : Type

  • “Qualifier” helps you specifically indicate which entity out of a set you mean.So, being less personal, I could have introduced myself as Employee 34, or, to put it in UML:

Nice to meet you.

I have been Employee 34 for a while and have noticed several levels of honesty in the arsenal of a salesperson:

  • “to be honest” = “I’d be looking you in the eye and lying to you, if we weren’t talking on the phone.”
  • “to be honest with you” = “This particular lie has been tailored especially for your case.”
  • “to be totally honest with you” = “Oh, come on, I’m getting a bit desperate here…”

Level two honesty and “special build” mean trouble for me. Fibbs has just managed to sell the “export to Excel” feature of our database reports to the client in question.The Excel export was discussed last month, found to be too much work and crossed off the release backlog and to my relief. In good times (an atomic bomb kills all sales personnel and the management offers the rest of us an unlimited supply of pizza and caffeine), it could probably be coded in a month. And it has just been promised and expected to be finished, tested, debugged, shrink-wrapped and delivered in a week.I steal a glance at my manager, Mr. Fossey, whose desk is across from mine.

Ah, new participant:

He seems just as exasperated as I am at the sound of the phone conversation, but manages to give me the “Oh well, get on with it” look.I have also been long enough in this office to know that I am probably more disposable than the client in question. And this makes my lifeline start to seem a bit short…

Participant lifelines

Hang on, what is a lifeline?

As a storyteller, a UML sequence diagram shows the passage of time – from top to bottom. A lifeline is shown with a dashed line coming down from each participant’s box and “represents the evolving life of the participating object by showing relevant events that are important to the object.”, to quote UML 2 For Dummies.

Creating and deleting participants

A “relevant event” can be as important to a participant as life and death. Literally.The diagram below shows two examples of that:

  • my boss hiring me eight years ago as a young and enthusiastic coder – shown with a message arrow coming out of Fossey’s lifeline;
  • his (very hypothetical) coming over to my desk to hand me his goodbye note and proceeding to delete me from the system – that would be the big fat X at the end of my short, but miserable, lifeline.

Activating participants – run, rabbit, run!

A white box on top of a lifeline shows that a partici pant is active, i.e. doing things. When the thing doing commences right after the creation of a participant, the activation box comes straight out of the participant’s box.

This is more like it: the day I was hired, I was also immediately activated and got on with fixing bugs in one of the company’s products – no welcome lattés, no pens with fancy logos.

The, still hypothetical, cross putting an end to my lifeline, is my paranoia kicking in, though… What is more likely to happen, is a bit more complicated…

Conditionals – what if?

What I imagine will happen next, is Fossey asking me to get on with the *** Excel export feature.

Things could then go two ways: I either finish it before next Friday, ask my boss for a promotion and take my mum on a holiday in Greece, or I fail and then I am deleted from the system. Still a bit apocalyptic, but not that improbable. Wish me luck.


  • UML – Unified Modelling Language
  • UML Sequence Diagram – a diagram, which describes a scenario in the behaviour of groups of collaborating objects
  • actor – something or someone, interacting with a system, but not part of it
  • lifeline – a line, representing the life span of a participant in the scenario
  • message – a line of communication between participants in the scenario (see “Messages in UML 2.0 Sequence Diagrams” for details on the types of messages and their use)
  • Class Diagram – a digram, which shows classes (object types), participating in a system, their properties and the relationships between them
  • Class Properties represent the features of a class, which can be attributes or associations


As much as I would like to take credit for the knowledge in this article, all the UML stuff comes from:

The cool cartoons are courtesy of zlotence.

About the Author

Manuel grew up in a small town. Went on to study Computer Science in a low level university in a slightly bigger town. Tried smoking for the first time. Didn't like it. Has been an employee of A Corporation, writing mostly C++ code for the last nine years. Bear with him.