CS 290C: Formal Models for Web Software Lecture 4: Implementing and Verifying Statecharts Specifications Using the Spin Model Checker Instructor: Tevfik Bultan

How to model statecharts in Spin? Statecharts can be converted to flat-state machines So we can do the following: –Flatten the statecharts specification, which generates at regular state machine –Then, use the approach described in the previous slides However this approach will result in a very large and ugly state machine

How to model statecharts in Spin? Instead of flattening the statecharts, we can keep the hierarchy Declare an mtype that lists the sub-states of all OR-states in the statecharts specification Create one state variable of type mtype for each OR-state in the statecharts specification Use the same type of modeling we used for basic state machines where there is one loop and there is a switch statement in the loop with multiple selections –However, this time each selection can correspond to multiple transitions –In case of AND-states we have to do the transitions together for each sub-state

How to model statecharts in Spin? We can model the events using boolean variables –At each iteration of the loop select one event variable and set it to true –At the end of each transition set the event variable to false Following paper discusses how Statecharts models can be translated to Promela (the input language of Spin) in detail: ``Implementing Statecharts in Promela/Spin,’’ Erich Mikk, Yassine Laknech, Michael Siegel, Gerard J. Holzmann, Proceedings of the WIFT’98 Workshop

Implementing Statecharts in Promela First, the authors formally define a model called Extended Hierarchical Automata (EHA) EHA are very much like statecharts but they are simpler in a couple of ways –The transitions only happen between states that are at the same hierarchy level –Effects of a transition at the lower levels of the hierarchy is specified explicitly as part of the transition –Some advanced features of statecharts (such as history states) are not covered by EHA

Extended Hierarchical Automata (EHA) An EHA consists of a set of sequential automata (these are like regular state machines) –A sequential automaton consists of a set of states, and initial state, a set of transition labels and a transition relation There is a unique root sequential automaton Composite states are modeled by mapping states of a sequential automata to a set of sequential automata –An OR-state is mapped to a single sequential automaton representing its sub-states –An AND-state is mapped to multiple sequential automata (one for each sub-state), corresponding to concurrent execution

Transitions in a EHA Transitions in a EHA can only have their source and destination states in the same sequential automata In addition to source and destination states, the transitions also specify –Source restriction, that restricts the enabledness of the transition in sub-states of the source state –The transition guard that consists of events and assertions in the form In(state) combined with logical connectives –A set of generated events –Target determinator, that identifies which sub-states of the destination state will be entered when the transition is taken

Translation of EHAs to Promela Translation of EHAs to Promela is done as follows: For each sequential automata in EHA with n states, a variable with n+1-values is created –n-values to model the states of the sequential automata, and an extra state to model the case where the automaton does not have an active state in the current configuration Each event is modeled by one boolean variable

Translation of EHAs to Promela In order to model transitions from one configuration of the EHA to another configuration, two copies of state and event variables are needed: –pre- variables denote the state before the transition is taken –post- variables denote the state after the transition is taken

Translation of EHAs to Promela In order to do verification, it is necessary to model the system as a closed system This means that external events are converted to internal events by adding state machines with self-loops that generate such events

Translation of sequential automata to Promela This is done using switch statements as we discussed earlier in translation of basic transition systems to Promela First a switch statement is used to determine which state is active, then another switch statement is used to figure out which transition will be taken, and, finally the effect of the transition is implemented by updating the post- variables Since each state of a sequential automata in an EHA can have other sub-automata denoting its sub-states, if no transition is enabled in the current automaton, then the control is passed to its sub-automata to figure out if the current events will trigger a transition in its sub-states

Translation of sequential automata to Promela Execution of a transition must be enclosed within a atomic block to indicate that execution of a transition is done atomically (i.e., there are no intermediate states during execution of a transition) There is an initialization phase where the states of the automata are initialized by traversing the state-hierarchy in a depth-first-manner –the state of the root sequential automaton is set to its default state and all sub-automata of that default state are similarly activated, the variables implementing control states of all other automata are set to the respective non-active states and event variables are set to false – this must also be done within an atomic block

Translation of sequential automata to Promela At the end of the execution of each step –The resulting post-state is copied to the pre-state for the calculation of the next-step. –Post-state variables are reset (as in the initialization phase variables implementing control states of automata are set to the respective non-active states and event variables are set to false).