ITM305 Week 7 SSD Development Steps PDF

## Steps for Developing SSD 1. **Identify input message** - See use case flow of activities or activity diagram - Describe the message from the external actor to the system using the message notation - Name it verb-noun: what the system is asked to do - Consider parameters t...

## Steps for Developing SSD 1. **Identify input message** - See use case flow of activities or activity diagram - Describe the message from the external actor to the system using the message notation - Name it verb-noun: what the system is asked to do - Consider parameters the system will need 2. **Identify any special conditions on input messages** - Iteration/loop frame - Opt or Alt frame 3. **Identify and add output return values** - As explicit return on separate dashed line or - On message itself: aValue:= getValue(valueID) **A system sequence diagram (SSD) illustrates input and output events.** - An SSD shows – for one particular scenario of a use case - the events that external actors generate, - their order, and - inter-system events - The system is treated as a black-box - SSDs are derived from use cases; SSDs are often drawn for the main success scenarios of each use case and frequent or complex alternative scenarios - SSDs are used as input for object design ## System Events and System Operations - **System operations** are the operations that the system as a black box component offers in its public interface. These are high-level operations triggered by an external input event / system event generated by an external actor. - During system behavior analysis, system operations are assigned to a conceptual class **System**. - **NOTE:** In the following example when a message has no parameters no brackets are shown. As noted earlier this is not a convention we are following. E.g. not makeNewSale but makeNewSale ().