software architecture and larger system design issues lecture 5 finite state modeling and analysis n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Topics: Using finite-state modeling to reason about a high level design prior to implementation PowerPoint Presentation
Download Presentation
Topics: Using finite-state modeling to reason about a high level design prior to implementation

Loading in 2 Seconds...

play fullscreen
1 / 47

Topics: Using finite-state modeling to reason about a high level design prior to implementation - PowerPoint PPT Presentation


  • 97 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Topics: Using finite-state modeling to reason about a high level design prior to implementation' - merrill


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software architecture and larger system design issues lecture 5 finite state modeling and analysis

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

CSE 335: Software Design

motivation and overview
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

CSE 335: Software Design

concrete example
Concrete example

Shift-lock

actuator

Remote

interface

Software

controller

Starter

interface

to engine

from engine

CSE 335: Software Design

potential problems in such systems
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

CSE 335: Software Design

problems continued
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

CSE 335: Software Design

current state of the practice
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

CSE 335: Software Design

finite state models
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)

CSE 335: Software Design

key terms
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

CSE 335: Software Design

state diagrams
State diagrams

Graphical 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

CSE 335: Software Design

state diagrams1
State diagrams

Graphical 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:

Transition

S

T

States

CSE 335: Software Design

state diagrams2
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

CSE 335: Software Design

enabling and firing of transitions
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

CSE 335: Software Design

enabling and firing of transitions1
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?

CSE 335: Software Design

guard condition
guard condition
  • boolean expression that must be true for transition to occur
  • checked only once, at time event occurs; transition fires if true

CSE 335: Software Design

one shot state diagrams
“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

CSE 335: Software Design

example
Example

Chess game

start state

White’s

turn

checkmate

stalemate

black

moves

white

moves

stalemate

Black’s

turn

Default final state

checkmate

CSE 335: Software Design

example1
Example

Chess game

Black

wins

start state

checkmate

White’s

turn

Final

states

stalemate

black

moves

white

moves

Draw

stalemate

Black’s

turn

White

wins

checkmate

CSE 335: Software Design

example entry and exit points
Example - entry and exit points

Chess game

checkmate

Black wins

Draw

White wins

White’s

turn

stalemate

black

moves

white

moves

stalemate

Black’s

turn

checkmate

CSE 335: Software Design

phone line example
Phone Line example
  • construct on board

CSE 335: Software Design

events
Events

Event : occurrence at a point in time

Concurrent events : causally unrelated; have no effect on one another

CSE 335: Software Design

kinds of events
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

CSE 335: Software Design

signal class uml notation
Signal class - UML notation

keyword “signal” in << >>

<< signal >>

Flight Departure

name of signal class

airline

flightNum

city

date

attributes

CSE 335: Software Design

kinds of events1
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)

CSE 335: Software Design

state diagrams3
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

CSE 335: Software Design

state model
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

CSE 335: Software Design

details
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

CSE 335: Software Design

effect
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

CSE 335: Software Design

activity effects
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

CSE 335: Software Design

activities
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

CSE 335: Software Design

activity effects1
Activity effects

r_button_down / showPopup

Idle

Menu visible

r_button_up / hidePopup

CSE 335: Software Design

do activities
Do-Activities
  • 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

PaperJam

do/ flash warning light

CSE 335: Software Design

entry and exit activities
Entry and Exit Activities
  • can bind activities to entry to/ exit from a state

Opening

entry / motor up

exit / motor off

CSE 335: Software Design

alternative reps
Alternative reps …

CSE 335: Software Design

order of activities
Order of activities

activities on incoming transition

entry activities

do-activities

exit activities

activities on outgoing transition

CSE 335: Software Design

completion transition
Completion Transition
  • triggered by completion of activity in the source state

State 1

do / blah()

State 2

CSE 335: Software Design

potential problem
Potential problem …

[ x > 20]

State 3

State 1

do /blah()

State 4

[ x < 10]

if (x ==12) when blah() completes??

CSE 335: Software Design

problems with fsms
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

CSE 335: Software Design

example automatic transmission
Example: Automatic transmission

Transmission

pushR

pushF

Neutral

Reverse

pushN

pushN

pushN

pushN

upshift

upshift

First

Second

Third

downshift

downshift

CSE 335: Software Design

problem multiple similar transitions
Problem: Multiple similar transitions

Transmission

pushR

pushF

Neutral

Reverse

pushN

pushN

pushN

pushN

upshift

upshift

First

Second

Third

downshift

downshift

CSE 335: Software Design

solution state generalization
Solution: State generalization

Transmission

pushR

Neutral

Reverse

pushN

pushN

pushF

Forward

upshift

upshift

First

Second

Third

downshift

downshift

CSE 335: Software Design

state generalization
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

CSE 335: Software Design

example lifecycle of a thread
Example: Lifecycle of a thread

Thread

Runnable

Ready

suspend

start

Created

Blocked

yield

dispatch

Running

resume

stop

end

stop

stop

Terminated

CSE 335: Software Design

problem composite behaviors
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?

CSE 335: Software Design

example automobile states
Example: Automobile states

HeatOn_Neutral_DefOff_RadOff

pushHeat

AirOn_Neutral_DefOff_RadOff

pushAir

Started

pushR

TCOff_Reverse_DefOff_RadOff

pushF

TCOff_First_DefOff_RadOff

...

CSE 335: Software Design

state explosion problem
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

CSE 335: Software Design

example2
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

CSE 335: Software Design

semantics of parallel composition
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?

CSE 335: Software Design