Purpose

Steps

Heuristics

Artifacts

   The sequence diagram maps the functional aspects of each use case workflow into roles and responsibilities for each of the participants. There is at least one sequence or activity diagram for each “leaf” use case in the use case model. A use case may have additional diagrams to represent variants or exceptions to the workflow. Sequence diagrams are best suited for a workflow that is linear in nature with few loops or decisions. If the workflow has many decisions or loops, and activity diagram may be more appropriate.

1. 1. Begin with a blank UML sequence diagram for a selected use case.
   

2. 2. Add the title and date / version to the diagram. The title is an exact match to the name of the use case to ensure traceability.
   

3. 3. Referring to the use case workflow, map each activity onto the sequence diagram:
   

1. a. Identify the “who” and the “whom” in the activity and add them as participants to the sequence diagram. External participants are represented as stick figures (actors) on the diagrams, and internal participants as objects (boxes) with explicit names and types.
   

2. b. Identify the “does what” in the activity and add it as one or more arrows flowing between the participants on the diagram. Label the arrows with text consistent with the workflow activity.
   

3. c. Identify the flow of information in the activity (if any) and add it as a parameter to the messages on the arrows.
   

4. d. Include return arrows where information flows back to the caller. If no information flows, the return can be implicit.
   

5. 5. If necessary, return to the use case descriptions to update the text.

1. • The sequence diagram must be consistent with the workflow description of the use case it represents.  If the use case description is not clear about “who does what to whom”, it must be explored and updated in conjunction with developing the sequence diagram.
   

2. • Sequence diagram participants at this level of abstraction are always entities found within the problem domain.
   

3. • Each sequence diagram should have a clear “trigger”, or event that starts the sequence. Each diagram should also have a clear ending point, usually the realization of the result in the use case description.
   

4. • At this level of abstraction, the flow of control in the diagram is usually single-threaded. A single thread implies that a one line can be drawn on the diagram tracing the flow of control from the start to the finish without lifting the pencil (keeping in mind that some return arrows are implicit, therefore not actually rendered on the diagram.)
   

5. • The flow of data on the diagram must be consistent throughout the flow. Data cannot be introduced in the middle of the workflow without a clear source.
   

6. • Participants should be labeled with the syntax appropriate for an object instance. An object instance is characterized a an instance name, followed by a colon, followed by the type of the instance. The text is also underlined to emphasize the instance vs. a class. for example, the rectangle for the participant may contain the string “bakedBeans:Item”. In some workflows, the instance name may not be relevant, and can be left off. However, the colon and type name must be included, along with the underline.

A Sequence Diagram (Example 1, Example 2, Example 3)