Professional Documents
Culture Documents
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.
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.