1. State Diagrams / System Sequence Diagrams (SSDs)
Lesson 9

2. Agenda Weekly Schedule-SLATE Solutions to ICE’s posted on SLATE Today
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

3. The Big Picture
© Sheridan College

4. Typical Amazon Package Tracking Status Report
© Sheridan College

5. Review I-C-E-06
Two Versions – check SLATE
© Sheridan College

6. ICE-06 - Option A
© Sheridan College

7. ICE06-Option B
© Sheridan College

8. State Transition Diagrams - Review
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

9. 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

10. Here’s a simple example State Transition Diagram for a washing machine.
Condition
Action
© Sheridan College

11. Typical Washing Machine User Interface
© Sheridan College

12. 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

13. Something we might be more familiar with!
© Sheridan College

14. A Typical Grocery POS[1]
Login Screen
User:
PW:
© Sheridan College

15. A Typical Grocery POS[2]
Ready to Scan next Order
© Sheridan College

16. A Typical Grocery POS[3]
© Sheridan College

17. A Typical Grocery POS[4]
Logging OFF
© Sheridan College

18. State Tables [1]
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

19. State Tables [2]
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

20. Summarize: Rules for Developing Statecharts
[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

21. Rules for Developing Statecharts (continued)
[5] Identify concurrent paths.
[6] Look for additional transitions
[7] Expand each transition as appropriate
[8] Review and test each statechart
© Sheridan College

22. Review Exercise – POS (model of the state of a Point of Sale device)
First. Examine the diagram carefully.
How many different state can the POS be in?
Logging in
Waiting
Scanning
Charging
Logging out
Second.
List all of the Events and Event[Conditions] on the diagram that can trigger a change in state.
1.   Password[Valid]
2.   Password Entry[Invalid]
3.   Customer wants to check out
4.   Scan[item(s)]
5.   Customer pays[Valid]
6.   Customer pays[Invalid]
7.   Scan[last item]
End of shift/Close Register
The next step is to check each of these against each event to confirm that the transitions are correct.
© Sheridan College

23. The Big Picture
© Sheridan College

24. Identifying Inputs and Outputs—the System Sequence Diagram
System sequence diagram (SSD)
Describes flow of information
Identifies interaction between actors and system
Message oriented
The System Sequence Diagram—Identifying
Inputs and Outputs
In the object-oriented approach, the flow of information is achieved through
sending messages either to and from actors or back and forth between internal
objects. A system sequence diagram (SSD) is used to describe this flow of
information into and out of the automated system. Thus, an SSD documents
the inputs and the outputs and identifies the interaction between actors and the
system. An SSD is a type of interaction diagram.
© Sheridan College

25. SSD Notation 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

26. Sample System Sequence Diagram
SSD Notation
Figure above shows a generic SSD. As with a use case diagram, the stick figure
represents an actor—a person (or role) that interacts with the system. In a use
case diagram, the actor “uses” the system, but the emphasis in an SSD is on
how the actor “interacts” with the system by entering input data and receiving
output data. The box labeled :System is an object that represents the entire
automated system. In SSDs and all other interaction diagrams, analysts use
object notation instead of class notation. In object notation, a box refers to an
individual object, not the class of all similar objects. The notation is simply a
rectangle with the name of the object underlined. The colon before the under-
lined class name is a frequently used but optional part of the object notation.
In an interaction diagram, the messages are sent and received by individual
objects, not by a class. In an SSD, the only object included is one representing
the entire system.
Underneath the actor and :System are vertical dashed lines called lifelines.
A lifeline, or object lifeline, is simply the extension of that object—either
actor or object—during the use case. The arrows between the lifelines represent
the messages that are sent by the actor. Each arrow has an origin and a destina-
tion. The origin of the message is the actor or object that sends it, as indicated
by the lifeline at the arrow’s tail. Similarly, the destination actor or object of a
message is indicated by the lifeline that is touched by the arrowhead. The pur-
pose of lifelines is to indicate the sequence of the messages sent and received by
the actor and object. The sequence of messages is read from top to bottom in
the diagram.
A message is labeled to describe its purpose and any input data being sent.
The message name should follow the verb-noun syntax to make the purpose
clear. The syntax of the message label has several options; the simplest forms are
shown in Figure 5-6. Remember that the arrows are used to represent a message
and input data. But what is meant by the term message here? In a sequence
diagram, a message is an action that is invoked on the destination object, much like
a command. Notice in Figure 5-6 that the input message is called inquireOnItem.
Sample System Sequence Diagram
© Sheridan College

27. SSD Notation (continued)
Message syntax can take several forms
Depends on send/return direction
Message semantics: actions (like commands) invoked on destination object  
© Sheridan College

28. Frequently, the same message is sent multiple times
Frequently, the same message is sent multiple times. For example, when an
actor enters items on an order, the message to add an item to an order may be
sent multiple times. Figure 5-7(a) illustrates the notation to show this repeating
operation. The message and its return are located inside a larger rectangle called a loop frame.
In a smaller rectangle at the top of the frame is the descriptive
text to control the behavior of the messages within the larger rectangle. The
condition loop for all items indicates that the messages in the box repeat many
times or are associated with many instances.
Figure 5-7(b) shows an alternate notation. Here, the square brackets and text
inside them are called a true/false condition for the messages. The asterisk (*)
preceding the true/false condition indicates that the message repeats as long as the
true/false condition evaluates to true. Analysts use this abbreviated notation for
several reasons. First, a message and the returned data can be shown in one step.
Note that the return data is identified as a return value on the left side of an assign-
ment operator —the := sign. This alternative simply shows a value that is returned.
Second, the true/false condition is placed on the message itself. Note that in this
example, the true/false condition is used for the control of the loop. True/false condi-
tions are also used to evaluate any type of test that determines whether a message is
sent. For example, consider the true/false condition [credit card payment]. If it is true
that the thing being tested is a credit card payment, the message is sent to the system
to verify a credit card number. Finally, an asterisk is placed on the message itself to
indicate the message repeats. Thus, for simple repeating messages, the alternate nota-
tion is shorter. However, if several messages are included within the repeat or there
are multiple messages—each with its own true/false condition—the loop frame is
more explicit and precise.
Here is the complete notation for a message:
[true/false condition] return-value := message-name (parameter-list)
© Sheridan College

29. SSD Message Syntax
*[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

30. Sequence diagrams use two additional frames to depict processing logic, as
shown above. The opt frame in (a) is used when a message
or a series of messages is optional or based on some true/false condition. The
alt frame is used with if-then-else logic, as shown in (b). The alt
frame in this figure indicates that if an item is taxable, then add sales tax; oth-
erwise, add a tax exemption code for a sales tax exemption.
© Sheridan College

31. Developing a System Sequence Diagram
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

32. A Simplified Diagram of the Telephone Order Scenario
© Sheridan College

33. An SSD of the Simplified Telephone Order Scenario for the Create New Order Use Case
© Sheridan College

34. Developing a System Sequence Diagram (continued)
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

35. Practice Exercise ICE07
See SLATE for a ICE07
© Sheridan College

36. For Next Class Read & Study Chapter 6 Pages 237 -246 What comes next?
Sequence Diagrams
© Sheridan College

37. Class example… Car Rental System – Posted on SLATE Week10
© Sheridan College