Announcing Cradle-7.3 - start your free trial here

3SL Reference

Sequence Diagram (SQD)

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:

Diagram showing the connectivity of a Sequence Diagram

SQDs are available in models in both the Essential and Implementation Domains.