topics: using finite-state modeling to reason about a high level design prior to implementation
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/1.jpg)
CSE 335: Software Design E. Kraemer
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
![Page 2: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/2.jpg)
CSE 335: Software Design E. Kraemer
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
![Page 3: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/3.jpg)
CSE 335: Software Design E. Kraemer
Concrete example
Starterinterface
Shift-lockactuator
Softwarecontroller
Remoteinterface
to engine
from engine
![Page 4: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/4.jpg)
CSE 335: Software Design E. Kraemer
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
![Page 5: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/5.jpg)
CSE 335: Software Design E. Kraemer
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
![Page 6: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/6.jpg)
CSE 335: Software Design E. Kraemer
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
![Page 7: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/7.jpg)
CSE 335: Software Design E. Kraemer
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)
![Page 8: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/8.jpg)
CSE 335: Software Design E. Kraemer
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
![Page 9: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/9.jpg)
CSE 335: Software Design E. Kraemer
State diagramsGraphical state-modeling notation:
– States: labeled roundtangles– Transitions: directed arcs, labeled by triggering event, guard
condition, and/or effects
Specifies the response of an object to input events- ignores events except those for which behavior is prescribed
Example:
S T
States
![Page 10: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/10.jpg)
CSE 335: Software Design E. Kraemer
State diagramsGraphical state-modeling notation:
– States: labeled roundtangles– Transitions: directed arcs, labeled by triggering event, guard
condition, and/or effects
Specifies the response of an object to input events- ignores events except those for which behavior is prescribed
Example:
S T
States
Transition
![Page 11: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/11.jpg)
CSE 335: Software Design E. Kraemer
State diagrams
Graphical state-modeling notation:– States: labeled roundtangles– Transitions: directed arcs, labeled by triggering
event, guard condition, and/or effects
Example:
S Tevent(attribs) [condition] / effect
States
EventTransition
![Page 12: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/12.jpg)
CSE 335: Software Design E. Kraemer
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]
![Page 13: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/13.jpg)
CSE 335: Software Design E. Kraemer
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?
![Page 14: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/14.jpg)
CSE 335: Software Design E. Kraemer
guard condition
• boolean expression that must be true for transition to occur
• checked only once, at time event occurs; transition fires if true
![Page 15: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/15.jpg)
CSE 335: Software Design E. Kraemer
“One-shot” state diagrams
• represent objects with finite lives– have initial and finite states
• initial state - entered on object creation• final state - entry implies destruction of object
![Page 16: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/16.jpg)
CSE 335: Software Design E. Kraemer
Example
White’sturn
Black’sturn
whitemoves
blackmoves
checkmate
checkmate
stalemate
stalemate
Chess game
start state
Default final state
![Page 17: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/17.jpg)
CSE 335: Software Design E. Kraemer
Example
White’sturn
Black’sturn
Blackwins
Whitewins
Drawwhite
movesblack
moves
checkmate
checkmate
stalemate
stalemate
Chess game
start state
Finalstates
![Page 18: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/18.jpg)
CSE 335: Software Design E. Kraemer
Example - entry and exit points
White’sturn
Black’sturn
whitemoves
blackmoves
checkmate
checkmate
stalemate
stalemate
Chess game
Black wins
Draw
White wins
![Page 19: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/19.jpg)
CSE 335: Software Design E. Kraemer
Phone Line example
• construct on board
![Page 20: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/20.jpg)
CSE 335: Software Design E. Kraemer
Events
Event : occurrence at a point in time
Concurrent events : causally unrelated; have no effect on one another
![Page 21: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/21.jpg)
CSE 335: Software Design E. Kraemer
Kinds of events
Signal event:– the sending or receiving 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
![Page 22: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/22.jpg)
CSE 335: Software Design E. Kraemer
Signal class - UML notation
<< signal >>Flight Departure
airlineflightNumcitydate
keyword “signal” in << >>
name of signal class
attributes
![Page 23: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/23.jpg)
CSE 335: Software Design E. Kraemer
Kinds of Events
• Change event – caused by satisfaction of a boolean expression– Intent: Expression continually tested; when changes from
false to true, the event happens– Notation: when(val1 < val2)
• Time event– caused by the occurrence of an absolute time or the elapse
of a time interval– when (time = some_time)– when (date = some_date_– after (n time_units)
![Page 24: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/24.jpg)
CSE 335: Software Design E. Kraemer
State Diagrams
• graph whose nodes are states and whose directed arcs are transitions between states
• specifies state sequences caused by event sequences
• all objects in a class execute the state diagram for that class; diagram models their common behavior– Note: state names are unique w/in scope of state
diagram
![Page 25: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/25.jpg)
CSE 335: Software Design E. Kraemer
State Model
• multiple state diagrams, one for each class with important temporal behavior– diagrams interact by passing events and through
side effects of guard conditions– events and guard conditions must match across
diagrams in the model
![Page 26: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/26.jpg)
CSE 335: Software Design E. Kraemer
Details
– if more than one transition leaves a state, then the first event to occur causes the corresponding transition to fire
– if an event occurs and no transition matches it, the event is ignored
– if more than one transition matches an event, only one transition will fire but the choice is non-deterministic
![Page 27: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/27.jpg)
CSE 335: Software Design E. Kraemer
Effect
• effect = a behavior executed in response to an event– can be attached to a transition or a state– listed after a “/”– multiple effects separated with a “,” and are
performed concurrently
![Page 28: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/28.jpg)
CSE 335: Software Design E. Kraemer
Activity Effects
• Activity = behavior that can be invoked by any number of effects
• May be performed upon:– a transition– entry to or exit from a state– some event within a state
• Notation:– event / resulting-activity
![Page 29: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/29.jpg)
CSE 335: Software Design E. Kraemer
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
![Page 30: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/30.jpg)
CSE 335: Software Design E. Kraemer
Activity effects
Idle
Menu visible
r_button_down / showPopup
r_button_up / hidePopup
![Page 31: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/31.jpg)
CSE 335: Software Design E. Kraemer
Do-Activities
PaperJamdo/ flash warning light
• continue for an extended time
• can occur only within a state
• can not be attached to a transition
• may be performed for all or part of time object is in state
• may be interrupted by event received during execution; event may or may not cause state transition
![Page 32: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/32.jpg)
CSE 335: Software Design E. Kraemer
Entry and Exit Activities
Openingentry / motor upexit / motor off
• can bind activities to entry to/ exit from a state
![Page 33: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/33.jpg)
CSE 335: Software Design E. Kraemer
Alternative reps …
![Page 34: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/34.jpg)
CSE 335: Software Design E. Kraemer
Order of activities
1. activities on incoming transition
2. entry activities
3. do-activities
4. exit activities
5. activities on outgoing transition
![Page 35: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/35.jpg)
CSE 335: Software Design E. Kraemer
Completion Transition
• triggered by completion of activity in the source state
State 1do / blah()
State 2
![Page 36: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/36.jpg)
CSE 335: Software Design E. Kraemer
Potential problem …
State 1do /blah()
State 3
State 4
[ x > 20]
[ x < 10]
if (x ==12) when blah() completes??
![Page 37: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/37.jpg)
CSE 335: Software Design E. Kraemer
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
![Page 38: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/38.jpg)
CSE 335: Software Design E. Kraemer
Example: Automatic transmission
Neutral Reverse
First Second Third
upshift
downshift
upshift
downshift
pushN
pushRpushF
pushNpushN
push
N
Transmission
![Page 39: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/39.jpg)
CSE 335: Software Design E. Kraemer
Problem: Multiple similar transitions
Neutral Reverse
First Second Third
upshift
downshift
upshift
downshift
pushN
pushRpushF
pushNpushNpu
shN
Transmission
![Page 40: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/40.jpg)
CSE 335: Software Design E. Kraemer
Solution: State generalization
Neutral Reverse
First Second Third
upshift
downshift
upshift
downshift
pushN
pushR
pushFpu
shN
Forward
Transmission
![Page 41: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/41.jpg)
CSE 335: Software Design E. Kraemer
State generalization
Introduces an abstract “super state”:– decomposes into multiple sub-states– when super state is active, exactly one of its sub-
states is active
Outbound transition incident on super-state abbreviates set of transitions, one from each sub-state
Inbound transition incident on super-state enters sub-state that is distinguished as the start state
![Page 42: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/42.jpg)
CSE 335: Software Design E. Kraemer
Example: Lifecycle of a thread
Ready
Running
Terminated
Blocked
dispatch yiel
d
Runnable
resume
suspend
stop
Created
stop
start
end
Thread
stop
![Page 43: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/43.jpg)
CSE 335: Software Design E. Kraemer
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?
![Page 44: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/44.jpg)
CSE 335: Software Design E. Kraemer
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
![Page 45: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/45.jpg)
CSE 335: Software Design E. Kraemer
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
![Page 46: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/46.jpg)
CSE 335: Software Design E. Kraemer
Example
TempOff
Automobile
Cooling
Heating
pushHeat pushAir
TempOn
pushHeat
pushAir
pushTCOff
Temperature control
Rear defroster
RDOff RDOnpushRD
pushRDRadOff RadOn
pushRad
pushRad
Radio control
![Page 47: Topics: Using finite-state modeling to reason about a high level design prior to implementation](https://reader033.vdocument.in/reader033/viewer/2022052701/5681358d550346895d9cf7c3/html5/thumbnails/47.jpg)
CSE 335: Software Design E. Kraemer
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?