University of Toronto University of Toronto Department of Computer Science What are we modelling Lecture 16 Modelling events Application Domain P programs Starting point Comparing notations for state transition models States of the environment FSMs vs Statecharts vs SCR Events that occur in the application domain that change the state of the environment Checking properties of state transition models Requirements expressed as Constraints over states and events of the application domain Consistency Checking E g When the aircraft is in the air the pilot should be prevented from accidentally engaging the reverse thrust Model Checking using Temporal Logic C computers R requirements Explicit event semantics Machine Domain D domain properties Focus on states or events E g SCR table based models Department of Computer Science When to use formal methods To get to a specification For each relevant application domain event find a corresponding input event For each relevant state ensure there is a way for the machine to detect it For each required action find a corresponding output event 1 Easterbrook 2004 University of Toronto Department of Computer Science 2 Easterbrook 2004 University of Toronto Tabular Specifications SCR SCR basics Four Variable Model System Enviroment Monitored Variables software output output data items devices Transitions in each mode class are triggered by events Controlled Enviroment Variables Complex systems described using several mode classes operating in parallel System State is defined as the system is in exactly one mode from each mode class and each variable has a unique value Dictionaries Tables Mode Transition Tables also Assertions Scenarios Event Tables Failure ff TACFailure CurrentModePoweredonToo ColdTemp OKToo HotNew ModeOff T t Inactive Tt Heat T tACInactive F Off T Heat TACHeat F Off T InactiveAC F Off T Inactive ModesEventsNoFailure T INMODE neverSensorFail T reset on T INMODE TimeoutalwaysneverACFailure HeatFailurenever T INMODE Warning light OffOn ModesEventsNoFailure T INMODE neverBlah T thingy T other DoodahneveralwaysACFailure HeatFailurenever T INMODE Heater OffOn ModesEventsNoFailure T INMODE neverBlah T thingy T other DoodahneveralwaysACFailure HeatFailurenever T INMODE ACpower OffOn An event occurs when any system entity changes value An input event occurs when an input variable changes value Notation Types TypeBaseTypeValuesUnitsWarningLevelenumeratedlow med high Temperatureinteger 100 100degrees CWaterlevelinteger0 100metersFlagenumeratedon off Condition Tables ModesEventsNoFailuretruefalseACFailuretemp temp0temp temp0HeatFailurefalsewaterlevel lowWarning light OffOn ConstantTypeValueUnitsLowTempinteger15degrees CHighTempinteger23degrees CMaxTimeOutinteger300millisecReferenceSafetyLevelsafetytypelow TempMargininteger5degrees C ModesEventsNoFailurefalsetrueACFailure HeatFailuretruefalseBuzzer OffOn We may need to refer to both the old and new value of a variable Used primed values to denote values after the event T c c c e g T y 1 y 1 y 1 F c c c A conditioned event is an event with a predicate SCR Specification Easterbrook 2004 Events Single input assumption only one input event can occur at once CurrentModePoweredonToo ColdTemp OKToo HotNew ModeOff T t Inactive Tt Heat T tACInactive F Off T Heat TACHeat F Off T InactiveAC F Off T Inactive VariableTypeInitial ValueUnitsWarningFlagbooleanfalse OtherFlagbooleantrueFudgelevelenumeratedone Waterlevelreal0 0mtemperaturereal0 0degrees CurrentModePoweredonToo ColdTemp OKToo CBlipCounterinteger0milesTimeNowreal100 0secAirBrakeAccreal0 0m sec HotNew ModeOff T t Inactive Tt Heat T tACInactive F Off T Heat TACHeat F Off T InactiveTimeout F No Constants Modes and Mode classes A mode class is a finite state machine with states called system modes input input devices data items Monitored Controlled Variables Department of Computer Science T c WHEN d c c d 3 Easterbrook 2004 Source Adapted from Heitmeyer et al 1996 4 1 University of Toronto University of Toronto Department of Computer Science Defining Mode Classes Defining Controlled Variables Mode Class Tables Define a disjoint set of modes states that the software can be in Event Tables defines how a controlled variable changes in response to input events Defines a partial function from modes and events to variable values Example A complex system will have many different modes classes Each mode class has a mode table showing the events that cause transitions between modes Modes Heat AC Inactive Off Ack tone A mode table defines a partial function from modes and events to modes Example Current Powered Too Cold Temp OK Too Hot Mode on Off T t T t T t Inactive F T T Heat F T AC F T Easterbrook 2004 New Mode Inactive Heat AC Off Heat AC Off Inactive Off Inactive Heat AC Inactive Off idle off hook ringtone Current Mode Idle Dialtone connected on hook Busytone Ringtone on hook on hook offhook Connected AC busytone on hook idle Easterbrook 2004 off hook Dial callee busy dialtone Callee disconnects Dial callee idle ringtone Callee accepts Off On 6 Source Adapted from Heitmeyer et al 1996 Department of Computer Science SCR Equivalent Callee disconnects Callee accepts target temp 5 temp target 5 never University of Toronto busytone Dial dialtone callee idle target temp 5 temp target 5 true Warning light Easterbrook 2004 Department of Computer Science Dial callee busy never C target Clang Condition Tables Refresher FSMs and Statecharts on hook C target never Beep defines the value of a controlled variable under every possible condition Defines a total function from modes and conditions to variable values Example Modes 5 Source Adapted from Heitmeyer et al 1996 University of Toronto Department of Computer Science connected offhook dial T F F F F T T callee offhook F T T F New Mode Dialtone Ringtone Busytone Idle Idle Connected Idle Dialtone Idle Interpretation In Dialtone T offhook WHEN callee offhook takes you to Ringing In Ringtone F offhook takes you to Idle Etc 7 Easterbrook 2004 8 2 University of Toronto University of Toronto Department of Computer Science Department of Computer Science State Machine Models vs SCR All 3 models on previous slides are approx equivalent State machine models formal analysis Is the formal model well formed assumes a modeling language where well formedness is a useful thing to check Emphasis is on states transitions No systematic treatment of events Different event semantics can be applied Formal challenges Composition achieved
View Full Document
Unlocking...