System Sequence

Diagrams

SSDs
System Sequence Diagrams are not a
true UML notation (at least not yet).
They are a useful adjunct to the set of
UML design diagrams that aid in the
process of use case realization.
SSDs help begin the process of Dynamic
Design by providing a graphical
representation of the interaction
between the user and the system.

SSD
The SSD shows the interactions between the
user and the System in terms of system
operations and return values.
User inputs into the system, requests that
the system perform some action, are
described in terms of named system
operations (solid arrows) with untyped
parameters.
Return values simply indicate what sort of
data is sent back to the user by the
system.

SSD

SSD
If your UML modeling software permits
it, the proper notation for the user
class should be:

SSDs
Note the solid arrows with names and
untyped parameters.
Each of these arrows is named
according to the System Operation it
depicts.
Note the dashed lines for return values
as a sort of data, or possibly an
Domain Level Object, rather than a
formal type.

SSDs are decomposed into

contracts
Each solid arrow (System Operation) should
map to exactly one Operational Contract.
Each Operational Contract should them
map to one Sequence Diagram.
While UML allows for the depiction of an
entire Use Case Scenario in one Sequence
Diagram for the sake of clarity and
modularity we want you to depict each
System Operation as a separate
Sequence Diagram.