Sequence diagram:

A sequence diagram in Unified Modeling Language (UML) is a kind of interaction diagram that shows how processes operate with one another and in what order. It is a construct of a Message Sequence Chart. Sequence diagrams are sometimes called event diagrams, event scenarios, and timing diagrams.

Overview:
A sequence diagram shows, as parallel vertical lines (lifelines), 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. For instance, the UML 1.x diagram on the right describes the sequences of messages of a (simple) restaurant system. This diagram represents a Patron ordering food and wine, drinking wine then eating the food, and finally paying for the food. The dotted lines extending downwards indicate the timeline. Time flows from top to bottom. The arrows represent messages (stimuli) from an actor or object to other objects. For example, the Patron sends message 'pay' to the Cashier. Half arrows indicate asynchronous method calls.

Diagram building blocks

If the lifeline is that of an object, it demonstrates a role. Note that leaving the instance name blank can represent anonymous and unnamed instances. In order to display interaction, messages are used. These are horizontal arrows with the message name written above them. Solid arrows with full heads are synchronous calls, solid arrows with stick heads are asynchronous calls and dashed arrows with stick heads are return messages. This definition is true as of UML 2, considerably different from UML 1.x. Activation boxes, or method-call boxes, are opaque rectangles drawn on top of lifelines to represent that processes are being performed in response to the message (ExecutionSpecifications in UML). Objects calling methods on themselves use messages and add new activation boxes on top of any others to indicate a further level of processing. When an object is destroyed (removed from memory), an X is drawn on top of the lifeline, and the dashed line ceases to be drawn below it (this is not the case in the first example though). It should be the result of a message, either from the object itself, or another. A message sent from outside the diagram can be represented by a message originating from a filled-in circle (found message in UML) or from a border of sequence diagram (gate in UML). UML 2 has introduced significant improvements to the capabilities of sequence diagrams. Most of these improvements are based on the idea of interaction fragments[2] which represent smaller pieces of an enclosing interaction. Multiple interaction fragments are combined to create a

variety of combined fragments[3], which are then used to model interactions that include parallelism, conditional branches, optional interactions.

UML sequence diagrams model the flow of logic within your system in a visual manner, enabling you both to document and validate your logic, and are commonly used for both analysis and design purposes. Sequence diagrams are the most popular UML artifact for dynamic modeling, which focuses on identifying the behavior within your system. Other dynamic modeling techniques include activity diagramming, communication diagramming, timing diagramming, and interaction overview diagramming. Sequence diagrams, along with class diagrams and physical data models are in my opinion the most important design-level models for modern business application development. USES OF SEQUENCE DIAGRAM:
1. Usage scenarios. A usage scenario is a description of a potential way your system is

used. The logic of a usage scenario may be part of a use case, perhaps an alternate course. It may also be one entire pass through a use case, such as the logic described by the basic course of action or a portion of the basic course of action, plus one or more alternate scenarios. The logic of a usage scenario may also be a pass through the logic contained in several use cases. For example, a student enrolls in the university, and then immediately enrolls in three seminars. 2. The logic of methods. Sequence diagrams can be used to explore the logic of a complex operation, function, or procedure. One way to think of sequence diagrams, particularly highly detailed diagrams, is as visual object code. 3. The logic of services. A service is effectively a high-level method, often one that can be invoked by a wide variety of clients. This includes web-services as well as business

transactions implemented by a variety of technologies such as CICS/COBOL or CORBA-compliant object request brokers (ORBs).
Element and its description Object: The primary element involved in a sequence diagram is an Objectan instance of a class. A Sequence diagram consists of sequences of interaction among different objects over a period of time. An object is represented by a named rectangle. The name to the left of the ":" is the object name and to its right is the class name. Symbol

Message: The interaction between different objects in a sequence diagram is represented as messages. A message is denoted by a directed arrow. Depending on the type of message, the notation differs. In a Sequence diagram, you can represent simple messages, special messages to create or destroy objects, and message responses.

RELATION BETWEEN SEQUENCE DIAGRAM & USE CASE DIAGRAM 1. A use-case model is built and the actors are connected to use cases. Each use case represents a task in which the actor participates. 2. For each use case, a sequence diagram is built. Each sequence diagram specifies the main interaction steps to be achieved for each task (i.e. use case). Some of the interaction steps in a sequence diagram can be deployed in another sequence diagram (or subdiagram). 3. From the sequence diagrams, use-case relationships are identified. Sequence subdiagrams are identified with new use cases. Then, the inclusion relationships are identified between the use cases specified and the new use cases. 4. The sequence diagrams are refined: some interaction steps are added as extensions to the original sequence diagrams. These extensions are represented as new sequence (sub)diagrams. These new subdiagrams are identified with new use cases. Sometimes, new abstract use cases can be defined representing generic sequence diagrams, and particular cases of abstract use cases are identified in which interaction steps are added or rewritten. 5. From the refined sequence diagrams, new use-case relationships are discovered: new generalization/specialization and extension relationships. Generalization/specialization relationships between abstract and particular use cases are identified. Extension relationships are identified between old use cases and their extending use cases.

6. Some of the previous steps might be applied incrementally in the development process.