Sequence diagrams are a UML (Unified Modeling Language) diagram and fall under the interaction view; they depict the interactions between the entities and the transactions that are taking place.
The trigger point and the end point are clearly distinguished in the diagram. The diagram shows the different processes as vertical columns or lines and the messages or interactions between them is represented by arrows with the arrowhead pointing towards the receiver away from the sender. The name of the message is written above the messenger arrow line.
It also includes the sequential order of events which will occur from the start to the end of the process. An important part of the sequence diagram is that time passes from the top to the bottom.
A message sent between two entities can be synchronous or asynchronous.
- A synchronous type of message indicates that the sender will wait until the receiver has finished processing the message before proceeding.
- With an asynchronous message type, the sender will not wait for a response from the receiver that they have received and finished processing the message.
- A synchronous message is represented by a filled in arrowhead while an asynchronous message type is represented by an open arrowhead.
The sequence diagrams are helpful in detailing the flow of transactions between the entities such as actor, database, controller, etc. Therefore, for a sequence diagram to be prepared correctly, it’s essential that the Use Case Diagram has been finalized. Otherwise, it could mean rework is required if the use case diagram is revised.
Sequence diagrams can be created by business analysts as part of their functional documentation or by solution architects or designers in their design models. Whether the sequence diagrams are created by the analyst or technical designer, what’s important is that the diagram conveys the right message to both the user groups and the development team.
An example of a sequence diagram is provided below.
In this example, there are three entities – Customer, Waiter, and Chef. The flow of messages can be read as follows:
- The customer gives the order to the waiter
- The waiter will serve the wine and give the order of the food to the chef
- The waiter will pick up the cooked food from the chef and serve it to the customer
- The customer will pay the waiter
This is a very simple example of how the flow of messages can be represented by using sequence diagrams. Note that the responses of the synchronous messages are shown in hashed arrow lines. Wherever there is a gap in the time line, it shows that there was no real interaction in that time period from the concerned entity.
Sequence Diagrams are a clear and simple way of depicting to the users, stakeholders and the technical team how the processing of messages will happen. This diagram can help identify gaps or any misunderstandings at the requirement level.