Administrivia

1
Administrivia

• Homework 7 on web
• A tour rather than a working project
• Please look through it and try to understand it
  before Wednesday if at all possible
• Project 3 will be introduced in class on
  Wednesday. Please be sure to attend.

2
Software Architecture and Larger System Design
Issues Lecture 5 Finite state modeling and
analysis

• Topics
• Using finite-state modeling to reason about a
  high level design prior to implementation
• Introduction to UML State Diagram notation
• Chapter 5 in Blaha and Rumbaugh

3
Motivation and overview

• Some objects in a system have complex temporal
  behaviors, which must be carefully designed
• E.g., modern interactive and distributed
  applications
• Typically comprise multiple active objects
• Use locking primitives to synchronize threads
• E.g., embedded systems where software controls
  devices
• Devices run in parallel with controller
• Communicate with one another by signalling
• Design problems
• e.g., race conditions and synchronization
  anomalies
• e.g., lost or unexpected signals, deadlock
• Issue How to design to prevent these problems

4
Concrete example
Shift-lock actuator
Software controller
Remote interface
Starter interface
to engine
from engine
5
Potential problems in such systems

• Controller enters a state in which it is no
  longer receptive to signals from its environment
• Signals may arrive but have no effect
• Controller may prevent issuing of signals
• e.g., greying out of buttons in a graphical
  dialog box
• Controller enters a state in which it is
  receptive to some signals, but not those that are
  being offered by the environment
• Controller expects some peer to be in a state
  that is ready to receive a signal, sends the
  signal, but the peer isnt ready

6
Problems (continued)

• The bad news Most of these problems cannot be
  reliably detected and fixed via testing
• Some are race conditions
• Depend on how the various actors are scheduled by
  OS
• Difficult to reproduce
• Instrumentation (for diagnosis) may make them go
  away!
• Very difficult to simulate all possible
  interactions with an environment
• Often we test our programs under lots of
  assumptions about how they will be used
• These assumptions often turn out to be naive

7
Current state of the practice...

• Relies on designing out these problems rather
  than trying to uncover and reproduce them after
  the fact
• Aided by finite state modeling and analysis of
  software architectures
• Model each entity in the system as a
  communicating finite state machine
• Simulate interactions between state machines,
  looking for flaws
• Model checking Attempts to exhaustively analyze
  a system specified in this fashion

8
Finite-state models

• Describe temporal/behavioral view of a system
• Specify control
• Sequence operations in response to stimuli
• Distinguish states, events, and transitions
• Especially useful during design
• Lots of variants
• E.g., StateCharts, UML state diagrams
• E.g., FSP (textual notation)

9
Key terms

• Event occurrence at a point in time
• instantaneous
• often corresponds to verb in past tense
• e.g., alarm set, powered on
• or onset of a condition
• e.g., paper tray becomes empty, temperature drops
  below freezing
• State behavioral condition that persists in time
• often corresponds to verbs with suffix of -ing
• e.g., Boiling, Waiting, Dialing
• in OO terms an abstraction of values of
  attributes and configuration of objects
• Transition instantaneous change in state
• triggered by an event

10
State diagrams

• Graphical state-modeling notation
• States labeled roundtangles
• Transitions directed arcs, labeled by triggering
  event, guard condition, and/or effects
• Example

S
T
States
11
State diagrams

• Graphical state-modeling notation
• States labeled roundtangles
• Transitions directed arcs, labeled by triggering
  event, guard condition, and/or effects
• Example

Transition
S
T
States
12
State diagrams

• Graphical state-modeling notation
• States labeled roundtangles
• Transitions directed arcs, labeled by triggering
  event, guard condition, and/or effects
• Example

Event
Transition
event(attribs) condition / effect
S
T
States
13
Enabling and firing of transitions

• Transition is
• enabled when source state is active and guard
  condition satisfied
• fires when enabled and the triggering event
  occurs
• Example below
• enabled when current state is Editing and the
  form is complete
• fires when the user presses the OK button

pressOK form complete
Editing
Submitted
14
Enabling and firing of transitions

• Transition is
• enabled when source state is active and guard
  condition satisfied
• fires when enabled and the triggering event
  occurs
• Example below
• enabled when current state is Editing and the
  form is complete
• fires when the user presses the OK button

pressOK form complete
Editing
Submitted
Question What happens if user presses OK when
transition not enabled?
15
Example
Chess game
Black wins
checkmate
Whites turn
stalemate
white moves
black moves
Draw
stalemate
Blacks turn
White wins
checkmate
16
Example
start state
final states
Chess game
Black wins
checkmate
Whites turn
stalemate
white moves
black moves
Draw
stalemate
Blacks turn
White wins
checkmate
17
Kinds of events

• Signal event
• occurrence of a signal
• an explicit one-way transmission of information
• may be parameterized
• E.g., stringEntered(Foo)
• Sending of a signal by one object is a distinct
  event from its reception by another
• Change event
• Event caused by satisfaction of a Boolean
  expression
• Intent Expression continually tested when
  changes from false to true, the event happens
• Notation when(bool-expr)
• Time event
• Example after(10 seconds)

18
Activities

• Often useful to specify an activity that is
  performed within a given state
• E.g., while in PaperJam state, the warning light
  should be flashing
• E.g., on entry into the Opening state, the motor
  should be switched on
• E.g., upon exit of the Opening state, the motor
  should be switched off

19
Examples
PaperJam do/ flash warning light
Opening entry / motor up exit / motor off
20
Problems with FSMs

• Difficult to read with lots of states and
  transitions
• Two sources
• Multiple transitions with same triggering event,
  guard condition, and response but different
  source and/or target states
• State explosion due to concurrency and/or
  orthogonality
• Ameliorated somewhat by modularity features
• State generalization
• Parallel composition

21
Example Automatic transmission
Transmission
pushR
pushF
Neutral
Reverse
pushN
pushN
pushN
pushN
upshift
upshift
First
Second
Third
downshift
downshift
22
Problem Multiple similar transitions
Transmission
pushR
pushF
Neutral
Reverse
pushN
pushN
pushN
pushN
upshift
upshift
First
Second
Third
downshift
downshift
23
Solution State generalization
Transmission
pushR
Neutral
Reverse
pushN
pushN
pushF
Forward
upshift
upshift
First
Second
Third
downshift
downshift
24
State generalization

• Introduces an abstract super state
• decomposes into multiple substates
• when super state is active, exactly one of its
  substates is active
• Outbound transition incident on superstate
  abbreviates set of transitions, one from each
  substate
• Inbound transition incident on superstate enters
  substate that is distinguished as the start state

25
Example Lifecycle of a thread
Thread
Runnable
Ready
suspend
start
Created
Blocked
yield
dispatch
Running
resume
stop
end
stop
stop
Terminated
26
Problem Composite behaviors

• Consider an automobile with multiple options
• Automatic transmission
• Temperature control (heating/air)
• Rear-window defroster
• Stereo system
• Suppose we wish to construct a state diagram for
  the autmobile
• Assume car starts with transmission in neutral
  and temp control, rear defroster, and stereo are
  all off
• What are the possible next states?

27
Example Automobile states
HeatOn_Neutral_DefOff_RadOff
pushHeat
AirOn_Neutral_DefOff_RadOff
pushAir
Started
TCOff_Reverse_DefOff_RadOff
pushR
pushF
TCOff_First_DefOff_RadOff
...
28
State explosion problem

• Number of states in a composite diagram is
  product of the number of states in component
  diagrams
• Major impediment to understanding
• Impossible to visualize in any meaningful way
• Requires the use of analysis tools to verify
  properties
• Managing state explosion
• Concurrent state diagrams
• Highly effective when diagram can be separated
  into truly orthogonal components

29
Example
Automobile
Temperature control
TempOn
pushAir
Cooling
pushTCOff
TempOff
pushHeat
pushAir
Heating
pushHeat
Rear defroster
Radio control
pushRD
pushRad
RDOff
RDOn
RadOff
RadOn
pushRD
pushRad
30
Semantics of parallel composition

• Multiple interpretations
• Concurrent regions execute independently
• What happens if transitions in different regions
  are triggered by same event?
• Do both execute simultaneously? Does one
  consume the event to the exclusion of the
  other?
• Concurrent regions communicate with one another,
  synchronizing on common events
• Regions can only proceed when all are ready to
  proceed
• Regions transfer data values during a concurrent
  transition
• Do we distinguish internal and external events?