sequence diagram

Sequence diagram notations

There are many components of a sequence diagram, which consists of various standardized dimensions and notations.

The two major axis dimensions are objects and time. Objects, which run across the horizontal axis, show the various elements that the interactions revolve around. The vertical axis, time, indicates the sequential progression of the interactions depicted in the diagram -- note, however, that it does not indicate duration of those interactions.

Within those dimensions, sequence diagrams typically include the following major notations:

• Lifelines represent an individual participant within an interaction. Lifelines are represented by vertical dashed lines, connecting at the top to an object or actor.
• Actors represent the user, external hardware or other subject setting off a particular sequence. They often appear as a stick figure icon and are placed to the left of the first object on the horizonal axis.
• Activation bars -- sometimes called focus of control -- are thin rectangular boxes that sit vertically on top of an object's lifeline to indicate the duration of a particular operation.
• Interaction fragments have no general notation but are used to describe an element of interaction in a sequence diagram. Examples of interaction types include occurrence, execution, state invariant, interaction use and combined fragment.
• Guards, also known as interaction constraints, are square brackets positioned around an interaction as a Boolean expression. They represent a check or pause to make sure certain conditions have been met.
• Messages represent communication from one actor or object to another. The first message typically starts at the top left of the sequence diagram and moves horizontally across lifelines from left to right, with each subsequent message one step lower than the one before.

Sequence diagram message types

There are many different message types that a sequence diagram can include:

• Synchronous messages occur when the object or actor who sent the message must wait for a reply before continuing. They are represented by a solid line and solid arrowhead.
• Asynchronous messages mean the message sender doesn't need to wait for a response before continuing. They are represented by a solid line and open arrowhead.
• Return messages most often move from right to left and are represented by a dashed line with a solid or open arrowhead.
• Create messages show when a new object is created. They are represented by a dashed line and open arrowhead, with the word create appearing above the line.
• Delete messages are used to delete an object. They are represented by a solid line followed by an X on the receiving lifeline, signaling destruction.
• Reflexive messages represent when an object sends a message to itself. They are represented by an arrow that starts and ends at the same lifeline.

Combined fragments in sequence diagrams

Combined fragments place multiple interaction fragments together and represent specific conditions that affect sequences. They are enclosed in boxes that consist of an interaction operator and corresponding operand. There are many combined fragment types, including the following:

• Option. Options represent choice between scenarios. The interaction operator is opt and highlights options an actor or object can choose.
• Alternative. Alternatives represent mutually exclusive conditions. The first operator is alt, followed by the operator else. Each condition path is delineated using an if-then model.
• Loop. Loops represent repetitive sequences. The interaction operator is loop.

This list is not exhaustive of the extensive notation options for sequence diagrams. In many cases, these basic elements make up the diagram. In others, teams can look to specific notating options for unique design.

The importance of sequence diagrams

Sequence diagrams have a variety of uses, many of them geared toward system design, testing and maintenance. Software developers and architects can use these diagrams in initial planning stages to brainstorm design, establish system requirements and consider how individual aspects of the system contribute to the overall end goal.

Sequence diagrams can increase the value of design meetings by enabling team members to communicate through a common visual. Teams might also spot problems earlier on. This can increase efficiency and troubleshooting to correct the issue before it reaches a later stage of development.

Software development teams can also use sequence diagrams to model and analyze specific use cases. By visually mapping out the order in which actions occur in the use case, teams can spot the dynamic sequence of events. This can help solve interaction problems that arise and enhance team understanding of the use case.

Visually documenting systems can help maintain existing systems and explain how certain objects interact with each other. This makes a sequence diagram especially beneficial when control of a software system transfers from one team to another. This can also be applied to business models or other nonsoftware systems; sequence diagrams can establish the interactions that take place in, for example, a business collaboration workflow.

Sequence diagram best practices

While sequence diagrams can improve a team's development or testing process, there are certain things to keep in mind. For one, overdetailed sequence diagrams can become visually cluttered and hard to comprehend. To keep the diagram coherent, make conscientious decisions about what details to include and what to leave out. Only include the necessary lifelines and messages, and leave out noncritical details.

If the sequence diagram complements a single use case, include the use case text along with the diagram. Having the use case -- and, if there is one, a use case diagram -- written down can enhance the reader's understanding of the sequence diagram.

Finally, remember that sequence diagrams can become out of date as software evolves, eventually rendering them useless. Routinely revisit and update sequence diagrams to keep diagrams relevant.

Sequence diagrams vs. collaboration diagrams

Sequence and collaboration diagrams are both types of interaction diagrams in UML, meaning they map the dynamic movement of objects within a system. Like sequence diagrams, collaboration diagrams rely heavily on actors, objects and messages to portray the system.

The major differences between these two diagram types lie in their interpretations of time and complexity. Sequence diagrams highlight the sequence of events through lifelines and can account for the level of complexity an interaction involves. Collaboration diagrams, meanwhile, document the entire system as a whole, focusing on the qualitative nature of those interactions rather than the specific order of events.