PlayGame: A Platform for Diagnostic Games Li Tan Joint work with Rance Cleaveland July 2004

1. PlayGame: A Platform for Diagnostic Games Li Tan Joint work with Rance Cleaveland July 2004 PlayGame: A Platform for Diagnostic Games

2. Design goals To provide an ``open’’ platform for game-based diagnostic routines, it should be, • Interactive: user chooses part of proof to study via the interaction with the computer. • Versatile: the tool shall work for a variety of verification techniques (equivalence checking, model checking, etc) • Modular: • Adding a new game requires less effort. • Game semantics are abstracted to improve code sharing. • Checker-independent: use abstract proof structures to construct winning strategies. Not tied to any particular checker. • Easy-to-use: improve the usability of a research tool. Provide both textual and graphic user interfaces. PlayGame: A Platform for Diagnostic Games

3. Textual User Interface Graphic User Interface Game history submodule Command submodule Model-Checking Game Submodule Equivalence/Preorder Game Submodule Model-Checking Game Submodule Equivalence/Preorder Game Submodule bisim/sim Plug-ins Weak bisim/sim Plug-ins Trace Equiv./Pre. Plug-ins Testing Equiv./Pre. Plug-ins m-calculus Plug-in The architecture of PlayGame User PlayGame Abstract game module Game semantics module Strategy module Kernel-Auxiliary Partition Refinement Trees Checker-Independent Evidence Support Sets Verification problems Kernel Equivalence /Preorder Checkers Model Checkers CWB front end PlayGame: A Platform for Diagnostic Games

4. The design of PlayGame • Semantics hierarchy: abstract the game semantics to improve code sharing and modularity [Ste98,Tan02a] • Abstract game module • Implementing an abstract version of verification games. • Implementing user interfaces, backtracking, and other common features. • Game semantics module • Defining the game rules (Who move next? Has anyone won the game?) • Allowing the further abstraction on the same category of games. • Strategy module • Synthesizing the winning strategies for the computer. • Evidence-based verification: synthesize winning strategies from abstract proof structures submitted by checkers [TanCle02]. • Strategy module works independent of underlying checkers. PlayGame: A Platform for Diagnostic Games

5. The Abstract Game • Verification problems as two-player games. • Player I intends to show that the verification result is negative. • Player II tries to frustrate it. • Games are determined. • Player I has a strategy to win the game if and only if the correct answer to verification problem is negative. • When games are used for diagnostic routines, • Two sides: Computer v.s. User, when the verification result is, • Yes => Computer plays as II while user as I. • No => Computer plays as I while user as II. • User understands the result by playing and losing every play. • Abstract game module implements this abstract game. • It introduces referee to enforce the rules and to perform player-independent actions (unrolling fixpoint variables …) etc. PlayGame: A Platform for Diagnostic Games

6. Game Semantics Module Semantics module defines the rules for each game. It provides, • Referee command based on the current configuration. • Has someone already won the game? • Who moves first? Which agents a player can pick? • Agent transition functions. • Provide all the possible moves for the players to choose. • Further abstraction for the same category of games. • Equivalence/Preorder Submodule implement the rules common to these games. • For example: checking whether the same configure is repeated (player II wins). • Each game uses its own (relatively small) plugin to define its specific rules. • For example: the definition of initial actions. • Multiple layers of abstraction on game semantics reduces 70-80% development cost when introducing a new game. PlayGame: A Platform for Diagnostic Games

7. The loop restriction reflects the least/greatest fixpoints • Synthesizing computer strategy from a support set: • Stay in the trail! choose those moves covered by support set. Game Strategy Module (I) Game strategy module is built within the framework of evidence-based verification. • Abstract proof structures are encoded independent of checkers. • In model checking, the abstract proof structure is a support set [TanCle02]. (S0, X) can_deadlock= mX.(<->XÇ[-]ff) a (S0, <->XÇ[-]ff) S0 b a S1 (S0, <->X)(S0, [-]ff)} a (S1,X)(S0, X) S2 (S1, <->XÇ[-]ff) • Each Boolean variable is supported by a set of variables (dependent set) (S1, <->X)(S1, [-]ff) (S2, X) (S2, <->XÇ[-]ff) (S2, <->X)(S2, [-]ff) PlayGame: A Platform for Diagnostic Games

8. Game Strategy Module (II) • In equivalence/preordering checking, the abstract proof structure is Kernel-Auxiliary partition refinement tree [TanCle01]. • The kernels of the leaves constitute the coarsest partition for an equivalence relation. • The auxiliary of a leaf contains the states ``greater than’’ the kernel states on a preorder. • Each internal node records the information about the splitter and the splitting action. • Computer Strategy. • If the initial states of two agents are related: keep the current states in the same leaf. • If the initial state of two agents are not related: keep the current states in different leaves. • A variety of checkers can be extended to produce abstract proof structures without scarifying their performance. • Strategy-synthesizing algorithms are independent of checkers. • Strategy-synthesizing algorithms are implemented per category basis. • Computer strategies are similar for the same category of the games. • All eight different equivalence/preordering games share the same strategy algorithm. PlayGame: A Platform for Diagnostic Games

9. Active Node Features and User Interfaces Semantics hierarchy allows the sharing of many add-on features among various games. Current configurations Shape shows the current player Referee User Computer Referee command Current configurations Players and their roles PlayGame: A Platform for Diagnostic Games

10. Features and User Interfaces The detailed explanation of rule and winning conditions. Shape shows the current player Referee User Computer Repeated configuration is shown In yellow Reason Declare the winner Red node indicates a winning configuration PlayGame: A Platform for Diagnostic Games

11. Features and User Interfaces PlayGame supports backtracking at any point and branch-time history. Shape shows the current player Referee User Computer Backtracking: Select/View a previous configure by clicking a node Repeated configuration is shown In yellow Choose a different option Red node indicates a winning configuration PlayGame: A Platform for Diagnostic Games

12. Features and User Interfaces PlayGame supports backtracking at any point and branch-time history. Shape shows the current player Referee User Computer Backtracking: Select/View a previous configure by clicking a node Repeated configuration is shown In yellow Red node indicates a winning configuration PlayGame: A Platform for Diagnostic Games

13. Features and User Interfaces Equivalence games have the same look and feeling as model checking games. An observational equivalence game as shown Shape shows the current player Referee User Computer Backtracking: Select/View a previous configure by clicking a node A graph layout algorithm Repeated configuration is shown In yellow Support ``standard” graph operations Drag&drop, Zoom etc Red node indicates a winning configuration PlayGame: A Platform for Diagnostic Games

14. Features and User Interfaces PlayGame also provides a textual user interface PlayGame is written in SML with the SML/TK [LutWol99] package PlayGame: A Platform for Diagnostic Games

15. Conclusions We introduced PlayGame, an open platform for implementing diagnostic games. • Semantics hierarchy is introduced to improve code sharing. • Save a great deal of developing time. • To introduce a new game, one only needs to supply the relatively small semantics module at right level of hierarchy. • Many common features have been implemented as part of abstract game and shared by individual games. • Strategies are synthesized from checker-independent evidences • PlayGame works on a variety of checkers, not just game-based checkers. • PlayGame supports an array of verification semantics and modeling languages. • m-calculus model checking and 8 different equivalence/preordering games (bisim./sim. game, test equiv./preorder etc) • Support CCS, TCCS, SCCS, LOTOS etc ( as the benefit of using CWB-NC) • PlayGame provides a graphic user interface, a textual user interface, and many other features. PlayGame: A Platform for Diagnostic Games

16. Appendix • Supported Checkers • Model Checkers: LAFP [LRS98] (m-calculus), SLP (m-calculus), a linear-time alternation-free algorithm [CS91], Alternating Buchi Tableau Automata-based model checker [BCG01] (work in progress). • Equivalence/Preorder checker: Paige-Tarjan algorithm [PT87](equivalence checking), Kernel-Auxiliary partition refinement algorithm [TC01] (equivalence/preorder checking). • Supported Verification Techniques • Model Checking: m-calculus • Equivalence Checking: Bisimulation, Weak bisimulation, Trace Equivalence, and Test Equivalence • Preorder Checking: simulation, Weak simulation, Trace inclusion, and Test preorder. PlayGame: A Platform for Diagnostic Games