GUESSING, MODEL CHECKING AND THEOREM PROVING OF STATE MACHINE PROPERTIES – A CASE STUDY ON QLOCK

It is worth understanding state machines better because various kinds of systems can be formalized as state machines and therefore understanding state machines has something to do with comprehension of systems. Understanding state machines can be interpreted as knowing properties they enjoy and comprehension of systems is interpreted as knowing whether they satisfy requirements. We (mainly the second author) have developed a tool called SMGA that basically takes a finite sequence of states from a state machine and generates a graphical animation of the finite sequence or the state machine. Observing such a graphical animation helps us guess properties of the state machine. We should confirm whether the state machine enjoys the guessed properties because such guessed properties may not be true properties of the state machine. Model checking is one possible technique to do so. If the state machine has a fixed small number of reachable states, model checking is enough. Otherwise, however, it is not. If that is the case, we should use some other techniques to make sure that the system enjoys the guessed properties. Interactive theorem proving is one such technique. The paper reports on a case study in which a mutual exclusion protocol called Qlock is used as an example to exemplify the abovementioned idea or methodology.


INTRODUCTION
A state machine is a mathematical structure, which can be used to formalize various kinds of systems, such as concurrent systems, distributed systems and real-time systems.It is worth comprehending a system under development better, which could be reduced to understanding a state machine that formalizes the system.Understanding a state machine could be interpreted as knowing properties the state machine enjoys.The more state machine properties we know, the better we understand the state machine.We (mainly the second author) have developed a tool called SMGA (Nguyen & Ogata, 2017a) that basically takes a finite sequence of states from a state machine and generates a graphical animation of the finite sequence or the state machine, where SMGA stands for State Machine Graphical Animation.Observing such a graphical animation helps us guess properties of the state machine.We should confirm whether the state machine enjoys the guessed properties because such guessed properties may not be true properties of the state machine.Model checking is one possible technique to do so.If the state machine has a fixed small number of reachable states, model checking is enough.Otherwise, however, it is not.If that is the case, we should use some other techniques to make sure that the system enjoys the guessed properties.Interactive theorem proving is one such technique.
This paper reports on a case study in which Qlock, a mutual exclusion protocol, is used to exemplify the abovementioned idea or methodology.The paper is an extended and revised version of the paper (Aung et al. 2018) presented and published at ICSCA 2018.Qlock can be regarded as an abstract version of the Dijkstra Binary Semaphore.Qlock is first formalized as a state machine, which is specified in Maude (Clavel et al., 2007), a rewriting logic-based computer language and tool.Finite sequences of states can be generated from the Maude specification of Qlock.From finite sequence of states, SMGA produces graphical animations of the state machine formalizing Qlock.The graphical animations help humans guess interesting characteristics occurring in the graphical animations.Maude is equipped with model checking facilities, one of which is the search command that can be used as an invariant model checker.This paper only focuses on invariant properties of state machines because invariant properties are the most fundamental and often used as lemmas to prove other classes of properties, such as leads-to properties.Guessed characteristics are formalized as invariant properties so that the search command can be used to check if the state machine enjoys them.We then use theorem proving to formally verify that the state machine surely enjoys the invariant properties by writing what are called proof scores (Goguen, 1990;Ogata & Futatsugi, 2003) in CafeOBJ (Diaconescu & Futatsugi, 1998), an algebraic specification language and tool.Note that both Maude and CafeOBJ are direct successor of OBJ3 (Goguen, et al., 2000), the most famous algebraic specification language and tool, and then are sibling languages and tools.
The rest of the paper is organized as follows: RELATED WORK in which some related work is mentioned; PRELIMINARIES in which some preliminaries, such as state machines, are mentioned; METHODOLOGY in which we report on the case study where Qlock is used to exemplify the methodology; CONCLUSION in which we conclude the paper.
All files, such as specification of Qlock in Maude, used in the paper are available on the webpage: http://www.jaist.ac.jp/~ogata/code/gmctp-qlock/The files are (1) a template picture of Mod3 (an example used in PRELIMINARIES) for SMGA, (2) a template picture of Qlock for SMGA, (3) an/ input file to SMGA for Mod3, (4) an input file to SMGA for Qlock, (5) specification of Mod3 in Maude, (6) specification of Mod3 in CafeOBJ (including proof score), (7) specification of Qlock in Maude, (8) specification of Qlock in CafeOBJ, and (9) seven files of proof scores for seven Qlock properties.On the website, you can find the link to SMGA.

RELATED WORK
Qlock has been used as one example to demonstrate how to prove that systems formalized as state machines enjoy properties by writing proof scores in CafeOBJ.How to write proof scores in CafeOBJ showing that Qlock enjoys the mutual exclusion property (referred as Prop. 1 later in this paper) and a lemma needed (referred as Prop. 2 later in this paper) is described in (Ogata & Futatsugi, 2008, 2013).Liveness properties as well as invariant properties can be formally verified by writing proof scores in CafeOBJ (Ogata & Futatsugi, 2013;Preining, 2014;Yoshida, 2015).
A graphical user interface for Maude-NPA has been developed (Santiago, 2009).Maude-NPA is a high-level security protocol analysis language and system implemented on the top of Maude.The graphical user interface is dedicated to Maude-NPA and then cannot be used for our purpose, namely that graphical animations of state machines can be displayed, helping humans guess properties of the state machines based on the graphical animations.
Specification animation has been actively studied.Specification animation means making formal specification executable by translating formal specifications into executable programs because most formal specification languages are not executable.Specification animations have been used to inspect formal specifications (Li & Liu, 2016), to monitor software through formal specification animation (Liang, et al., 2016), to validate formal models by refinement animation (Hallerstede, et al., 2016) and to make a specification-based testing better (Nagoya & Liu, 2017).Maude is inherently executable and then it is unnecessary to translate Maude specifications into executable programs.
Some model checkers, such as Alloy (Jackson, 2012) and PAT (Sun, 2009), are equipped with some graphical facilities such that counterexamples are graphically displayed.Human users are allowed to interact with such graphically displayed counterexamples, such as forward and backward step execution and investigating each state.Their graphical animations of counterexamples, however, have not been used to help humans guess properties of state machines.
Few researches have been conducted in which graphical animations of state machines are used to help human users guess or conjecture lemmas needed to complete formal proofs.The case study reported in this paper exhibits a positive potential that graphical animations of state machines could be used for that purpose.There are, however, a lot to do left so as to make sure that our claim that graphical animations of state machines can help human users conjecture useful lemmas for theorem proving would be true.One of them is to conduct more case studies.We (mainly the second author) have been conducting a case study in which it is theorem proved that MCS (Mellor-Crummey & Scott, 1991), a list-based queuing mutual exclusion protocol, enjoys the mutual exclusion property (that corresponds to Prop. 1 of Qlock).The proof requires many lemmas.As a preliminary research, the second and third authors guessed and confirmed some MCS properties with SMGA and Maude (Nguyen & Ogata, 2017b).MCS is not just a laboratory-level mutual exclusion protocol but has been really used in many Java virtual machines.This is why Mellor-Crummey & Scott were awarded the 2006 Edsger W. Dijkstra Prize in Distributed Computing.

PRELIMINARIES
A state machine consists of a set of states, the set of initial states and a binary relation over states.An element is called a (state) transition and may be written as , where is called a successor state of with respect to (wrt) .The set R of reachable states wrt is inductively defined as follows: and if and , then .A state predicate is called an invariant property wrt if and only if (iff) holds in all reachable states wrt , namely .States can be expressed in various ways.States are characterized by some values and then it suffices to observe those values in a way to express states.We use two ways to express states.The first way to do so in to record those values in namevalue pairs called observable components, which are similar to entries of maps or dictionaries and states are expressed as associative-commutative collections (called soups) of observable components.For example, is a soup of observable components used for Qlock, in which there are six observable components.For example, is an observable component where is the name and is the value, meaning that the process is at label .The second way to do so is to use functions (called observers) that take states and some other parameters and return values that characterize states.For example, we can use an observer that takes a state and a process ID and returns the label at which the process is.Let us consider a simple system called Mod3, which will be formalized as a state machine .Mod3 has one value referred as that is a natural number and whose initial value is .Each state of Mod3 can be expressed as one observable component , where is the name and is the value.is , where is the set of natural numbers.is , where there is one initial state .is .Note that is not finite, while is .We suppose that the function takes and returns and we can guess that is an invariant property wrt .Maude makes it possible to use any user's preferred notation to express states.For example, we can use exactly the same notation to express states of as we used in the last paragraph: . As described, generally, soups of observable components are used to express states.Note that a single observable component is a singleton soup that only consists of the observable component.Transitions are specified in terms of rewrite rules.For example, is specified as the following rewrite rule: where is a Maude variable of natural numbers.Given a state s, {s} obtained by enclosing s with { and } is called a configuration.Rewrite rules specifying transitions are written as those from configurations to configurations so as to avoid some subtle issues.The rule says that if , then is incremented.Otherwise, the value of the observable component is .The Maude search command can be used to model check invariant properties wrt a state machine.It is in the form: where is a Maude specification of a state machine under model checking, is a given state (typically an initial state of the state machine), is a pattern and is a condition.The search command searches the reachable states from for at most states that can match and make true.Typically, is and the nagation of the state predicate used to express the invariant property concerned is expressed as and .The condition part " " can be omitted.The invariant property wrt can be model checked with the search command as follows: where equals .Maude does not find any counterexamples, and then because there are only three reachable states from , which is the only initial state of , we have formally verified that enjoys the invariant property.From the Maude specification of , a finite sequence of states can be generated.For example, the following is an example: where the sequence consists of seven states, the leftmost one is the first (initial) state and the rightmost is the final one.For each state, a picture could be designed and drawn.For , and , for example, the following three pictures are designed and drawn, respectively: Let sp0, sp1 and sp2 be the three pictures, respectively.From the finite sequence of states, then, we can generate the finite sequence of pictures: Such a finite sequence of pictures can be regarded as a movie film.Playing such a movie film, we can watch a graphical animation of state machines.This is the basic idea on which SMGA, a state machine graphical animation tool, produces graphical animations of state machines.Note that we do not need to draw all pictures for all possible states but it suffices to design and draw one template picture, for example, for , and then SMGA automatically produces each concrete state picture.Once a template picture is designed and drawn, basically feeding a finite sequence of states, SMGA produces a graphical animation of the finite sequence.For example, from the finite sequence of states, the graphical animation in which the following seven pictures appear sequentially in the order is produced: Observing the animation, we can guess that the value never becomes three or greater, namely that the value is always less than three, although we have already confirmed (and actually verified) this with Maude.
CafeOBJ can be used to theorem prove that a state machine enjoys an invariant property by writing what are called proof scores.To this end, it is necessary to specify a state machine in CafeOBJ as what is called an observational transition system (OTS) style.As briefly mentioned, in the OTS style, each value that characterizes states is observed by applying a function called an observer to the states, a set of transitions is represented by a function called an action (or a transition), and how to change each value that characterizes states by applying an action to the states is specified in terms of equations.
is specified in CafeOBJ as an OTS style as follows: is the sort (or type) representing the set of reachable states that are constructed from the constant and the function as indicated by that stands for constructor.The constant represents an arbitrary initial state.is the sort representing the set of natural numbers.In this paper, a sort and the set denoted by the sort are interchangeably used.In this example, there is one initial state.The function is an action, which is the only one in this example.The function is an observer, which is the only one in this example.The first equation says that the value observed by the observer in the initial state is 0. is a variable of .The second equation says that in the successor state obtained by applying the action to S, the value observed by the observer becomes if is less than , and it becomes otherwise.
Let us define the following state predicate: We can theorem prove that inv1 is an invariant property wrt by structural induction of the reachable state.The proof is first divided into the base case and the induction case.For the base case, we write the following program in CafeOBJ that is called (a fragment of) proof score: where is the CafeOBJ specification of , the command makes a given specification available, the command indicates the end of the use of the module and the command reduces (or simplifies) a given expression (term) by using equations as left-to-right rewrite rules.CafeOBJ returns for this proof score, meaning that the base case has been successfully proved.For the induction case, we write the following proof score in CafeOBJ: where the constant of Sys represents an arbitrary state.The equation is the induction hypothesis but is not used as a left-to-right rewrite rules as indicated by the attribute.Instead, the induction hypothesis is used as in " ." CafeOBJ does not return true for this proof score, meaning that we need to do some more to complete the proof.Typically, there are two kinds of things to do: (1) case splitting and (2) lemma conjecture and use.For this specific example, the induction case is split into three sub-cases based on and , which correspond to the following three fragments of proof score: CafeOBJ returns true for each of the three fragments, but the first sub-case needs one lemma about natural numbers, which is as follows: where is a CafeOBJ variable of natural numbers.The lemma is written as a conditional equation, which says that if is true, then is true.Accordingly, we have successfully proved that inv1 is an invariant property wrt .

METHODOLOGY
Qlock is a mutual exclusion protocol and can be regarded as an abstract version of the Dijkstra Binary Semaphore.The pseudo-code for each process as follows: where is a queue of process IDs shared by all processes participating in Qlock and is atomic in that the functions , and for queues are atomic.We suppose that queue is used in neither "Remainder Section" and "Critical Section."Each process is located at (remainder section), (waiting section) or (critical section).Initially, each process is located at and queue is empty.When a process wants to enter "Critical Section," first enqueues its ID into queue, next waits at until the top of is , then enters "Critical Section" if the top of is , and finally goes back to "Remainder Section," which is repeated.
One desired property Qlock should enjoy is what is called the mutual exclusion property, which is that there is always at most one process in "Critical Section."Some properties of a state machine formalizing Qlock including the mutual exclusion property will be guessed based on graphical animations of , confirmed by model checking and theorem proved.

Specification of Qlock in Maude
The values that characterize states of are the value (a queue of process IDs) stored in and the each process location ( , or ).When there are five processes , , , and , each state is expressed as where and each are names, and each are values, is a queue of process IDs, and each is , or .Initially, is empty and each is .Let be the expression (term) denoting the initial state.
is specified as the following rewrite rules: where Q is a Maude variable of process ID queues, I is a Maude variable of process IDs and S is a Maude variable of states (or state fragments).denotes a queue such that I is the top element and Q is deq(I Q).For example, is the queue such that , and are the first, second and third elements and is the empty queue.Let refer to the Maude specification of .

Guessing and Confirmation of some Qlock Properties
The picture of the initial state used by SMGA is shown in Fig. 1.There are three rectangles that correspond to , and , respectively.The picture allows us to immediately recognize that there are five processes in and no process in both and .Because a process moves to , and from , and , respectively, there are three arrows from the former to the latter, respectively.
is represented as a long pentagon laid down such that its head faces right.In the initial state, is empty and then there is nothing in the pentagon.If there are some in the pentagon, what is located at the right-most is the top element of .
We generate a finite sequence of states such that it consists of 1000 states based on the Maude specification of Qlock with Maude, feeding it to SMGA that produces the graphical animation of the sequence of states.The th state in the sequence is expressed as .Fig. 2 shows the six states in row from to .Observing the graphical animation produced by SMGA makes us guess that there is always at most one process at cs.For example, among the states shown in Fig. 2 there is one process in and , and there is no process in the other four states.This guessed property is called Prop. 1 (which is actually the mutual exclusion property).The Maude search command can be used to confirm Prop. 1 as follows: The search tries to find a state such that there are two processes and whose locations are and , respectively, and it is not the case that if is , then is not , namely that both and are cs.Maude checks all possible combination of two processes and but not some specific combinations, such as and .No counterexample is found and then Qlock enjoys Prop. 1 (the mutual exclusion property) when there are five processes.Note that the model checking result does not guarantee that Qlock surely enjoys the Prop. 1.For example, the result does not guarantee that Qock enjoys Prop. 1 when there are 100 processes.The animation makes us recognize that whenever there is a process at cs, its process ID is the top of queue.For example, please take a look at and in Fig. 2. The guessed property is called Prop. 2, which is confirmed by the following search command: The search tries to find a state such that there is a process whose location is , the content of queue is , and it is not the case that if is , then the top of is .No counterexample is found and then Qlock enjoys Prop. 2 when there are five processes.The animation also makes us recognize that whenever a process is at rs, it is not in .For example, please take a look at the five states from s994 to s998.The guessed property is called Prop. 3, which is confirmed by the following search command: The search tries to find a state such that there is a process whose location is , the content of queue is , and it is not the case that if is , then is not in .No counterexample is found and then Qlock enjoys Prop. 3 when there are five processes.
The animation makes us guess some more properties as well, among which are as follows:  Prop.4: Whenever a process is not in queue, it is at rs.  Prop.5: Whenever a process is at ws or cs, it is in queue. Prop.6: Whenever a process is in queue, it is at ws or cs.The three guessed properties are confirmed by the following three search commands: using all equations except for those annotated as as left-to-right rewrite rules.Feeding the proof score fragment into CafeOBJ, CafeOBJ returns true as the result, meaning that the case is discharged.
To discharge case (1), the case needs to be split into multiple cases.First case (1) is split into two cases: (1.1) and (1.2) .Case (1.1) also needs to be split into two cases: (1.1.1)(meaning that is empty) and (1.1.2) , where is a fresh constant of and is a fresh constant of (meaning that queue(s) is not empty).For case (1.1.1),the following proof score fragment is written: Feeding this into CafeOBJ, CafeOBJ returns true.
Case (1.1.2) also needs to be split into two cases: (1.1.2.1) and (1.1.2.2) .For case (1.1.2.1), the proof score fragment is as follows: Feeding this into CafeOBJ, CafeOBJ returns , where is the exclusive or operator.If is false, then the result becomes true.Observing the graphical animation of , there is at most one occurrence of each process ID in queue.Therefore, we can guess the 7 th property:  Prop.7: For each process ID , let be the queue obtained by deleting from and then it is always the case that there is no occurrence of in .If there is no occurrence of in , then is the same as .This guessed property can be confirmed by Maude as follows: where takes a queue and a process ID and returns the one obtained by deleting the first occurrence of the ID from the queue.The search does not find any counterexamples.Prop.7 is specified in CafeOBJ as follows: inv7 is used in the proof score fragment for case (1.1.2.1) as follows: Feeding this into CafeOBJ, CafeOBJ returns true.
For case (1.1.2.2), the proof fragment is as follows: Feeding this into CafeOBJ, CafeOBJ returns .For this case, we cannot use inv7 because we assume .But, we also assume that is the top of .Therefore, we can use as a lemma in the proof score fragment as follows: Feeding this into CafeOBJ, CafeOBJ returns true.

CONCLUSION
We conjecture that graphical animations of state machines help human users guess or conjecture non-trivial properties of state machines, which could be used to complete formal proofs of theorems.Although model checking is convenient as well as useful to confirm guessed properties, it is not enough because state machine may not have a fixed small number of reachable states.If that is the case, interactive theorem proving is one possible technique to tackle the situation.The case study reported in the paper supports our claim to some extent.To support our claim more, we should conduct some more case studies as mentioned in the last section.

Figure 2 .
Figure 2. Six states in row from s993 to s998.
Case (1.2) can be discharged likewise.It needs to use as a lemma but does not need to use .The base case can be straightforwardly discharged, and the other two induction cases can be discharged only by case splitting.The other six including can be proved by structural induction on .In addition to those lemmas on , to complete the formal proofs, we need to use the following four lemmas on queues: where and are CafeOBJ variables of and is a CafeOBJ variable of .The first equation says that if equals , then is true and otherwise it is the same as .The second (conditional) equation says that if is not true, then is false.The third equation says that if is different from ,