Each Use Case Diagram (UCD) use case may be expanded into a 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.
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 class specifications 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 data 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 class specification.
It is possible to navigate directly to a class’s definition from an SQD, and thereafter to the Class Diagram (CD) in which the class appears.
By being defined in class specifications, the classes in an SQD will be cross referenceable.
If the user omits the ( and ) characters from messages (which contain the arguments being passed in the message to the operation in the recipient class), then Cradle will interpret the message name as being the name of a data definition. This approach allows SQDs to be used as pure data protocol diagrams, which show time sequenced data exchanges.
When used in this way, the lifelines are not considered to relate to actors or object instances, but instead to relate to parts of the system architecture.
SQDs are not hierarchical. Their connectivity is:
SQDs are available in models in both the Essential and Implementation Domains.
Data Protocol DiagramsThe messages in Sequence Diagrams (SQDs) are normally calls to an operation in a destination class or object instance.
As a non-UML extension to the behaviour of SQDs, if the parameter list of a message is omitted, then the message symbol will have a data definition. This allows SQDs to be used as pure data protocol diagrams.
To omit the parameter list, do not use a () combination in the message name.
Numbering of SQDsEach 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 specifications for object instances and actors are named and numbered from the class or actor name.
SymbolsAn example SQD is:
The symbols available in SQDs are:
| Symbol | Name | Description | Definition | Expansion |
|---|---|---|---|---|
 | Comment | Makes a note anywhere in the diagram. Are always surrounded by * characters. Note: If you do not want Cradle to automatically add an * go to the Graphics Settings section of Project Setup and turn off the Automatically add asterisks to diagram's comment symbols option. | None | None |
 | External Actor | A part of the environment that stimulates the system or is stimulated by it. | Environment | None |
 | Object Instance | An object that is created, performs actions, and/or is destroyed during the lifeline. | Class specification | 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. | Message specification | 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 procedure. 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 |
 | Item | Represents a requirement or system note in the diagram. | None | None |
 | Context Item | Represents a requirement or system note in a diagram and is a container within which other object symbols can be drawn or attached. | None | None |
 | Cross Reference Link | Represents a cross reference that exists between a pair of system notes/requirements. It can also represent a cross reference between a system note/requirement and a specification or data definition or system that describes the objects symbols that it connects. | None | None |