System Sequence Diagram

A system sequence diagram (SSD) illustrates input and output events related to the systems under discussion. They are input to operation contracts and, most importantly, object design.

The use case text and its implied system events are input to its creation. The SSD operations can in turn be analyzed in the operation contracts and, most important, serve as the starting point for designing collaborating objects.

Use cases describe how external actors interact with the software system. During this interaction an actor generates system events to a system, usually requesting some system operation to handle the event. The use case text implies some event, and the SSD makes it concrete and explicit.

A SSD shows, for one particular scenario of a use case, the events that external actors generate, their order, and inter-system events. All systems are treated as a black box; the emphasis of the diagram is events that cross the system boundary from actors to systems.

Guideline: Draw an SSD for a main success scenario of each use case, and frequent or complex alternative scenarios.

The elements shown in SSDs (operation name, parameters, return data) may need proper explanation. The Glossary is a great place for these details.

Why Draw an SSD?
Think of what events are coming in to the system. Then design the software to handle these events and execute a response. Basically, a software system reacts to three things:
 * 1) External events from actors (human or computers)
 * 2) Timer events
 * 3) Faults or exceptions (often from external sources)

Therefore, it is useful to know what, precisely, are the external input events, the system events. They are an important part of analyzing system behavior.

Before proceeding to a detailed design of how a software application will work, it is useful to investigate and define its behavior as a "black box". System behavior is a description of what a system does, without explaining how it does it. One part of that description is a SSD. Other parts include use cases and system operation contracts.

Iterative and Evolutionary SSDs
Don't create SSDs for all scenarios that requires identification of all system operations. Rather, draw them only for the scenarios chosen for the next iteration. And, they shouldn't take long to sketch, perhaps a few minutes or a half hour.

SSDs are also very useful when you want to understand the interface and collaborations of existing systems, or to document the architecture.