K. Stirewalt CSE 335: Software Design Administrivia Homework #7 on web –A “tour” rather than a working project –Please look through it and try to understand

CSE 335: Software Design K. Stirewalt

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.


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


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


Concrete example

Starterinterface

Shift-lockactuator

Softwarecontroller

Remoteinterface

to engine

from engine


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 isn’t ready


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


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


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)


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


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


State diagrams



Example:

S T

States

Transition


State diagrams



Example:

S Tevent(attribs) [condition] / effect

States

EventTransition


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

Editing SubmittedpressOK [form complete]


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

Editing SubmittedpressOK [form complete]

Question: What happens if user presses “OK” when transition not enabled?


Example

White’sturn

Black’sturn

Blackwins

Whitewins

Drawwhite

movesblack

moves

checkmate

checkmate

stalemate

stalemate

Chess game


Example

White’sturn

Black’sturn

Blackwins

Whitewins

Drawwhite

movesblack

moves

checkmate

checkmate

stalemate

stalemate

Chess game

final statesstart state


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)


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


Examples

PaperJamdo/ flash warning light

Openingentry / motor upexit / motor off


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


Example: Automatic transmission

Neutral Reverse

First Second Third

upshift

downshift

upshift

downshift

pushN

pushRpushF

pushNpushN

push

N

Transmission


Problem: Multiple similar transitions

Neutral Reverse

First Second Third

upshift

downshift

upshift

downshift

pushN

pushRpushF

pushNpushNpu

shN

Transmission


Solution: State generalization

Neutral Reverse

First Second Third

upshift

downshift

upshift

downshift

pushN

pushR

pushFpu

shN

Forward

Transmission


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


Example: Lifecycle of a thread

Ready

Running

Terminated

Blocked

dispatch yiel

d

Runnable

resume

suspend

stop

Created

stop

start

end

Thread

stop


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?


Example: Automobile states

Started

HeatOn_Neutral_DefOff_RadOff

AirOn_Neutral_DefOff_RadOff

TCOff_Reverse_DefOff_RadOff

TCOff_First_DefOff_RadOff

...

push

Hea

tpush

Air

pushR

pushF


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


Example

TempOff

Automobile

Cooling

Heating

pushHeat pushAir

TempOn

pushHeat

pushAir

pushTCOff

Temperature control

Rear defroster

RDOff RDOnpushRD

pushRDRadOff RadOn

pushRad

pushRad

Radio control


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?

Documents

K. Stirewalt CSE 335: Software Design Administrivia Homework #7 on web –A “tour” rather than a working project –Please look through it and try to understand