Integrated State Space Reduction for Model Checking Executable Object-oriented Software System Designs Fei Xie and James C. Browne Dept. of Computer Sciences Univ. of Texas at Austin

2 Presentation Agenda Problem Our Approach Evaluation Related Work Conclusions and Future Work

3 Problem Model checking of software system designs is often intractable due to state space explosion. State space reduction algorithms are applied, but often in an ad-hoc manner. Executable object-oriented (OO) modeling languages –Enable model checking of executable OO software system designs; –Facilitate application of many reduction algorithms. Can reduction algorithms be applied to executable OO software system designs in an organized manner?

4 Observations Structures and behaviors of software systems are more observable on the design model level. Executable OO software system designs often follow domain-specific design patterns. Effectiveness of reduction algorithms often depends on structures and behaviors of software systems. State space reduction algorithms are often applied in combination.

5 Presentation Agenda Problem Our Approach Evaluation Related Work Conclusions and Future Work

6 Our Approach Integrated State Space Reduction (ISSR) –Divide the process of model checking executable OO software system designs into three stages: User-driven State Space Reduction; Model Translation; Model Checking; –Apply reduction algorithms in different stages according to their characteristics: Target representations, semantics, automation, etc.; –Explore interactions among reduction algorithms: Combinations, application orders, etc. –Instantiate ISSR based on domain-specific design patterns.

7 Outline for Presenting ISSR General Framework for ISSR Instantiation of General Framework Case Study

8 Model Checking xUML Models System design and query are specified in xUML. xUML level model and query are automatically translated into the S/R automaton language. S/R model and query are checked with the COSPAN model Checker. Bugs found are fed back to system designers. xUML ModelxUML Level Query xUML-to-S/R Translation S/R ModelS/R Level Query Model Checking with COSPAN Success Report / Error Track

9 General Framework xUML-to-S/R Translation S/R ModelS/R Level Query Model Checking with COSPAN Success Report / Error Track xUML Model xUML Level Query Reduced xUML Model Reduced xUML Level Query User-Driven State Space Reduction Verification TaskVerification Subtasks Basic Model Checking Process Decomposition Abstraction Symmetry Reduction Symbolic Verification Localization Reduction Partial Order Reduction

10 Recursive and Interactive Model Checking Process with ISSR Enqueue (ToDo, T 0 ); Done = { }; Directly_model_checkable (T) Valid (T, ) Model_check(T) Yes = User_driven_state_reduction (T); No Done = Done + {T}; Property holds Error_report_generation( ); Invoke_user_interface( ); No Enqueue (ToDo, T1, …, Tn); Yes No Empty(ToDo) T = Dequeue (ToDo); No Halt Yes

11 Selection and Ordering of Reduction Algorithms Selection of Reduction Algorithms –A set of general selection guidelines are suggested. Duplicated class instances Symmetry reduction; Intensive execution interleaving Partial order reduction; … –Selection of user-driven reductions is domain-dependent. Application Order of Reduction Algorithms –Reduction algorithms are ordered by application stages; –Order of user-driven reductions is domain-dependent.

12 Automation Support for ISSR COSPAN as Model Checker –Provides Localization Reduction; –Supports Symbolic Model Checking (SMC); –Facilitates Static Partial Order Reduction (SPOR). xUML-to-S/R translator –Is extended with SPOR; –Supports Symmetry Reduction. Reduction manager being developed –Performs user-driven state space reduction; –Coordinates recursive model checking process.

13 Outline for Presenting ISSR General Framework for ISSR Instantiation of General Framework Case Study

14 Transaction Systems A transaction system executes transactions concurrently. Transactions –Sequences of interactions between system components; –Maybe of different types. Transactions of a same type are often symmetric if certain details are abstracted away. Correctness of a transaction system often depends on –Correctness of each transaction; –Correctness of interactions among transactions.

15 Model Checking Task A model checking task on a transaction system, S, is a four-tuple,, where –M : An xUML model of S; –T : A transaction type defined on M; –P : A temporal property to be checked on T; –A : A set of temporal properties assumed on the environment of S.

16 Instantiation of General Framework for Transaction Systems Reduce P with Symmetry Reduction to P 1 Where P 1 is on Instance 1 of T; P is a query on every instance of T M consists of instances from different classes M consists only of all instances of a class, C Reduce M with Case Splitting to M 1 where M 1 = {Instance 1 of C}; Reduce M with Decomposition into M 1, …, M n ; Reduce T to sub-transactions, T 1, …, T n Reduce P to sub-properties on T 1, …, T n ; Yes No

17 Outline for Presenting ISSR General Framework for ISSR Instantiation of General Framework Case Study

18 Case Study: An Online Ticket Sale System (OTSS) Customer (C)Dispatcher (D) Agent (A)Ticket_Server (TS) TryLater Assignment Hold Request Held/Later/Out TicketHeld/TryLater/SoldOut Payment Ticket Reset Buy/Release Branching Point 1 Branching Point 4 Branching Point 2 Branching Point 3

19 Property to be Checked on OTSS In English, After a Request message from a customer is processed by the dispatcher, eventually the system will reply the customer with a TicketHeld message, or a TryLater message, or a SoldOut message. In the xUML level query specification logic, P 0 : After Request (i) Eventually TicketHeld(i) or TryLater (i) or SoldOut(i);

20 Reduction Steps for Checking P 0 Customers, Dispatcher Agents, Ticket Sever Step 1: Symmetry Reduction Step 2: Decomposition Step 3: Symmetry ReductionStep 4: DecompositionStep 5: Case Splitting Step 6: Symmetry Reduction P0P0 Customers, Dispatcher Agents, Ticket Sever P1P1 CustomersDispatcherAgents, Ticket Server P 21, P 22 P 31, P 32 P 33, P 23 Agents, Ticket Server P 41, P 42 P 43, P 44 Ticket Server Agents P 41, P 42 P 43, P 44 P5P5 Ticket ServerP6P6 Agent P 41, P 42 P 43, P 44

21 Step 1: Symmetry Reduction Customers, Dispatcher Agents, Ticket Sever P 0 : After Request(i) Eventually TicketHeld(i) or TryLater(i) or SoldOut(i) P 1 : After Request(1) Eventually TicketHeld(1) or TryLater(1) or SoldOut(1) P0P0 Customers, Dispatcher Agents, Ticket Sever Step 1: Symmetry Reduction P1P1

22 Step 2: Decomposition Customers, Dispatcher Agents, Ticket Sever P 21 : After Request(1) and Forall k {D.Agent_Free[k] = FALSE} Eventually TryLater(1) P 22 : After Request(1) and Exists k {D.Agent_Free[k] = TRUE} Eventually Assignment(j, 1) and A(j).$ = Idle P 23 : After Assignment(j, 1) and A(j).$ = Idle Eventually TicketHeld(1) or TryLater(1) or SoldOut(1) P1P1 CustomersDispatcherAgents, Ticket Server Step 2: Decomposition P 21, P 22 P 23 P 31, P 32, P 33 P 31 : After A(j).$ = Idle Always A(1).$ = Idle UntilAfter Assignment (j) P 32 : After Assignment (j) and A(j).$ = Idle Eventually Reset(j); P 33 : After Reset(j) Eventually A(j).$ = Idle Assuming

23 Step 3: Symmetry Reduction Agents, Ticket Server P 31 : After A(j).$ = Idle Always A(j).$ = Idle UntilAfter Assignment (j) P 32 : After Assignment (j) and A(j).$ = Idle Eventually Reset(j); P 33 : After Reset(j) Eventually A(j).$ = Idle P 23 : After Assignment(j, 1) and A(j).$ = Idle Eventually TicketHeld(1) or TryLater(1) or SoldOut(1) P 41 : After A(1).$ = Idle Always A(1).$ = Idle UntilAfter Assignment (1) P 42 : After Assignment (1) and A(1).$ = Idle Eventually Reset(1); P 43 : After Reset(1) Eventually A(1).$ = Idle P 44 : After Assignment(1) and A(1).$ = Idle Eventually TicketHeld(1) or TryLater(1) or SoldOut(1) P 31, P 32 P 33, P 23 Agents, Ticket Server Step 3: Symmetry ReductionP 41, P 42 P 43, P 44

24 Step 4: Decomposition P 41 : After A(1).$ = Idle Always A(1).$ = Idle UntilAfter Assignment (1) P 42 : After Assignment (1) and A(1).$ = Idle Eventually Reset(1); P 43 : After Reset(1) Eventually A(1).$ = Idle P 44 : After Assignment(1, 1) and A(1).$ = Idle Eventually TicketHeld(1) or TryLater(1) or SoldOut(1) P 5 : After Hold(j) Eventually Held(j) or Later(j) or Out(j) Agents, Ticket Server Step 3: Symmetry Reduction Ticket Server Agents Step 4: DecompositionP 41, P 42 P 43, P 44 P5P5 P 31, P 32 P 33, P 23 P 41, P 42 P 43, P 44

25 Step 5: Case Splitting P 41 : After A(1).$ = Idle Always A(1).$ = Idle UntilAfter Assignment (1) P 42 : After Assignment (1) and A(1).$ = Idle Eventually Reset(1); P 43 : After Reset(1) Eventually A(1).$ = Idle P 44 : After Assignment(1, 1) and A(1).$ = Idle Eventually TicketHeld(1) or TryLater(1) or SoldOut(1) Agents, Ticket Server Ticket Server Agents Step 4: Decomposition P 41, P 42 P 43, P 44 Agent Step 5: Case Splitting P 41, P 42 P 43, P 44 P5P5

26 Step 6: Symmetry Reduction P 5 : After Hold(j) Eventually Held(j) or Later(j) or Out(j) Agent Step 5: Case Splitting Agents, Ticket Server Ticket Server Agents Step 4: Symmetry Reduction P 6 : After Hold(1) Eventually Held(1) or Later(1) or Out(1) P5P5 Ticket Server Step 6: Symmetry Reduction P6P6 P 41, P 42 P 43, P 44

27 Reduction Steps for Checking P 0 Customers, Dispatcher Agents, Ticket Sever Step 1: Symmetry Reduction Step 2: Decomposition Step 3: Symmetry ReductionStep 4: DecompositionStep 5: Case Splitting Step 6: Symmetry Reduction P0P0 Customers, Dispatcher Agents, Ticket Sever P1P1 CustomersDispatcherAgents, Ticket Server P 21, P 22 P 31, P 32 P 33, P 23 Agents, Ticket Server P 41, P 42 P 43, P 44 Ticket Server Agents P 41, P 42 P 43, P 44 P5P5 Ticket ServerP6P6 Agent P 41, P 42 P 43, P 44

28 Presentation Agenda Problem Our Approach Evaluation Related Work Conclusions and Future Work

29 Evaluation of User-driven State Space Reduction Directly model checking P 0 on OTSS –Two customer instances and two agent instances; –SPOR and SMC are both applied. –Memory usage: M –Time usage: S Memory and time usages for discharging subtasks at the leaf nodes of the reduction tree. P 21 P 22 P 41 P 42 P 43 P 44 P6P6 Memory0.30M0.95M0.28M0.29M0.28M0.29M0.35M Time0.02S1.81S0.01S0.04S0.01S0.04S0.63S

30 Evaluation of SPOR and SMC SPOR and SMC scale directly model-checkable tasks. Four model checking runs directly checking P 21 and using different combinations of SPOR and SMC: SPORSMCMemory UsageTime Usage Off M193748S OnOff M S OffOn M471.32S On M280.1S

31 Related Work Extensive research on various state space reduction algorithms, surveyed in [Clarke, et al. 1999] ; Integrated state space reduction for model checking hardware systems [McMillan 1999, Cadence 2001]. Our work distinguishes by: –Focusing on executable OO software system designs; –Utilizing reduction algorithms for asynchronous execution semantics and synchronous execution semantics; –Exploring integrated state space reduction under a general framework and instantiating for specific domains;

32 Conclusions and Future Work General framework for ISSR is proposed. Automation support is partially implemented. Instantiation for transaction systems has been conducted and applied to an online ticket sale system. Future work is focused on –Incorporation of more reduction algorithms; –Full implementation of automation support; –Instantiations for other application domains.