A\u00a0sequence diagram<\/b>\u00a0or\u00a0system sequence diagram<\/b>\u00a0(SSD) shows\u00a0process<\/a>\u00a0interactions arranged in time sequence in the field of\u00a0software engineering<\/a>. It depicts the processes involved and the sequence of messages exchanged between the processes needed to carry out the functionality. Sequence diagrams are typically associated with use case realizations in the\u00a04+1 architectural view model<\/a>\u00a0of the system under development. Sequence diagrams are sometimes called\u00a0event diagrams<\/b>\u00a0or\u00a0event scenarios<\/b>.<\/p>\n For a particular scenario of a\u00a0use case<\/a>, the diagrams show the events that external actors generate, their order, and possible inter-system events.\u00a0<\/sup>All\u00a0systems<\/a>\u00a0are treated as a\u00a0black box<\/a>; the diagram places emphasis on events that cross the system boundary from actors to systems. A system sequence diagram should be done for the main success scenario of the\u00a0use case<\/a>, and frequent or complex alternative scenarios.<\/p>\n A sequence diagram shows, as parallel vertical lines (lifelines<\/i>), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner.<\/p>\n A system sequence diagram should specify and show the following:<\/p>\n In developing a project, professionals often use system sequence diagrams to illustrate how certain tasks are done between users and the system. These tasks may include repetitive, simple, or complex tasks. The purpose is to illustrate the\u00a0use case<\/a>\u00a0in a visual format. In order to construct a system sequence diagram, you need to be familiar with the\u00a0unified modeling language<\/a>\u00a0(UML). These models show the logic behind the actors (people who affect the system) and the system in performing the task. Reading a sequence diagram begins at the top with the actor(s) or the system(s) (which is located at the top of the page). Under each actor or system there are long dotted lines called lifelines, which are attached to them. Actions are performed with lines that extend between these lifelines. When an action line is connected to a lifeline it shows the interaction between the actor or system. Messages will often appear at the top or bottom of a system sequence diagram to illustrate the action in detail. For example, the actor could request to log in, represented by login (username, password). After each action is performed, the response or next action is located under the previous one. As you read down the lines you will see in detail how certain actions are performed in the provided model, and in what order.<\/p>\n If the lifeline is that of an object, it demonstrates a role. Leaving the instance name blank can represent anonymous and unnamed instances.<\/p>\n Messages, written with horizontal\u00a0arrows<\/a>\u00a0with the message name written above them, display interaction. Solid arrow heads represent synchronous calls, open arrow heads represent\u00a0asynchronous messages<\/a>, and dashed lines represent reply messages.\u00a0<\/sup>If a caller sends a synchronous message, it must wait until the message is done, such as invoking a subroutine. If a caller sends an asynchronous message, it can continue processing and doesn\u2019t have to wait for a response. Asynchronous calls are present in multithreaded applications, event-driven applications and in\u00a0message-oriented middleware<\/a>. Activation boxes, or\u00a0method<\/a>-call boxes, are opaque rectangles drawn on top of lifelines to represent that processes are being performed in response to the message (ExecutionSpecifications in\u00a0UML<\/a>).<\/p>\n Objects calling methods on themselves use messages and add new activation boxes on top of any others to indicate a further level of\u00a0processing<\/a>. If an object is\u00a0destroyed<\/a>\u00a0(removed from\u00a0memory<\/a>), an X is drawn on bottom of the lifeline, and the dashed line ceases to be drawn below it. It should be the result of a message, either from the object itself, or another.<\/p>\n A message sent from outside the diagram can be represented by a message originating from a filled-in circle (found message<\/i>\u00a0in UML) or from a border of the sequence diagram (gate<\/i>\u00a0in UML).<\/p>\n UML has introduced significant improvements to the capabilities of sequence diagrams. Most of these improvements are based on the idea of\u00a0interaction fragments\u00a0<\/i><\/sup>which represent smaller pieces of an enclosing interaction. Multiple interaction fragments are combined to create a variety of\u00a0combined fragments<\/i>,\u00a0<\/sup>which are then used to model interactions that include parallelism, conditional branches, optional interactions.<\/p>\n","protected":false},"excerpt":{"rendered":"Key elements<\/span><\/h3>\n
\n
Reading a system sequence diagram<\/span><\/h3>\n
Diagram building blocks<\/span><\/h3>\n