Transcript SYST39409 - Sheridan College

State Diagrams / System Sequence Diagrams (SSDs)

Weekly Schedule-SLATE
 Assignment No 2 Rubric Posted
 Quiz No 3 next week


Solutions to ICE’s posted on SLATE
Today
 State charts – continued...
 I-C-E-06
▪ Two ways of modelling
 Summarize Requirements Gathering Process
▪ Car Rental System – Case Study
 Introduce System Sequence Diagrams (SSDs)
 Quiz No 2
 ICE-07
© Sheridan College
2
© Sheridan College
3
Typical Amazon Package Tracking Status Report
© Sheridan College
4

Two Versions – check SLATE
© Sheridan College
5
ICE-06 - Option A
© Sheridan College
6
ICE06-Option B
© Sheridan College
7



What is a State Diagram?
Purpose: To model the various states that a
system, user, or object can be in, including
initial and final states.
From a business perspective, tracking the
state of an object provides users with
important status information on key
elements.
© Sheridan College
8
State Transition Diagrams
State:
Some behavior of a system that is observable and that lasts for some
period of time.
A state is when a system is:
• Doing something – e.g., heating oven, mixing ingredients, accelerating
engine,
• Waiting for something to happen – Waiting for user to enter password,
waiting for sensor reading.
Transition:
(Virtually) instantaneous change in state (behavior).
© Sheridan College
9
Here’s a simple example State
Transition Diagram for a washing
machine.
State
Transition
Condition
Action
© Sheridan College
10
Typical Washing Machine User Interface
© Sheridan College
11
A condition is typically some kind of event, e.g.:
•
Signal
•
Arrival of an object (data/material),
•
Etc…
An action is the appropriate output or response
to the event, e.g.:
•
Signal or message
•
Transfer of an object,
•
Calculation,
•
Etc…
Condition
Action
© Sheridan College
12
© Sheridan College
13
Login Screen
User:
PW:
© Sheridan College
14
Ready to Scan next Order
© Sheridan College
15
© Sheridan College
16
Logging OFF
© Sheridan College
17
 State Transition Diagrams often don’t show all
possible combinations of states and events.
 Often they overlook things that can’t or shouldn’t
happen.
 A state table overcomes that limitation by combining
every known state with every event[condition]
combination that can occur.
 You can then specify the correct action or next state.
 If you find a combination of state, event, and
condition for which the attendant action and
subsequent state are not specified, congratulations.
You have found a bug!
© Sheridan College
18

To design a set of functional tests from a
state transition diagram, the rules are simple:
 Visit every state.
 Cover every transition.
 Ensure that no states are unreachable or
unleavable.
© Sheridan College
19

[1] Select the classes that will require statecharts

[2] List all the status conditions for each group

[3] Specify transitions that cause object to leave the
identified state

[4] Sequence state-transition combinations in correct
order
© Sheridan College
20

[5] Identify concurrent paths.

[6] Look for additional transitions

[7] Expand each transition as appropriate

[8] Review and test each statechart
© Sheridan College
21
Start
Logging In
Password [ Valid ] / "Open R egister"
Waiting
Customer Pay s [ Valid ] / "Issue Receip
Initial State
Customer W ants to Check Out
Password Entry [ Inv alid ] / "Display Error Message"
Scanning
Scan [ Item(s) ] / "Display Subtotals"
Scan [ Last Item ] / "Display Total"
Charging
Customer Pay s [ Inv alid ] / "Display Error Message"
End of Shif t / "Close Register"
End
Logging Out
© Sheridan College
22
© Sheridan College
23

System sequence diagram (SSD)
 Describes flow of information
 Identifies interaction between actors and system
 Message oriented
© Sheridan College
24


Actor “interacts” with the system via input/output
SSDs use object notation
 Box (rectangle) refers to individual object
 Name of the object underlined
 Messages sent/received by objects, not classes

Lifeline
 Extension of object or actor for duration of the SSD
 Indicates sequence of the messages sent/received
© Sheridan College
25
Sample System Sequence Diagram
© Sheridan College
26

Message syntax can take several forms
 Depends on send/return direction

Message semantics: actions (like commands)
invoked on destination object
© Sheridan College
27
© Sheridan College
28
*[true/false condition] return-value := message-name (parameter-list)
Any part of the message can be omitted. In brief, the notation components
do the following:
■ An asterisk (*) indicates repeating or looping of the message.
■ Brackets [ ] indicate a true/false condition. This is a test for that message
only. If it evaluates to true, the message is sent. If it evaluates to false, the
message isn’t sent.
■ Message-name is the description of the requested service. It is omitted on
dashed-line return messages, which only show the return data parameters.
■ Parameter-list (with parentheses on initiating messages and without
parentheses on return messages) shows the data that are passed with the
message.
■ Return-value on the same line as the message (requires :=) is used to
describe data being returned from the destination object to the source
object
in response to the message.
© Sheridan College
29
© Sheridan College
30

Begin with detailed description of use case
 Fully developed form
 Activity diagrams

(4) step process for turning activity diagram into SSD
 [1] Identify the input messages
 [2] Describe messages from external actor to system
 [3] Identify/apply special conditions to input messages
 [4] Identify and add the output return messages
© Sheridan College
31
A Simplified Diagram of the Telephone Order Scenario
© Sheridan College
32
An SSD of the Simplified Telephone Order Scenario for the Create New
Order Use Case
© Sheridan College
33

Names of messages reflect services performed

Important principle for identifying data parameters
 Base the list on the class diagram
 Attributes from the classes listed as parameters

Iteratively define input/output parameters around
workflows

Objective: discovery and understanding
© Sheridan College
34

See SLATE for a ICE07
© Sheridan College
35


Read & Study Chapter 6 Pages 237 -246
What comes next?
 Sequence Diagrams
© Sheridan College
36

Car Rental System – Posted on SLATE
Week10
© Sheridan College
37