Sequence diagrams are part of UML(Unified Modeling Language) diagrams and come under the interaction view as they depict the interactions between the entities and the transactions that are taking place with the trigger point and the end point clearly distinguished.
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(es). An important part of the sequence diagrams is that time passes from the top to the bottom. A message sent between two entities can be synchronous or asynchronous type. A synchronous type of message indicates that the sender will wait till the receiver has finished processing the message and then only proceed while in asynchronous message type, the sender will not wait for a response that the receiver has received and finished processing the message. A synchronous message is represented by a filled up 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. Hence, for a sequence diagram to be prepared, its essential that the use case diagram would have been finalized, else it could mean rework might be required if the use case digram is revised. Sequence diagrams can be used by business analysts in their functional documentation process or by solution architects or designers in their design models. But whether the sequence diagrams are created by the analyst or technical designer, whats important is that the diagram conveys the right message across to both the user groups and the development team.
An example of a sequence diagram is provided in Figure A
Figure A Sequence Diagram Example
In this example, there are three entities Customer, Waiter, Chef. The flow of message can be read as follows:
- The customer gives the order to the waiter
- Waiter will serve the wine and give the order of the food to the chef
- Waiter will pickup the cooked food from the chef and serve it to the customer
- The customer will pay to the waiter
This is a very simple example of how the flow of messages can be represented by using sequence diagrams. It cab be noted 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 and an assessment of this will go a long way in clearing up any gaps or misunderstandings at the requirement level.