Sequence Diagram
Purpose
Each Use Case Diagram (UCD) use case may be expanded into an Sequence Diagram (SQD) and/or a Collaboration Diagram (COD). A use case with multiple scenarios will be decomposed into a lower-level UCD with a set of use cases, one for each scenario, and therefore a set of SQDs. An SQD provides a time-sequenced view of the interaction between actors and class instances in a scenario graphically distributing the messages that are exchanged along timelines.
Example
Here is an example Sequence Diagram.
Description
A use case is a class of interactions between actors in a UML model's environment and the system. Each use case may be complex or compound and may require decomposition into more elemental, simpler, use cases. A use case is, effectively, a set of events sequenced in time, termed an event flow. There may be several event flows for a use case, describing, for example, the normal or most common sequence of events, alternate sequences of events, and exceptional sequences of events that will usually correspond to error conditions. Each path through these multiple event flows is called a scenario.
Scenarios are described by either an SQD or a COD, or both. Both of the diagram styles show the details of the interaction of the environment (the external actors shown in the UCD) with the appropriate part(s) of the system (classes and their object instances), in terms of a time sequenced exchange of messages. The time sequencing is made graphically explicit by the SQD, whereas the COD focuses on clearly showing the totality of message transfers between all of the actors and classes/object instances involved in the scenario.
Except for these graphical differences, the SQD and COD convey similar information.
An SQD identifies the actors and classes (or instances of classes: objects) involved in the interaction, with a timeline (called a lifeline) for each. Between the lifelines, the SQD shows the messages sent between the participants in the interaction. Initially, these messages are expressed in free format text. Ultimately (and potentially only in the design model instances of the SQDs), the messages are rigorously specified in terms of message numbers, optional precursor conditions (termed guards), a message name and optional parameters. In this form, the message names correspond to invocations of correspondingly named operations of the recipient class.
The classes and objects shown in an SQD are defined by PSpecs whose name and number match the name of the class. No other symbol has a definition, the data content of a class must consist of basic data types, there will never be a set of DD definitions defining data structure.
When naming classes and objects in the SQD the naming convention is as follows:
instance-name : class-name
When viewing the definition of an object instance named in this way, Cradle ignores the instance name and the : class name separator character, and uses only the class name to identify the PSpec.
It is possible to navigate diredtly to a class's definition from an SQD, and thereafter to the Class Diagram (CDs) in which the class appears.
By being defined in PSpecs, the classes in an SQD will be cross referenceable.
Characteristics
APPEARS IN MODELS |
Essential and Implementation |
NUMBERING |
Each use case may be expanded into an SQD and/or COD to define its scenario. A use case with multiple scenarios will be decomposed into a lower-level UCD with a set of use cases, one for each scenario. An SQD has the same name and number as its parent use case. The PSpecs for object instances and actors are named and numbered from the class or actor name. |
HIERARCHICAL |
No |
Linkage
Symbols
 |
Comment |
Makes a note anywhere in the diagram. Are always surrounded by * characters. |
None |
None |
 |
External actor |
A part of the environment that stimulates the system or is stimulated by it. |
PSpec |
None |
 |
Object instance |
An object that is created, performs actions, and/or is destroyed during the lifeline. |
PSpec |
None |
 |
Lifeline node |
A connection point in a lifeline. |
None |
None |
 |
Object deletion |
Indicates the deletion of an object. |
None |
None |
 |
Lifeline script text |
A label for the actions being performed over the time of the lifeline, which is attached to a particular segment of the lifeline. |
None |
None |
 |
Send message |
Connects into object lifelines and acts as the source of any type of message. |
PSpec |
None |
 |
Picture |
Allows you to choose the location of a GIF or JPEG image to be displayed as a diagram symbol or to be embedded in an existing diagram symbol. |
None |
None |
 |
Object lifeline |
A representation of the existence of an object over a particular period of time. |
None |
None |
 |
Activation |
The period during which an object is performing an action either directly or through a subordinate procecure. The Activation time may include time when it has control information on a stack, but during which control resides in something that is called. Also known as the Focus of Control . |
None |
None |
 |
Computing activation |
The period during which an object activation is actually computing (i.e. it is the top item on the stack). |
None |
None |
 |
Synchronous message |
An instantaneous communication between objects that conveys information, with the expectation that an action will be initiated as a result. |
None |
None |
 |
Flow of control message |
A message that passes the focus of control from one object to another. |
None |
None |
 |
Asynchronous message |
A communication between objects, taking a measurable time, that conveys information, with the expectation that an action will be initiated as a result. |
None |
None |
|
