Integrated State Space Reduction for Model Checking Executable Object-oriented Software System Designs

1
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.

9
General Framework
xUML Model
xUML Level Query
xUML-to-S/R Translation
S/R Model
S/R Level Query
Model Checking with COSPAN
Success Report / Error Track
10
Recursive and Interactive Model Checking Process
with ISSR
Enqueue (ToDo, T0) Done
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, ltM, T, P, Agt, 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
ltM, T, P, Agt
P is a query on every instance of T
Yes
Reduce P with Symmetry Reduction to P1 Where P1
is on Instance 1 of T
No
M consists of instances from different classes
Reduce M with Decomposition into M1, ,
Mn Reduce T to sub-transactions, T1, ,
Tn Reduce P to sub-properties on T1 , , Tn
Yes
No
M consists only of all instances of a class, C
Yes
Reduce M with Case Splitting to M1 where M1
Instance 1 of C
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)
Agent (A)
Ticket_Server (TS)
Customer (C)
Dispatcher (D)
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,
• P0 After Request (i) Eventually TicketHeld(i)
  or TryLater (i) or SoldOut(i)

20
Reduction Steps for Checking P0
P0
Step 6 Symmetry Reduction
21
Step 1 Symmetry Reduction
P0

• P0 After Request(i) Eventually
  TicketHeld(i) or TryLater(i) or SoldOut(i)

22
Step 2 Decomposition
P1

• P21 After Request(1) and Forall k
  D.Agent_Freek FALSE Eventually
  TryLater(1)
• P22 After Request(1) and Exists k
  D.Agent_Freek TRUE
• Eventually Assignment(j, 1) and
  A(j). Idle
• P23 After Assignment(j, 1) and A(j). Idle
  Eventually TicketHeld(1) or TryLater(1) or
  SoldOut(1)

23
Step 3 Symmetry Reduction
P31 , P32 P33 , P23

• P31 After A(j). Idle Always A(j). Idle
  UntilAfter Assignment (j)
• P32 After Assignment (j) and A(j). Idle
  Eventually Reset(j)
• P33 After Reset(j) Eventually A(j). Idle
• P23 After Assignment(j, 1) and A(j). Idle
  Eventually TicketHeld(1) or TryLater(1) or
  SoldOut(1)

24
Step 4 Decomposition
P31 , P32 P33 , P23
P41 , P42 P43 , P44

• P41 After A(1). Idle Always A(1). Idle
  UntilAfter Assignment (1)
• P42 After Assignment (1) and A(1). Idle
  Eventually Reset(1)
• P43 After Reset(1) Eventually A(1). Idle
• P44 After Assignment(1, 1) and A(1). Idle
  Eventually TicketHeld(1) or TryLater(1) or
  SoldOut(1)

• P5 After Hold(j) Eventually Held(j) or Later(j)
  or Out(j)

25
Step 5 Case Splitting
P41 , P42 P43 , P44
P5

• P41 After A(1). Idle Always A(1). Idle
  UntilAfter Assignment (1)
• P42 After Assignment (1) and A(1). Idle
  Eventually Reset(1)
• P43 After Reset(1) Eventually A(1). Idle
• P44 After Assignment(1, 1) and A(1). Idle
  Eventually TicketHeld(1) or TryLater(1) or
  SoldOut(1)

26
Step 6 Symmetry Reduction
P41 , P42 P43 , P44
P5
P41 , P42 P43 , P44

• P5 After Hold(j) Eventually Held(j) or Later(j)
  or Out(j)

27
Reduction Steps for Checking P0
P0
Step 6 Symmetry Reduction
28
Presentation Agenda

• Problem
• Our Approach
• Evaluation
• Related Work
• Conclusions and Future Work

29
Evaluation of User-driven State Space Reduction

• Directly model checking P0 on OTSS
• Two customer instances and two agent instances
• SPOR and SMC are both applied.
• Memory usage 152.79M
• Time usage 16273.7S
• Memory and time usages for discharging subtasks
  at the leaf nodes of the reduction tree.

P21 P22 P41 P42 P43 P44 P6
Memory 0.30M 0.95M 0.28M 0.29M 0.28M 0.29M 0.35M
Time 0.02S 1.81S 0.01S 0.04S 0.01S 0.04S 0.63S
30
Evaluation of SPOR and SMC

• SPOR and SMC scale directly model-checkable
  tasks.
• Four model checking runs directly checking P21
  and using different combinations of SPOR and SMC

SPOR SMC Memory Usage Time Usage
Off Off 167.072M 193748S
On Off 16.0604M 10476.5S
Off On 142.746M 471.32S
On On 102.527M 280.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.