A sequence diagram describes an interaction: between user(s) and an application and among objects within an application.

A non-software illustration is using a single elevator. The steps of the interaction are shown, each below the previous one. We could separately describe the states of elevator etc. but that is not our goal here.We want to illustrate the sequence in which functionality is exercised by various objects.Where you see the object :Elevator (there is only one, so its name is not supplied--or we could used myElevator:Elevator), think of a software object of a software class rather than the physical elevator containing and executing software.In other words, the objects in question are part of a software application rather than being physically embedded in the things mentioned.(The latter is not out of the question, however.)

Precondition: User standing at elevator door of floor number Beg

Goal: User at floor number End>Beg

Use Case (useful to express first to guide the process):

1. User pushes UP button

2. Elevator travels to floor Beg

3. Elevator door opens

4. Customer enters elevator

5. Elevator door closes

...

Note that objects are instances of classes but in many cases, only one object of the class is relevant within the application.

For each step, there is an *initiator* object and a *doer* object. An initiator can be either a user or an object within the application. A doer is usually an object within the application.

An arrow goes from the initiator to the doer. It is labeled with the name of the function that the doer object performs. In the case of traveling, for example, the elevator changes its position (variable), so it is both initiator and doer.

User..........:UpButton...........:Elevator...........:ElevatorDoor

| ---1. push--->|

| .....................| --2.1 activate -->|

| .....................|.........................|-----2.2 travel -----

| .....................|.........................|<----------------------

| .....................| .........................|------3.open----->|

| ----------------4. enter ------------------>|

The beginning of each arrow is often (but not always) the same object as the end of the previous arrow. Arrows may go left or right. In pure software, we notate as close to the code as we can, using function names and parentheses when known. But we can remain at a less formal level.

I did not use Visio for this example, so it does not show clearly the beginning and ending of each function. In all UML diagrams, many types of detail can be added.For example, some designers like to show a return-type of arrow from the doer object to the initiator object (Visio covers just a subset in any case.) It's a judgment call as to whether each type of detail is valuable or whether it becomes clutter or too expensive to maintain.