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. CSE 335: Software Design

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 CSE 335: Software Design

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 CSE 335: Software Design

4. Concrete example Shift-lock actuator Remote interface Software controller Starter interface to engine from engine CSE 335: Software Design

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 isn’t ready CSE 335: Software Design

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 CSE 335: Software Design

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 CSE 335: Software Design

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) CSE 335: Software Design

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 CSE 335: Software Design

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 CSE 335: Software Design

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 CSE 335: Software Design

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 CSE 335: Software Design

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 CSE 335: Software Design

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? CSE 335: Software Design

15. Example Chess game Black wins checkmate White’s turn stalemate black moves white moves Draw stalemate Black’s turn White wins checkmate CSE 335: Software Design

16. start state final states Example Chess game Black wins checkmate White’s turn stalemate black moves white moves Draw stalemate Black’s turn White wins checkmate CSE 335: Software Design

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) CSE 335: Software Design

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 CSE 335: Software Design

19. Examples PaperJam do/ flash warning light Opening entry / motor up exit / motor off CSE 335: Software Design

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 CSE 335: Software Design

21. Example: Automatic transmission Transmission pushR pushF Neutral Reverse pushN pushN pushN pushN upshift upshift First Second Third downshift downshift CSE 335: Software Design

22. Problem: Multiple similar transitions Transmission pushR pushF Neutral Reverse pushN pushN pushN pushN upshift upshift First Second Third downshift downshift CSE 335: Software Design

23. Solution: State generalization Transmission pushR Neutral Reverse pushN pushN pushF Forward upshift upshift First Second Third downshift downshift CSE 335: Software Design

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 CSE 335: Software Design

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

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? CSE 335: Software Design

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

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 CSE 335: Software Design

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 CSE 335: Software Design

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? CSE 335: Software Design