Integration of state machine graphical animation and Maude to facilitate characteristic conjecture: an approach to lemma discovery in theorem proving

Abstract

State Machine Graphical Animation (called SMGA) is a visualization tool that assists formal methods experts in conjecturing characteristics of a protocol/system. The characteristics guessed by using the tool can be used as lemma candidates to theorem prove that the protocol/system satisfies its desired properties. Because previous work has shown that interaction in SMGA is one promising factor to foster assistance, in this paper, we revise SMGA equipping it with various interactive features in order to help human users in conjecturing lemmas. Moreover, we integrate SMGA and Maude, a declarative language and high-performance tool, so that the revised version of SMGA (called r-SMGA) can use some powerful features of Maude, such as parsing associative-commutative binary operators as well as context-free grammars, reachability analysis, and model checking. We conduct a case study with the Suzuki-Kasami protocol to demonstrate the usefulness of these new features. In the case study, some characteristics are conjectured and confirmed with these features. Based on the guessed characteristics and assistance of r-SMGA, we successfully prove that the protocol enjoys the mutual exclusion property. Finally, we propose guidelines that can help users to conjecture characteristics using r-SMGA. Our result shows that the graphical animation approach is useful for lemma conjecture in theorem proving. The formal verification is a part of the case study.

1 Introduction

Formal verification is known as one promising method to guarantee the reliability of software systems. There are two complementary approaches in formal verification: model checking [2] and theorem proving [3,4,5]. The former can automatically check whether or not the system under verification enjoys a given property to some extent and it is often good at detecting a counterexample of the property, but it basically cannot make sure that the system enjoys the property when an infinite number of entities are involved. Even though it would be possible to do so if some advanced techniques, such as abstraction, are used together, such advanced techniques have not yet fully matured. The latter is well-known for its ability in dealing with systems in which an infinite number of entities are involved. The approach, however, often requires human users to conjecture some auxiliary lemmas to complete the proof of the main theorem. The present paper aims to address this lemma conjecture challenge by utilizing human capability in visual perception.

State Machine Graphical Animation (called SMGA) [6] is a tool to visualize protocols/systems based on state machines formalizing them. The main goal of SMGA is to make formal methods experts able to conjecture characteristics of the protocols/systems that can be used as lemma candidates to prove that they enjoy some desired properties in theorem proving. Note that it is necessary to prove any characteristics used as lemmas. The tool uses visual information because visual perception is one of the human strengths [7]. Interaction is a substantial aspect of visualization tools from which humans can get insights of what are visualized [8]. Some case studies of SMGA [9,10,11] show that interaction is one promising factor to find non-trivial characteristics. For instance, the authors in [11] have graphically animated an autonomous vehicle intersection protocol [12] with SMGA. By interacting with some objects of graphical animations while observing them, the authors have found characteristics that have not been reported in [12]. Therefore, in the present paper, we aim to revise SMGA to provide new and revised interactive features for human users to conjecture characteristics. The revised version of SMGA hereinafter is referred to as r-SMGA.

SMGA takes a state picture template and a state sequence as inputs. Human users are in charge of designing the state picture template, which is regarded as an important task in SMGA [10]. Then, SMGA generates graphical animations of the state sequence based on the designed state picture template. By observing the generated animations, some non-trivial characteristics can be conjectured. SMGA is equipped with various animation control features so that while observing animations human users can, for example, temporarily pause it and run it step by step. SMGA also provides a pattern matching feature in which human users can find states from a given state sequence that satisfies some condition via regular expressions. In r-SMGA, we integrate SMGA and Maude [13], a declarative language and high-performance tool, so that r-SMGA can use some powerful features of Maude, such as parsing, reachability analysis, and model checking. Subsequently, the pattern matching feature is revised so that context-free grammars can be used instead of regular expressions. Moreover, various interactive features are equipped in r-SMGA, which allow human users to focus on some interesting visual objects as well as to hide some visual objects that are less interesting. r-SMGA provides some visualization designs for commonly used data structures, such as queues and arrays.

Bui and Ogata [10] have given a literature review with some reasons to show that it is not straightforward to conduct experiments involving humans to evaluate visualization tools. Conducting a case study (or a few case studies) is a common practice to evaluate newly proposed formal techniques and tools supporting them.¹ Therefore, in this paper, we conduct a case study with the Suzuki-Kasami distributed mutual exclusion protocol (Suzuki-Kasami protocol) to demonstrate the usefulness of the new and revised features in r-SMGA. We first design the state picture template for the protocol, and then based on observing some animations generated by the tool, some non-trivial characteristics of the protocol are conjectured by using our new and revised features and some tips proposed in [10]. Those characteristics are then checked by the Maude search command integrated inside r-SMGA, filtering out the incorrect characteristics.

The present paper shows one evidence that r-SMGA is useful for the main goal, helping formal experts to find characteristics used as lemma candidates in theorem proving. In this paper, which is an extended version of [1], we use proof scores [14] in CafeOBJ [15] and a proof generator called CafeInMaude Proof Generator (CiMPG) [16] to formally verify that the Suzuki-Kasami protocol enjoys the mutual exclusion property based on the guessed characteristics and assistance of r-SMGA. CafeOBJ is an algebraic specification language and system, a sibling language of Maude, and proof scores are proof plans written in CafeOBJ. CafeOBJ has two implementations: one is implemented in Common Lisp, while the other is implemented in Maude [17]. The latter, called CafeInMaude, is used in our case study. CiMPG takes proof scores and generates proof scripts that can be checked by a proof assistance called CafeInMaude Proof Assistant (CiMPA). Most of the lemmas used are constructed by simplifying the guessed characteristics, while the rest are constructed based on some features of r-SMGA. Moreover, based on our experiences, we propose guidelines to use r-SMGA to conjecture characteristics (especially characteristics in the form of implication) of protocols/systems. Our result shows that the graphical animation approach is useful for lemma conjecture in theorem proving. To sum up, Fig. 1 displays the flow diagram of our approach with r-SMGA.

Fig. 1

A flow diagram of our approach with r-SMGA

The contributions of the paper are summarized as follows:

• 1. We revise SMGA to r-SMGA where we provide some interactive features for (i) controlling visual objects of the state picture template and (ii) analyzing data with pattern matching features by integrating r-SMGA and Maude (Section 5). We conduct a case study with the Suzuki-Kasami protocol to demonstrate the usefulness of those features (Section 6). Note that this contribution has been reported in [1] and the present paper is an extended version of [1] as written.

• 2. Based on the guessed characteristics and assistance of some features of r-SMGA, we formally verify that the Suzuki-Kasami protocol enjoys the mutual exclusion property to demonstrate the usefulness of new features of r-SMGA in particular and potential of our approach (graphical animations) to lemma conjecture in interactive theorem proving in general (Section 7).

• 3. We propose guidelines used as a generic strategy of how to use r-SMGA to conjecture characteristics of protocols/systems (Section 8).

The rest of the paper is organized as follows. Section 2 discusses the related work. Section 3 mentions some preliminaries such as state machines, Maude, SMGA, CafeOBJ, and proof scores, where a simple mutual exclusion protocol is used. Section 4 introduces the Suzuki-Kasami protocol and its specification in Maude. In Section 5, we describe the ideas of the new and revised features in r-SMGA. In Section 6, some characteristics of the Suzuki-Kasami protocol are guessed and confirmed by using the new and revised features. In Section 7, we describe how we use the guessed characteristics and some features of r-SMGA to successfully prove that the Suzuki-Kasami protocol enjoys the mutual exclusion property. Section 8 introduces and explains the details of our proposed guidelines to conjecture characteristics of protocols/systems using r-SMGA. Finally, we show the meaningfulness of our approach and conclude the present paper in Section 9.

2 Related work

Tree graphs are a common kind of diagram to visualize some pieces of information that link together. Hernando et al. [18] have proposed a novel method using a tree graph to visualize huge information from related documents, such as news. Keywords or sentences are considered as nodes that can be seen as raw texts or related images. There is one main node that is displayed as a picture containing related texts and images. The other nodes are displayed as raw texts or displayed in the same way as the main node such that the main node is displayed larger than the others. Users can observe nodes and navigate the graph to understand the relations between such nodes. When users navigate the graph, the main node is updated to let users mainly focus on such node. ABETS [19] is a prototype for checking the correctness of Maude programs. The main purpose of the work is to improve the diagnosis of erroneous Maude programs. It uses tree graphs to visualize state sequences when nodes and edges correspond to states and rules, respectively. If an error occurs, the tool generates a tree graph that contains states which lead to the error. To understand the error, users can observe the paths and click on states to expand the information of such states displayed as raw texts.

There are many attributes of animations that can help humans to recognize some relations of visual objects. In the present paper, we investigate two attributes: subitizing and the law of common fate of the Gestalt principle. In the psychology field, subitizing is a term to introduce the ability of humans to enumerate a small number of items rapidly and accurately. The terminology was first used in [20] to distinguish it from counting that is time-consuming and error-prone, where the subitizing range is fewer than four items and the counting range is more than four items [21]. Many studies have shown that some factors can expand the subitizing range, such as grouping [22], bilateral and two-item advantage [23]; and the original subitizing range (1-3) is still the fastest and the most accurate in the experiments. The law of common fate (LCF) [24] is one of the Gestalt principles and it is the only one that can deal with dynamic (i.e. animations) properties instead of static properties [25]. This law states that visual elements that move with the same velocity (i.e. same speed and same direction) are perceived as the same group. The work [26] has conducted two empirical experiments to demonstrate that LCF is not restricted to mere motion and some dynamic visual properties (such as luminance and size) have been affected also. In the second experiment, participants are required to observe some animated scatterplots representing the change of data and answer some questions related to group, such as “what patterns do you see?” and “which variable(s) create the most visible patterns?” The result of the second experiment makes the authors claim that the power of dynamic visual variables might shift when applied to more realistic visualization scenarios, such as pattern identification and conjunction search.

The potential for interaction with SMGA has been mentioned in some previous work. The pattern matching feature, which uses regular expressions to help users filter states from the input of SMGA, is introduced as an assistant feature of some proposals for conjecturing characteristics [9, 10]. Interacting with objects in graphical animations while observing them also helps users in conjecturing characteristics [11]. In detail, an autonomous vehicle intersection protocol [12] has been graphically animated with SMGA [11]. Each lane has concurrent and conflict lanes in the intersection. What are involved in the protocol, such as autonomous vehicles and lanes, are visualized. By interacting with SMGA to focus on one lane, its concurrent lanes and the vehicles on the lanes, the authors in [11] have found the characteristic that there exists at most two vehicles on the lanes in the intersection. Note that the characteristic is not reported in [12].

3 Preliminaries

In the section, we introduce some backgrounds to better comprehend our paper such as state machines, Maude, SMGA, and CafeOBJ.

3.1 State machines and Maude

A state machine $M \triangleq \langle S, I, T \rangle$ consists of a set S of states, a set $I \subseteq S$ of initial states, and a binary relation $T \subseteq S \times S$ over states. $(s, s') \in T$ is called a state transition. The set $R \subseteq S$ of reachable states with respect to (w.r.t.) M is inductively defined as follows: (1) for each $s \in I$, $s \in R$ and (2) for each $(s,s') \in T$, if $s \in R$, then $s' \in R$. A state predicate p is an invariant property w.r.t. M if and only if p(s) holds for all $s \in R$. A finite sequence $s_0, \ldots , s_i, s_{i+1},\ldots , s_n$ of states is called a state sequence of M if $s_0 \in I$ and $(s_i, s_{i+1}) \in T$ for each $i = 0, \ldots , n - 1$.

In this paper, to express a state of S, we use a braced associative-commutative collection of name-value pairs although there are many possible ways to express states. Associative-commutative collections are called soups and name-value pairs are called observable components. That is, a state is expressed as a braced soup of observable components. The juxtaposition operator is used as the constructor of soups. Suppose oc1, oc2, oc3 are observable components and then $oc1\ oc2\ oc3$ is the soup of those three observable components. A state that can be characterized by the three observers can be expressed as $\{oc1\ oc2\ oc3\}$. There are many possible ways to specify state transitions. In the present paper, Maude is used to specify state transitions as rewrite rules. Maude can specify complex systems flexibly and is also equipped with several formal analysis techniques, such as reachability analysis and linear temporal logic (LTL) model checking. A rewrite rule starts with the keyword rl, followed by a label enclosed by square brackets and a colon, two patterns (terms that may contain variables) connected with =>, and ends with a full stop. A conditional one starts with the keyword crl and has a condition following the keyword if before a full stop. The following is the form of a conditional rewrite rule:

crl [lb] : l =>$\ r$ if $\ldots$ / $c_i$ / $\ldots$

where lb is a label, l and r are the patterns, and $c_i$ is a part of the condition, which may be an equation $lc_i = rc_i$. The negation of $lc_i = rc_i$ could be written as $(lc_i =$/$= rc_i) =$ true, where = true could be omitted. If the condition $\ldots$ / $c_i$ / $\ldots$ holds under some substitution $\sigma$, $\sigma (l)$ can be replaced with $\sigma (r)$.

Maude provides the search command that allows users to find a reachable state from t such that the state matches the pattern p and satisfies the condition c:

search [n,m] in $MOD$ $:\ t$ =>* p such that c .

where $MOD$ is the name of the Maude module specifying the state machine, n and m are optional arguments stating a bound on the number of solutions and the maximum depth of the search, respectively. n typically is 1, m typically is unbounded (or equivalently omitted) and t typically represents an initial state of the state machine.

Maude provides LTL model checking so that we can check whether a system satisfies a property that is expressed as an LTL formula. Maude can check the system that starts from init satisfies $\varphi$ by the following command:

reduce modelCheck(init, $\varphi$) .

Maude returns true if the system satisfies $\varphi$ provided that init is only considered as its initial state. Otherwise, a counterexample is returned. When the system has multiple initial states, it suffices to conduct the model checking experiment for each initial state so that we can model check that the system enjoys the property.

Fig. 2

Overview of SMGA

Fig. 3

An example of two kinds of visualization in SMGA

3.2 State Machine Graphical Animation (SMGA)

The initial version of SMGA was developed by Nguyen and Ogata and reported in [6]. The main purpose of the tool is to make formal methods experts able to conjecture characteristics of a given protocol so that the characteristics can be used as lemmas to theorem prove that the protocol enjoys some desired properties. There are two phases when using SMGA: preparation and control, as shown in Fig. 2. In the preparation phase, SMGA takes as inputs a state picture template (also called a state picture design in [10]), which is designed by human users, and a state sequence, which is generated by Maude from the protocol formal specification. From the inputs given, SMGA generates graphical animations of the state sequence, and by observing the animations, human users can conjecture some characteristics. In the control phase, users can control the animations, such as temporarily pausing them, changing the running speed, and running them step by step. Additionally, using SMGA we can search some states in a state sequence based on some conditions, which are specified by regular expressions. This feature is called Find Patterns in [9, 10].

SMGA basically provides two kinds of visualization for an observable component: textual display and visual display. The former presents a value of an observable component as text, whereas the latter presents a value of an observable component visualized by what users expect, such as visual objects. Let us consider, for example, an observable component simulating a traffic light, which exhibits a color in either red, yellow, or green. Figure 3 depicts a possible state picture template (on the left-hand side) and a state picture when the light is green (on the right-hand side). In the figure, the text on the top is regarded as a textual display component and the three circles are regarded as three visual display components.

3.3 CafeOBJ and proof scores

CafeOBJ [15] allows us to not only write formal specifications of protocols/systems but also verify that they satisfy some desired requirements/properties by writing and executing what are called proof scores [14]. Model checking only supports the verification of protocols/systems that have a finite number of reachable states, meaning that we need to, for example, limit the number of processes/nodes participating in a protocol/system under checking. Formal verification by writing proof scores [14] does not limit either the number of processes/nodes participating in a protocol/system or the number of sessions, for example, how many times each process/node enters a critical section. This subsection illustrates that advantage through an example with a mutual exclusion protocol. The protocol, called TAS (Test And Set), can be written in pseudo-code as follows:

We suppose that each process is located at either $\textrm{rs}$ (Remainder Section) or $\textrm{cs}$ (Critical Section) and initially at $\textrm{rs}$. locked is a Boolean variable shared by all processes and initially $\textrm{false}$. $\mathrm{test \& set}(locked)$ atomically does the following: if locked is $\textrm{false}$, then it sets locked to $\textrm{true}$ and returns $\textrm{false}$; otherwise, it just returns $\textrm{true}$.

We want to prove that TAS enjoys the mutual exclusion property whose informal description is that there is always at most one process located at the Critical Section (cs), no matter how many processes participate in the protocol and no matter how many times each process tries to enter the cs. We first specify TAS in CafeOBJ and then prove that it enjoys the mutual exclusion property by writing proof scores. To specify the protocol, we declare two operators locked and pc observing the value of locked and the location of each process:

where Sys is the sort (or type) representing the state space, and Pid & Label are the sorts of process IDs & locations such as $\textrm{rs}$ and $\textrm{cs}$, respectively. -19pt

An arbitrary initial state is expressed as a CafeOBJ operator (init). We use two transitions that are expressed as CafeOBJ operators (enter and exit). Those CafeOBJ operators are declared as follows:

where constr says that the three operators are constructors of the sort Sys. The functions pc and locked are defined for init and enter by means of equations as follows:

where S is a CafeOBJ variable of the sort Sys, and P and Q are CafeOBJ variables of the sort Pid. Note that in CafeOBJ, all variables are implicitly universally quantified. The equations for exit are defined likewise.

The mutual exclusion property is then defined by the following predicate:

We prove that the predicate mutex holds in all reachable state S and all processes P and Q, namely that mutex is an invariant property of the state machine formalizing TAS. It is proved by (simultaneous) structural induction on the variable S by writing proof scores in CafeOBJ. There are one base case and two induction cases. The following is the proof of the base case written in CafeOBJ, which is called a proof score fragment (or just a fragment):

where TAS is the CafeOBJ module in which the specification of TAS and the predicate mutex are available, open makes the given module available, close stops the use of the module, and red (an abbreviation of reduce) reduces the given term by applying equations. p and q are fresh constants of the sort Pid representing arbitrary process IDs (which are possibly equal). Feeding this proof score fragment into CafeOBJ, CafeOBJ returns true, meaning that the case is discharged.

There are two induction cases needed to be tackled because we defined two operators with the constr attribute besides init. The proof score fragment for the induction case in which enter is taken into account is as follows:

where s represents an arbitrary state and mutex(s,p,q) is an instance of the induction hypothesis. However, feeding this proof score fragment into CafeOBJ, the returned result is neither true nor false, but instead a complicated term. Case splitting is used to overcome this situation. The proof of one sub-case is as follows:

The equations characterize the sub-case. For example, a Boolean term can be used to split a case into two sub-cases: (1) the term equals true and (2) it equals false. The induction case is first to split into two sub-cases with the Boolean term pc(s,r) = rs (distinguishing whether the process r is in the remainder section in the state s): (1) (pc(s,r) = rs) = true and (2) (pc(s,r) = rs) = false. (pc(s,r) = rs) = true can be replaced with pc(s,r) = rs that is used as the first equation of the fragment. CafeOBJ returns false for this fragment. We need to conjecture a lemma to discharge the sub-case. The lemma is as follows:

Then, in the fragment above, inv1 is used as a lemma to discharge the sub-case as follows:

CafeOBJ now returns true for the fragment. The proof of inv1 needs to use mutex as a lemma. Although the proof of mutex uses inv1 and vice versa, our proof is not circular. The reason is that we use simultaneous (structural) induction to develop our proof. The correctness of this method has been mathematically proved in [14]. Note that it is not straightforward to find lemmas for complex and/or complicated protocols.

4 Suzuki-kasami distributed mutual exclusion protocol

Fig. 4

Algol-like description of the Suzuki-Kasami protocol

We first introduce the Suzuki-Kasami protocol and then describe how to specify it in Maude.

4.1 Protocol description

The Suzuki-Kasami protocol is a distributed mutual exclusion protocol proposed by Suzuki and Kasami [27]. A shared privilege is used in the protocol such that a node cannot enter the critical section unless it owns the privilege. The privilege can be transferred from one node to the others in the network. Suppose that there are N nodes participating in the protocol and $1, \dots , N$ are used for their IDs. A node can send to others two kinds of messages: $\textrm{request}$ and $\textrm{privilege}$. The former is in the form of $\textrm{request}(j,n)$, where j is the sender ID and n is a natural number identifying the request. The latter is in the form of $\textrm{privilege}(q,a)$, where q is a queue of node IDs and a is an N-array of natural numbers.

The protocol execution of each process i consists of two procedures, namely P1 and P2, which are depicted in Fig. 4. $requesting$ is a local Boolean variable of i, which is true if i wants to enter the critical section; otherwise, it is false. $have\_privilege$ is another local Boolean variable of i, which is true if i owns the privilege; otherwise, it is false. $queue$ is a queue of node IDs that are requesting to enter the critical section. $ln$ and $rn$ are N-arrays of natural numbers whose size is N. $ln [j]$ is the request number of the request of node j granted most recently. $rn$ records the largest request number ever received from each other node. For each node i, its $rn$ is always meaningful, while its $queue$ and $ln$ are meaningful only when node i owns the privilege. For each node i, initially, $requesting$ is false, $have\_privilege$ is true if $i = 1$, otherwise, it is false, $queue$ is empty, and each element of $ln$ and $rn$ is 0.

When node i wants to enter the critical section, procedure P1 is invoked. First, $requesting$ is set to true. If i owns the privilege, it moves directly to the critical section. Otherwise, it increments $rn [i]$ and sends the $\textrm{request}$ message $\textrm{request}(i, rn [i])$ to all other nodes. Then, i waits for the privilege. Once the privilege is received, it sets $have\_privilege$ to true and moves to the critical section. When i leaves the critical section, it updates $ln [i]$ by $rn [i]$. Then, $queue$ is updated by checking if each node j waits for entering the critical section ($rn[j] = ln[j] + 1$) and j is not in the queue ($j \not \in queue$). If that is the case, j is put into the queue. After that, if $queue$ is empty, i sets requesting to false and leaves P1, keeping the privilege. Otherwise, $have\_privilege$ is set to false and i transfers the privilege to the node located at the top of the queue by sending the privilege message to that node.

When node i receives the request message in the form of $\textrm{request}(j,n)$, procedure P2 is invoked. Note that procedure P2 is atomically executed. First, $rn [j]$ is updated if it is greater than n. Then, i checks $have\_privilege$, $requesting$ and $rn[j]$, and if they satisfy the conditions described in P2, i sets its $have\_privilege$ to false and transfers the privilege to node j.

4.2 Specification of the protocol in maude

We formally specify the protocol in Maude. Sorts $\texttt{Nat}$, $\texttt{Bool}$, $\texttt{Loc}$, $\texttt{Queue}$, and $\texttt{Array}$ are introduced as the sorts of natural numbers, Boolean values, locations (e.g., l1 and cs), queues of node IDs, and arrays of natural numbers, respectively. A message is in the form of $\textrm{msg}(i,body)$, where i is the receiver and body is either a request or a privilege. A request is in the form of $\textrm{req}(j,k)$, where j is a node ID and k is a request number, while a privilege is in the form of $\textrm{priv}(q,a)$, where q is a queue of node IDs and a is an array. The network is specified as a soup of messages. Let $\texttt{Message}$ be the sort of soups of messages and $\texttt{void}$ denote the empty soup.

The observable components used to formalize the Suzuki-Kasami protocol are classified into two groups: (1) those storing values independent from each node, such as the locked observable component used to formalize TAS in Section 2, and (2) those storing values dependent on each node, such as the pc observable component. There are three observable components in group (1), while there are seven observable components in group (2) for each process. The observable components in group (1) are as follows:

• (nw: ms) says that the network is ms, a soup of messages. Initially, ms is empty.

• (queue: q) says that q is the meaningful queue. Initially, q is empty.

• (ln: a) says that a is the meaningful ln. Initially, a is the natural number array of size N such that each element is 0.

The observable components in group (2) for each node i are as follows:

• (pc[i]: l) says that node i is located at location l. Initially, l is $\textrm{rem}$.

• (have_privilege[ i ]: b) says that node i has the privilege when b is true and does not otherwise. Initially, b is true if $i = 1$ and false otherwise.

• (requesting[i]: b) says that node i wants to enter its critical section if b is true and does not otherwise. Initially, b is false.

• (queue[i] : q) says that the node i’s $queue$ is q. Initially, q is empty.

• (rn[i]: a) says that the node i’s rn is a. Initially, a is the natural number array of size N such that each element is 0.

• (ln[i]: a) says that the node i’s ln is a. Initially, a is the natural number array of size N such that each element is 0.

• (idx[i]: j) says that the node i’s loop variable is j. Initially, j is 1.

We divide the protocol execution into 13 regions as shown in Fig. 4. The name of each region is shown on the left side, such as $\textrm{try}(i)$ and $\textrm{exit}(i)$. We suppose that each node is located at one of 12 regions in P1. One region is expressed as one transition that is written as one rewrite rule in Maude. Thus, there are 13 rewrite rules in the formal specification of the protocol in Maude. For example, the rewrite rule (whose label is updateQueue) that corresponds to the region $\textrm{updQ}(i)$ is as follows:

If the node I’s loop variable K equals N, then node I moves to l8 from l7, exiting the corresponding loop in the pseudo-code, and K is set to 1. Otherwise, node I stays at l7 and K is incremented to handle the next iteration of the loop. If K does not equal I, K is not in Q (the node I’s queue) and the latest node K’s request has not been yet granted (RN[K] == LN[K] + 1), then K is put into Q. Because the node I’s queue is meaningful, the queue observable component stores the node I’s queue and the one stored in the observable component is updated likewise. The other rules work similarly.

5 Features in r-SMGA

We describe how r-SMGA works and explain new and revised features of r-SMGA with their functions in detail.

5.1 Intuitive idea

The main goal of the present paper is to provide interactive features for helping users to conjecture characteristics/properties of a protocol/system for which graphical animations are prepared and controlled by r-SMGA. r-SMGA allows human users to interact with visual objects used in the state picture template, for example, focusing on or hiding them when the users are more or less interested in them. r-SMGA also helps human users to get more insights of a protocol/system by finding the pictures that satisfy some with powerful pattern matching empowered by Maude from its graphical animations. We have integrated r-SMGA and Maude so that r-SMGA can use powerful functionalities of Maude, such as reachability analysis, parsing, and LTL model checking. Moreover, Maude supports context-free grammars and associative and/or commutative binary operators, which can be used for the pattern-matching feature to make r-SMGA more powerful than SMGA, which supports only regular expressions. To this end, we use a server as a bridge to communicate between r-SMGA and Maude. The server uses Maude bindings [28] to communicate with Maude via APIs and uses sockets to communicate with r-SMGA via message passing. r-SMGA’s new features are described in the rest of the section.

Fig. 5

An overview of r-SMGA

5.2 New features

Figure 5 displays an overview of r-SMGA in which light-blue texts refer to the new and revised features. There are three phases when using r-SMGA: preparation, control, and search. The main purpose of the preparation and control phases is to produce an input and an output, while the search phase focuses on analyzing data with the pattern matching feature. In the preparation phase, r-SMGA takes as inputs a protocol formal specification and a state picture template. Note that human users no longer need to prepare a state sequence as in the previous version. Besides, a feature called Special display is additionally provided in the revised version, which can visualize some common data structures such as array and queue.

In the control phase, two new features called Sequence generation and Interaction are implemented. The former can automatically generate a list of state sequences based on the formal specification given. It consists of the following five functions:

• Default generation: The function randomly generates a state sequence whose length is bounded by a controlled number (100 by default). The key idea to implement the function is that from a given state, one among its successor states is randomly selected and appended into the sequence. The chosen successor state is different from the source state so that there is no state repeat in the generated state sequence. The generated state sequence is tagged with an index and added to the list of state sequences generated. Users can select and use any state sequence in the list.

• Update: The function updates a state sequence in the list by randomly generating a new one. Users can reconfigure the generated state sequence length before producing a new state sequence.

• Add: This function works similarly to the function Default generation, except that the generated state sequence length can be configured before generating.

• Clear: The function removes a selected state sequence from the list.

• Reset list: The function reset the list to empty.

Users can utilize the Interaction feature to interact with a state picture template or a state picture while observing the animations. This feature consists of two functions:

• Focus: By using this function, only some selected visual objects are displayed, the remaining visual objects are omitted. It helps users to focus on only the selected visual objects.

• Hide: This function allows users to select to hide some visual objects.

For each of the above-mentioned functions, three more sub-functions, undo, redo, and reset are provided. Undo allows users to cancel the latest action (Focus or Hide), while redo allows users to carry out the latest action again. Reset allows users to go back to the original state picture template. Note that the sub-function reset is different from the function reset list in the sequence generation feature. In addition, users can utilize the Interaction feature, while running some other features.

In the search phase, there are two features called Maude and Pattern matching. In the Maude feature, we provide the following two functions:

• Search command: The function takes as inputs a protocol specification and a Maude search command (as described in Section 3). The function performs searching by calling Maude through APIs. If the number of desired solutions in the search command is one, the function outputs a state sequence leading to the target state from the initial state. If the number is greater than one, the function outputs a list of state sequences, from which users can select and use any of them. If there is no solution, an alert message is output.

• Model checking: The function takes as inputs a protocol specification, an LTL formula, and an initial state. If the formula is not satisfied, a counterexample is output, which is in the form of a state sequence followed by a loop.² Note that when the reachable state space of the protocol specification is huge, the two functions Search command and Model checking may take a long time to produce the results (Figs. 6 and 7).

Fig. 6

A state picture template of the Suzuki-Kasami protocol

Fig. 7

A state picture template of three observable components: pc[i], privilege[i], and requesting[i] for node i, where i = 1, 2, 3

The purpose of the Pattern matching feature is to find states satisfying some conditions from a state sequence. In r-SMGA, the Pattern matching feature is improved based on some advanced features of Maude, making it much more powerful than that of the previous version. For example, we want to find some specific messages in the network that we cannot do with the previous version, because the network is formalized as a soup (an associative-commutative collection) of messages. This feature uses state sequences in the list maintained by r-SMGA and a pattern with a condition written in Maude as the input. The pattern and the condition are similar to the target state and the condition in the Maude search command (as described in Section 3). The output is a collection of states that match the pattern under the condition, or a message “no solution” if there is no such state. The Pattern matching feature has the following three functions:

• Pattern matching on a sequence: Users select one state sequence from the list and fill a pattern with a condition. Then, the function returns a list of states that match the pattern and satisfy the condition from the selected state sequence.

• Pattern matching on some sequences: Users select multiple state sequences from the list and fill in a pattern with a condition, and then the function outputs state sequences that match the pattern and satisfy the condition. Afterward, users can select a sequence in the outputted results to see the states in the sequence that satisfy the pattern and the condition.

• Pattern matching on all sequences: This is the same as the second function provided that all state sequences in the list are selected.

In the search phase, we provide two ways to display the result returned from the Maude and the Pattern matching features: (i) a still picture that includes all states matching a pattern with a condition and (ii) graphical animations of such states. The second way, where the output is displayed as animations, can help human users quickly recognize the difference between such states, which may be useful to conjecture characteristics. It will be demonstrated in the next section. Figure 8 shows some functions that allow us to control the animations when choosing to display the returned result as graphical animations. In the figure, the buttons on the left-hand side are similar to those used for the functions in the control feature. The drop-down list and the button on the right-hand side are the returned result (a list of solutions) and the function to load all states (in the returned result) to the output display, respectively.

Fig. 8

Some functions used when displaying the output as graphical animations

Table 1 summarizes the new and revised features with their purposes and functions.

Table 1 Summary of new and revised features

6 Experiment

Based on what we have explained in the previous section, we apply the new and revised features to the Suzuki-Kasami protocol and show the usefulness of those features in conjecturing characteristics.

6.1 Applying the new and revised features to the suzuki-kasami protocol

To illustrate how to use the new and revised features of r-SMGA and demonstrate their usefulness, the Suzuki-Kasami protocol is used as a case study. Let us suppose that there are three nodes participating in the protocol. In the preparation phase, we prepare the protocol formal specification in Maude, which has been described in Section 4.2, and a state picture template, which has been shown in Fig. 6. We borrow some visualization techniques from [9] and redesign some observable components such as have_privilege, requesting, queue, rn, and ln. Based on some tips from [10], observable components should be visual as much as possible, and so we redesign have_privilege and requesting using the visual display. We use the Special display feature to visualize the queue queue and two arrays rn & ln. For other observable components, readers are referred to the work [9]. Figure 9 shows the revised design for the five observable components. In the figure, the three blue rectangles and the three exclamation marks on the right-hand side represent the values of have_privilege and requesting of the three nodes, 1, 2, 3. We will describe later how exactly the blue rectangles express the have_privilege[ i ] observable components and the exclamation marks express the requesting[i] observable components. The three circles with different colors inside the blue rectangles represent the labels of the three nodes. Let us look at the nine light-pink rectangles. From top to down, three light-pink rectangles aligned horizontally with three numbers inside represent the rn observable component of each of nodes 1, 2, and 3. The numbers 1, 2, and 3 on the top of the figure represent indices of arrays starting from 1. The three light-orange rectangles aligned horizontally represent the ln observable component in which the meaningful array ln is stored, where the text “LN" appears right next to the three light-orange rectangles. The light-orange wide right-arrow represents the queue observable component in which the meaningful queue is stored. Figure 10 shows a case in which the have_privilege[1], have_privilege[2], and have_privilege[3] observable components are true, false, and false, respectively; and the requesting[1], requesting[2], and requesting[3] observable components are false, true and true, respectively.

Fig. 9

The design of observable components: have_privilege[i], requesting[i], RN[i] (for node i, where i = 1, 2, and 3), LN, and queue

Fig. 10

An example of when the value of have_privilege[1] is true, have_privilege[2] is false, have_privilege[3] is false, requesting[1] is false, requesting[2] is true, and requesting[3] is true

In the previous version, a queue was used with textual display only. r-SMGA makes it possible to show a queue with the visual display. Human users are supposed to design what visual objects as elements appear at each position in a visual object that represents a (bounded) queue. Because there are three nodes, it suffices that the queue stored in the queue observable component has at most three elements (three node IDs). Thus, there are three positions in the queue and then each of three node IDs can be located at each position in the queue. We use a circle on which a node ID is written as a visual object as a queue element. When the queue is empty, nothing appear at all positions of the queue, while the queue is not full, nothing appears at some positions of the queue. For example, the queue expressed as 2 | 3 | empty, where there are two elements, 2 is the top and 3 is the second (and the last), is visualized as in Fig. 11.

Fig. 11

An example of when the value of queue is 2 and 3 (2 is the top of queue)

In the previous version, an array was shown with textual display only. In the formal specification of the Suzuki-Kasami protocol, an array is expressed as a soup of index-value pairs. For example, the natural number array a of size 3 such that a[1] = 0, a[2] = 1, and a[3] = 0 is expressed as (1 : 0), (2 : 1), (3 : 0). In the previous version, a is shown as the text (1 : 0), (2 : 1), (3 : 0). In the current version, a is visualized as in Figure 12. The figure is the visual object for the ln observable component and the three rn[i] observable components, where $i = 1, 2, 3$, can be visualized likewise.

Fig. 12

An example of when the value of the array is (1 : 0), (2 : 1), (3 : 0)

In the control phase, by using the sequence generation feature, users can generate multiple state sequences. Users can modify the Maude specification to generate new state sequences. Note, however, that even if the specification is modified, the old state sequences are still available in the list maintained by the tool. Users can keep them to compare with new state sequences generated from the modified specification, otherwise, they should be deleted, for example, they can be completely removed by using the function Reset list.

Interaction features and some features in the search phase will be discussed in the next subsections.

6.2 Guessing characteristics with the new features

Some tips for guessing characteristics have been proposed by Bui and Ogata [10]. We summarize those tips and show the usefulness of our new and revised features based on them.

• CC-T1: Concentrating on one observable component, users can find some specific values on it from which users can conjecture some characteristics.

• CC-T2: Concentrating on two different observable components, users can find a relation between them.

• CC-T3: Searching states in which some observable components have some specific values and concentrating on other observable components on those states, users can find some relations on those observable components.

• CC-T4: Investigating conjectured characteristics, users can find some other characteristics.

where CC-T stands for Characteristic Conjecture Tip. The Interaction feature presented in this paper makes it easy to apply the tips CC-T1 and CC-T2 because it allows us to stay focused on some observable components without being disturbed by others. For example, in the Suzuki-Kasami case study, we can focus on the three observable components pc[i], have_privilege[ i ], and requesting[i] of the three nodes as shown in Figure 7 by using the function focus and/or hide. By observing graphical animations, some characteristics are conjectured as follows:

• Characteristic 1: If a node is located at cs, l6, l7, l8, or l9, there does not exist another node located at cs, l6, l7, l8, or l9.

• Characteristic 2.1: There exists a case such that none of the three nodes owns the privilege.

• Characteristic 2.2: When the privilege is owned by a node, it cannot be owned by any other node.

Based on CC-T2, we focus on two of the three observable components shown in the Fig. 7. By observing graphical animations, we conjecture the following characteristics:

• Characteristic 3.1: If a node is located at cs, l6, l7, l8, or l9, the node owns the privilege.

• Characteristic 3.2: If a node is located at l3, l4, or l5, the node does not own the privilege.

• Characteristic 4.1: If requesting of a node is false, the node is located at either rem or l1.

• Characteristic 4.2: If a node is located at either rem or l1, requesting of the node is false.

Fig. 13

A case of using the Pattern matching feature to check whether a privilege message in the network

Fig. 14

Some state pictures found with Pattern matching feature

The Pattern matching feature makes it easy to apply the tip CC-T3. Figure 13 shows how to use this feature to find states in which there exists a privilege message in the network. The top of the figure indicates that we are trying to use the function Pattern matching on all sequences with the number of sequences currently in the list. The pattern (nw: NW:Network) OCs:Config used is written in the rectangle just below “pattern:” and the condition hasPrivilege(NW:Network) used is written in the rectangle just below “condition:”. The pattern is used to find states in which there exists an observable component that matches (nw: NW:Network), where NW:Network is a Maude variable of sort $\texttt{Network}$ declared on-the-fly. Because every state has such an observable component, all states are candidates to be found. The purpose of use of the pattern is to extract the contents, a soup of messages, stored in the observable component. The condition checks whether such a soup of messages has a privilege message. Because a soup of messages is an associative-commutative collection, we need to rely on the associative-commutative pattern matching of Maude, which is one unique feature empowered by Maude. Using CC-T2 and observing the animations of such states shown in Fig. 14, we conjecture the following characteristics:

• Characteristic 5: There exists exactly one privilege message in the network.

• Characteristic 6.1: If there exists a privilege message in the network, no node owns the privilege.

• Characteristic 6.2: If a node owns the privilege, there does not exist a privilege message in the network.

• Characteristic 7: If there exists a privilege message in the network, there does not exist a node located at cs, l6, l7, l8, and l9.

• Characteristic 8: If there exists a privilege message in the network, requesting of the receiver of the privilege message is true.

• Characteristic 9: If there exists a privilege message in the network, the receiver of the privilege message is located at either l4 or l5.

Note that we can conjecture Characteristics 5-9 by observing states satisfying Characteristic 2.1 (we will explain the details of how to conjecture those in Section 8). Characteristic 7 can be guessed by Characteristics 6.1 and 3.1 based on CC-T4.

To this end, by using the Special display feature for the observable components queue, ln, and rn, we can conjecture some characteristics that are relevant to those observable components. First, using CC-T3, we use the Pattern matching feature to search states where queue is not empty. Using CC-T2 and observing graphical animations, such as in Fig. 14, we can conjecture some characteristics as follows:

• Characteristic 10: When node I owns the privilege and node J is the top of the queue of node I, the number at index J of ln[I] is less than the number at index J of rn[J] by one. Figure 15 shows an example of this characteristic where the index J is 1 and the node J is N1.

• Characteristic 11: Each node whose ID is in $queue$ maintained by a node that owns the privilege is located at either l4 or l5.

Note that the above-mentioned characteristics are just some of the characteristics we found. They are used to demonstrate the usefulness of the new and revised features in r-SMGA. There exist other characteristics found that are not mentioned in this paper.

Fig. 15

An example of Characteristic 10

6.3 Confirmation of guessed characteristics based on the new features

We use “to confirm characteristics" to mean to filter out false characteristics among those found with r-SMGA together with its features, etc. with the search command available inside r-SMGA. In the previous version, users can confirm guessed characteristics by running the Maude search command in Maude. In the revised version of the tool, users can do so inside r-SMGA through the function Search command. For instance, to confirm Characteristic 2.1, the following Maude search command is performed through r-SMGA as shown in Fig. 16:

where SKP is the Maude module in which the protocol specification is available, init is an initial state, I and J are Maude variables declared on-the-fly of sort NodeID, and OCs is a Maude variable declared on-the-fly of sort Config. The function tries to find a state such that both nodes I and J own the privilege. The function does not return any counterexample; hence, the guessed characteristic is confirmed.

Figure 17 shows the command for confirming Characteristic 9. In the figure, getRecfromPrivMes takes a soup of messages and returns the receiver node ID of the privilege message in the soup if any. The command does not return any counterexamples and then Characteristic 9 has been confirmed. For the other guessed characteristics, we also confirm them by using Search command.

Fig. 16

An example of using Search command of r-SMGA for Characteristic 2.1

Fig. 17

An example of using Search command of r-SMGA for Characteristic 9

Users need to check guessed characteristics because it is not always the case that a guessed characteristic is correct. For example, we have conjectured that if one node sends a request message to all other nodes, the privilege message will be eventually sent to the node by some other node. We use Model checking to confirm the characteristic by the following LTL formula:

where reqMsgInNw(I) is a proposition which is true if and only if there exists a request message sent by node I in the network. privMsgInNw(I) is a proposition which is true if and only if there exists a privilege message sent to node I in the network. _|->_ and _/_ are Maude operators denoting leads-to and conjunction,respectively. A counterexample is returned, meaning that the guessed characteristic is incorrect. When observing the counterexample [29, 30] by animations, we can understand the situation. Therefore, r-SMGA can be considered as a visualization tool for understanding a counterexample better.

A video in which you can find how to find some characteristics of the Suzuki-Kasami protocol with r-SMGA can be found at: https://www.youtube.com/watch?v=MvyG6nmpOXs

7 Formally proving the mutual exclusion property of the suzuki-kasami protocol with assistance of r-SMGA

This section presents how we formally verify that the Suzuki-Kasami protocol enjoys the mutual exclusion property with the use of some guessed characteristics mentioned in Section 6 and the assistance of some features of r-SMGA while proving. The verification is conducted by writing proof scores in CafeOBJ and running them with its system. Note that we do not restrict how many nodes participate in the protocol and how many times each node tries to enter its critical section. Thus, we formally verify that the protocol enjoys the property no matter how many nodes there are and no matter how many times each node tries to enter its critical section. The result shows not only the usefulness of the new and revised features of r-SMGA but also the potential of our approach (graphical animations) in lemma conjecture.

7.1 Formal specification in CafeOBJ

We first briefly present the formal specification of the protocol in CafeOBJ. Sorts Sys, Network, Queue, Array, and Label are introduced to represent the state space, the network, queues, arrays, and locations at which nodes are located, respectively. The meaning of Sys has been explained in Section 3.3 while the meaning of the remaining sorts is the same as the one described in Section 4. The observers used in the CafeOBJ formal specification are declared as follows:

where NzNat is the sort of non-zero natural numbers, representing node IDs.

The constant init is introduced to represent an arbitrary initial state. Let I is a CafeOBJ variable of sort NzNat, init is defined in terms of equations as follows:

where void, empty, and ia are constants denoting the empty network, the empty queue, and the (initial) array such that each content is 0, respectively.

We specify 13 transitions, where each of them is defined in terms of equations that specify how the values observed by the eight observers change. For example, $\textrm{updQ}(i)$ in Fig. 4 is defined as follows:

where S and J are CafeOBJ variables of sorts Sys and NzNat, respectively. idx(S,I) represents the value of the loop variable of node I in state S,_in_ is an operator defined to check whether the first parameter is in the second parameter, s(_) is the successor function of natural numbers, and c-updateQueue(S,I) is pc(S,I) = l7. The rest of the transitions can be defined likewise.

7.2 Formal verification

Similarly to the TAS case study presented in Section 3.3, we first specify the mutual exclusion property by the following mutex predicate:

and then, we prove that the predicate is an invariant of the state machine formalizing the protocol by writing proof scores in CafeOBJ. Similarly to what has been presented in Section 3.3, we also use simultaneous structural induction on variable S of sort Sys to conduct the formal verification. There are one base case and 13 induction cases (from $\textrm{try}(i)$ to $\textrm{recReq}(i)$ in Fig. 4). As also described in Section 3.3, we use case splitting to make each of CafeOBJ fragments return either true or false. For each case in which CafeOBJ returns false, we need to use lemmas to discharge the case. When proving the mutex property, most lemmas are constructed from the guessed characteristics in Section 6.2. Let us consider a fragment (or a sub-case) of the induction case $\textrm{chkPrv}(i)$ in which false is returned as follows:

where pc(s,p) = l2, ..., havePriv(s,p) = true are our assumptions used to characterize the sub-case (or the fragment). To discharge this fragment, we use inv1 defined as follows:

inv1 is constructed by simplifying the combination of Characteristics 2.2 and 3.1. Combining Characteristics 2.2 and 3.1 (become a complex lemma) is one possible way to discharge this fragment, but it may lead to some unpredicted cases or be stuck. We met such cases when conducting the protocol proposed by Mellor-Crummey and Scott (the MCS protocol) [10, 31], therefore, we do not construct the complex lemma at the beginning. Until now, we do not know whether a complex lemma is better than a simplified lemma and vice versa. Most lemmas used in the verification are constructed in the same way (using a simplification of the guessed characteristics).

There are two lemmas inv6 and inv8 that are constructed in different ways. inv6 is defined as follows:

where del(_,_) is the operator defined to delete a specific message (the second parameter) in the network (the first parameter). inv6 says that if there exists a privilege message M from the network, there is no more privilege messages in the network just after deleting the privilege message M. From inv6, we can derive that there always exists at most one privilege message in the network. The main reason to be able to construct the lemma is to discharge a sub-case as follows:

In the sub-case, CafeOBJ returns a term as follows:

We can use inv6 so that CafeOBJ can return true for the sub-case. Note that this lemma is inspired from Characteristic 5.

Table 2 Proved properties of the Suzuki-Kasami Protocol

Lastly, inv8 is defined as follows:

The meaning of the lemma is similar to some guessed characteristics, such as Characteristics 4.1 and 4.2 and the meaning of this lemma is as follows: when a node is not located at either rem or l1, its requesting is true. However, it took time for us to find that the lemma is crucial. When we use the lemma, we can discharge the most annoying sub-cases we have encountered. We construct this lemma by using some features of r-SMGA. Let us consider a sub-case when proving the induction case $\textrm{recReq}(i)$ as follows:

where node(_) is defined to get the node from the request message denoted re. “...” are assumptions that are not relevant for the current case First, in this sub-case, we make an attempt by using a simplification of the guessed characteristics based on all assumptions (similarly to what we do with most lemmas). The assumptions make us construct some characteristics that are hard or complicated to verify; for example, Characteristic 8 is also one possible way to discharge the sub-case above but we come to need to use some other characteristics about queues and find them hard to predict whether such characteristics would be able to be proved. After we have analyzed the situation, we found that requesting(s,p) is the core source of the situation. If requesting(s,p) is true, we can discharge the case; otherwise, it makes the case become complicated. We have used Pattern matching feature of r-SMGA to search for states that satisfy the condition “requesting is true” and we have finally constructed inv8 by observing graphical animations of such states (the details of how to find this lemma are described in Section 8). To this end, we summarize the properties of the Suzuki-Kasami protocol proved and their lemmas used in Table 2.

CafeOBJ is considered as a semi-formal way to verify that Suzuki-Kasami protocol enjoys the desired property because CafeOBJ does not whether proofs conducted with CafeOBJ are correct, for example, whether case splitting used is correct. Humans may overlook some sub-cases. CiMPG [16] can be used to check whether proof scores are correct with respect to a proof assistant. CiMPG takes proof scores as its input and automatically generates proof scripts that can be checked by CiMPA [16], a proof assistant. We have checked the proof scores made for the verification that the Suzuki-Kasami protocol enjoys the mutual exclusion property with CiMPG and CiMPA. Thus, there is no human error lurking in the proof scores. All proof scores and proof scripts generated from CiMPG are available at: https://gitlab.com/duydang12/skp-cafeobj-cafeinmaude.

8 Guidelines for conjecturing characteristics using r-SMGA

In this section, we start with an example of how we find characteristics in order to better comprehend our idea. Then, we build our idea as guidelines for conjecturing characteristics of a protocol/system using features of r-SMGA.

8.1 Intuitive idea via an example

Based on the tips [10], we have already shown the usefulness of the new and revised features provided by r-SMGA. From the tips and our experience, we aim to find a generic way to conjecture characteristics of protocols/systems by using r-SMGA. Let us start with a situation where we have conjectured some characteristics of the Suzuki-Kasami protocol in Section 6.2. Given the state picture template and the specification of the Suzuki-Kasami protocol, r-SMGA then produces graphical animations. Observing the animations and focusing on the visual representations of the privilege[i] observable components for $i = 1, 2, 3$, we obtain four cases as shown in Fig. 18.

Fig. 18

Four possible cases when focusing on privilege[i] for node i, where i = 1, 2, 3

Based on the second picture from the left in Fig. 18, which indicates that no node owns the privilege, we conjecture Characteristic 2.1. Then, we use the Pattern matching feature to find states that match Characteristic 2.1 and some results are shown in Fig. 14. Observing the animations made from the results and focusing on the network, we observe that there is a privilege message in the network in each state picture of the animations. Therefore, we can guess that if no node owns the privilege, there exists a privilege message in the network. We confirm it with the Search command function. Let us suppose that the confirmed characteristic is denoted as $A \Rightarrow B$, where A and B are “no node owns the privilege” and “there exists a privilege message in the network,” respectively; $\Rightarrow$ is the logical implication. Once again, we use the Pattern matching feature to find states that match B and the results obtained are the same as those shown in Fig. 14. Then, we can conjecture Characteristics 5–9. Repeating the process, we can find other characteristics of the protocol. Note that we can find a new characteristic by the transitive property of implication, namely that if $P \Rightarrow R$ and $R \Rightarrow Q$, then $P \Rightarrow Q$. For example, P, R, and Q are “there exists a node i located at cs, l6, l7, l8 or l9,” “node i owns the privilege,” and “no privilege message in the network,” respectively; $P \Rightarrow R$ and $R \Rightarrow Q$ are Characteristics 3.1 and 6.2, respectively. Then, we can get a new characteristic $P \Rightarrow Q$ stating that “if there exists a node located at cs, l6, l7, l8 or l9, then no privilege message in the network.” Note also that we can create a complex characteristic by combining confirmed characteristics together. For example, if $M \Rightarrow T$ and $N \Rightarrow T$, then (M or $N) \Rightarrow T$. Please see [10] for concrete characteristics conjectured this way.

8.2 Proposed guidelines

Our proposed guidelines can be summarized as follows:

• Step 1: Find as many characteristics as possible by carefully observing graphical animations generated by r-SMGA with the features/functions of r-SMGA, such as focusing and hiding. Characteristics A, B, P, and R in Section 8.1 are examples of such characteristics. Some conditions can be extracted from such characteristics.

• Step 2: Use the Search command function and/or the Pattern matching feature in order to find states that satisfy each characteristic found at Step 1 (or any other steps) or a condition extracted from the characteristic.

• Step 3: By carefully observing the graphical animation of the states obtained at Step 2 and/or the states as still pictures, where a characteristic $D_1$ is used at Step 2 to obtain the states, confirm the guessed characteristics so far to some extent and/or find as many characteristics as possible. Let $D_2$ be one of the characteristics found. Then, $D_1 \Rightarrow D_2$ is one possible characteristic candidate.

• Step 4: Repeat Step 2 with the characteristics, such as $D_1$, found at Step 3, followed again by Step 3, from which new characteristics could be found.

Note that each of guessed characteristics should be confirmed with the Search command function because they may not be true characteristics. Those that are derived from non-true characteristics at Step 2 and Step 3 are less likely to be true characteristics. Note also that it does not suffice just to use the Search command function to judge if the guessed characteristics are true and then it is necessary to formally verify them with theorem proving as we do in Section 7.

Fig. 19

Some state pictures found with the condition “requesting[1] is true”

Let us use how to find inv8 as an example to exemplify the guidelines. inv8(s,i) is as follows: if a node i is located at neither rem nor l1 in a state s, then the value stored in requesting[i] is true in state s. First let us focus on the requesting[i] and pc[i] observable components for $i = 1, 2, 3$. We carefully observe graphical animations, especially, the relation between the values stored in requesting[i] and pc[i]. We notice and guess that the following is likely to be true: if the value stored in requesting[i] is true, then the value stored in pc[i] is neither rem nor l1. This is an example conducted at Step 1.

The condition that the value stored in requesting[i] is true can be extracted from the guessed characteristic. We use the Pattern matching feature to generate states that satisfy the condition. See Fig. 19 for some of the states generated. The figure shows some states that satisfy the condition “requesting[1] is true." This is an example conducted at Step 2.

We then check whether the value stored in pc[i] is neither rem nor l1 by observing the graphical animations made from the states found and/or the still pictures of the states, from which we can confirm the guessed characteristic. This is an example conducted at Step 3.

We can also use “the value stored in pc[i] is neither rem nor l1” as a condition and generates states that satisfy the condition with the Pattern matching feature. This is another example conducted at Step 2. We carefully observe the graphical animations made from the states found and notice that the value stored in requesting[i] is true in each of the states, from which we guess that if the value stored in pc[i] is neither rem nor l1, then the value stored in requesting[i] is true. This is another example conducted at Step 3. The examples conducted at Step 2 and Step 3 is an example conducted at Step 4 as well.

This is how we guess inv8 based on the guidelines.

9 Discussion & conclusion

The present paper shows the potential of our approach (graphical animations) in lemma conjecture in theorem proving. In other words, r-SMGA is demonstrated as a useful assistant to help experts in formal methods to conjecture lemma candidates that can be used for formal verification. Our result shows that (i) formal methods experts can better comprehend a protocol/system (that may help to find suitable lemmas) by specifying it in Maude and CafeOBJ, designing its state picture template, and the guessed characteristics with r-SMGA; (ii) formal methods experts can use some of the guessed characteristics and their variants to discharge sub-cases when doing a formal verification; and (iii) if formal methods experts could find the core source from sub-cases for which false is returned, they can utilize r-SMGA to find suitable characteristics according to our proposed guidelines, which is described in Section 8. Note that we need to prove each of the lemmas used and can find other lemmas for the proofs with r-SMGA as well.

The paper has proposed a way for a lemma conjecture task in theorem proving by utilizing human capability of visual perception, such as graphical animations with r-SMGA. In particular, we have integrated SMGA and Maude so that r-SMGA can use some powerful features of Maude to support in conjecturing characteristics. By using Maude, the pattern matching feature of SMGA has been revised so that context-free grammars, instead of regular expressions, can be used as patterns, and associative-commutative binary operators can also be used in patterns, making it possible to search for states each of which has a network that consists of a privilege message. Because a network is formalized as a soup (associative-commutative collection) of messages, it is impossible to do so with regular expressions.

Some more interactive features have been provided to help users to concentrate on some visual objects in which users are interested. By graphically animating the Suzuki-Kasami distributed mutual exclusion protocol, we have demonstrated the usefulness of new and revised features in conjecturing characteristics using the tips in [10]. Based on the guessed characteristics and assist of r-SMGA, we successfully verify that the Suzuki-Kasami protocol satisfies the mutual exclusion property by writing proof scores in CafeOBJ and executing them with the CafeOBJ system. We have also checked the correctness of the proof scores with CiMPG, a proof generator, with respect to CiMPA, a proof assistant. Finally, we propose a generic strategy of how to use r-SMGA to conjecture characteristics of a protocol/system.

When a protocol/system, such as the Suzuki-Kasami protocol, is graphically animated, the number of active entities, such as processes and nodes, is a few, such as three. For the Suzuki-Kasami protocol used as an concrete example, we use three nodes. Our way to visualize each state of the protocol allows us to immediately recognize how many nodes there are at each location, such as cs (Critical Section), without counting the nodes because of subitizing (mentioned in Section 2). SMGA and its extension, called r-SMGA, make it possible for human users to rely on subitizing to find characteristics, although we heavily depend on state picture templates. This illustrates how important state picture templates are [10]. Some non-invariant characteristics (liveness characteristics), such as eventually characteristics, can be perceived in a similar way to LCF (mentioned in Section 2), where a group or a pattern can be regarded as a characteristic.

As usual, there are many things to do left as future work. One piece of our future work is to conduct more non-trivial theorem proving case studies so that we can make more sure that r-SMGA can truly help experts in formal methods to conjecture lemmas in theorem proving, we can come up with a more systematic way to conjecture lemmas, and we can make how to conjecture lemmas with r-SMGA in a semi-automatic way., which may require to revise r-SMGA furthermore or to develop another tool.