Sequence Diagram

Implement Sequence diagram for capturing and representation, requirements of a system.

Theory:

Asequence diagram is a kind ofinteraction diagram that shows how processes operatewith one another and in what order. It is a construct of aMessage Sequence Chart.A sequencediagram shows object interactions arranged in time sequence.

Purpose:

The sequence diagram is used primarily to show the interactions between objects in thesequential order that those interactions occur. Much like the class diagram, developers typicallythink sequence diagrams were meant exclusively for them. However, an organization's businessstaff can find sequence diagrams useful to communicate how the business currently works byshowing how various business objects interact.

Besides documenting an organization's current affairs, a business-level sequence diagramcan be used as a requirements document to communicate requirements for a future systemimplementation. During the requirements phase of a project, analysts can take use cases to thenext level by providing a more formal level of refinement. When that occurs, use cases are oftenrefined into one or more sequence diagrams.

Elements of Sequence diagram:

Sequence diagrams are constructed from the following:Lifelines

When drawing a sequence diagram, lifeline notation elements are placed across the top ofthe diagram. Lifelines represent either roles or object instances that participate in the sequencebeing modeled. [Note: In fully modeled systems the objects (instances of classes) will also bemodeled on a system's class diagram.] Lifelines are drawn as a box with a dashed line descendingfrom the center of the bottom edge (Figure 3). The lifeline's name is placed inside the box.

Figure 3: An example of the Student class used in a lifeline whose instance name isfreshman

The UML standard for naming a lifeline follows the format of:

Instance Name : Class Name

In the example shown in Figure 3, the lifeline represents an instance of the class Student, whoseinstance name is freshman. Note that, here, the lifeline name is underlined. When an underline isused, it means that the lifeline represents a specific instance of a class in a sequence diagram, andnot a particular kind of instance (i.e., a role).

Our example lifeline in Figure 3 is a named object, but not all lifelines represent namedobjects. Instead a lifeline can be used to represent an anonymous or unnamed instance. Whenmodeling an unnamed instance on a sequence diagram, the lifeline's name follows the samepattern as a named instance; but instead of providing an instance name, that portion of thelifeline's name is left blank.Messages

The first message of a sequence diagram always starts at the top and is typically locatedon the left side of the diagram for readability. Subsequent messages are then added to thediagram slightly lower then the previous message.

To show an object (i.e., lifeline) sending a message to another object, you draw a line tothe receiving object with a solid arrowhead (if a synchronous call operation) or with a stickarrowhead (if an asynchronous signal). The message/method name is placed above the arrowedline. The message that is being sent to the receiving object represents an operation/method thatthe receiving object's class implements.

Besides just showing message calls on the sequence diagram, the Figure 4 diagramincludes return messages. These return messages are optional; a return message is drawn as adotted line with an open arrowhead back to the originating lifeline, and above this dotted line youplace the return value from the operation. In Figure 4 the secSystem object returns userClearanceto the system object when the getSecurityClearance method is called. The system object returnsavailableReports when the getAvailableReports method is called.

Again, the return messages are an optional part of a sequence diagram. The use of return

messages depends on the level of detail/abstraction that is being modeled. Guards

When modeling object interactions, there will be times when a condition must be met fora message to be sent to the object. Guards are used throughout UML diagrams to control flow.Here, I will discuss guards in both UML 1.x as well as UML 2.0. In UML 1.x, a guard could onlybe assigned to a single message. To draw a guard on a sequence diagram in UML 1.x, you placedthe guard element above the message line being guarded and in front of the message name.

How to Draw?

To create a sequence diagram:1.On theArchitecture menu, click New Diagram.2.UnderTemplates, click UML Sequence Diagram.3.Name the diagram.

4.InAdd to Modeling Project, select an existing modeling project in your solution, orCreate a new modeling project, and then click OK.A new sequence diagram appears with theSequence Diagram toolbox. Thetoolbox contains the required elements and connectors.

To draw a sequence diagram:1.DragLifelines from theToolbox onto the diagram to represent instances of classes,components, actors, or devices. You can also create a lifeline by dragging an existing class, interface, actor orcomponent fromUML Model Explorer onto the diagram. This creates a lifelinerepresenting an instance of the chosen type.

2.Draw messages to show how the lifelines collaborate to achieve a specific goal.

To create a message, click a message tool. Then click the sending lifeline at the pointwhere you want the message to start, and then click the receiving lifeline.

An execution occurrence appears at the receiving lifeline. The executionoccurrence represents a period of time during which the instance is executing a method.You can create other messages that start from an execution occurrence.

3.To show a message that comes from an unknown event source, or broadcasts to unknownrecipients, draw an asynchronous message from or to blank space on the diagram. These

messages are called found messages and lost messages.

4.Draw sequence diagrams for each major message to the same component or system.

Example:

Applications of Sequence Diagrams:

···

We should use sequence diagrams when we want to look at the behavior of severalobjects within a single use case.

Sequence diagrams are good at showing collaborations among the objects. They are not so good at precise definition of behavior.

In short,Sequence Diagrams - capture some elements of the dynamics of systems, support a

number of different activities, describe interaction in some detail, including timing

Conclusion:

Thus we have successfully studied and implemented sequence diagram of a system