System Sequence Diagram --- SSD

SSD

       A system sequence diagram (SSD) is a fast and easily created artifact that illustrates input and output events related tothe systems under discussion. They are input to operation contracts and mostimportantly object design.

What are SystemSequence Diagrams?

       Use cases describe how external actors interact with the software system we are interested in creating. During this interaction an actor generates system eventsto a system, usually requesting some system operationto handle the event. For example, when a cashier enters an item's ID, thecashier is requesting the POS system to record that item's sale (the enterItem event). That event initiates an operationupon the system. The use case text implies the enterItem event, and the SSD makes it concrete andexplicit.

       The UML includes sequence diagrams as a notation that can illustrate actor interactions and the operations initiated by them.

       A system sequence diagram is a picture that 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.

Why Draw an SSD?

       An interesting and useful question in software design is this: What events are coming in toour system? Why? Because we have to design the software to handle these events (from the mouse, keyboard, another system, …) and execute a response.Basically, a software system reacts to three things: 1) external events from actors (humans or computers), 2) timer events, and 3) faults or exceptions(which are 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.

       You may be familiar with the idea of identifying the messages that go into one software object. But this concept is useful at higher levels of components, including the entire system viewed(abstractly) as one thing or object.

       Before proceeding to a detailed design ofhow a software application will work, it is useful to investigate and defineits behavior as a "black box." Systembehavior is a description of what asystem does, without explaining how it does it. One part of that description is a system sequence diagram. Other parts include the use cases and system operation contracts (to be discussed later).

What is theRelationship Between SSDs and Use Cases?

       An SSD shows system events for one scenario of a use case, therefore it is generated from inspection of a use case.

How to NameSystem Events and Operations?

       System events should be expressed at the abstract level of intention rather than in terms of the physical input device.

What SSDInformation to Place in the Glossary?

       The elements shown in SSDs (operation name, parameters, return data) are terse. These may need proper explanation so that during design it is clear what is coming in and going out. The Glossary isa great place for these details.

Iterative andEvolutionary SSDs

       Don't create SSDs for all scenarios,unless you are using an estimation technique (such as function point counting)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 wantto understand the interface and collaborations of existing systems, or to document the architecture.