integrated state space reduction for model checking executable object-oriented software system...

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


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 Model xUML Level Query

xUML-to-S/R Translation

S/R Model S/R Level Query

Model Checking with COSPAN

Success Report / Error Track

9

General Framework

xUML-to-S/R Translation

S/R Model S/R Level Query

Model Checking with COSPAN

Success Report / Error Track

xUML Model xUML Level Query

ReducedxUML Model

Reduced xUML Level Query

User-Driven State Space Reduction

Verification Task

Verification Subtasks

Basic Model Checking Process

DecompositionAbstractionSymmetry Reduction

Symbolic VerificationLocalization Reduction

Partial Order Reduction

10

Recursive and Interactive Model Checking Process with ISSR

Enqueue (ToDo, T0); Done = { };

Directly_model_checkable (T)

Valid (T, < T1, …, Tn>)

Model_check(T)

Yes

<T1, …, Tn> = 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);

NoHalt

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




• 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, <M, T, P, A>, 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 P1

Where P1 is on Instance 1 of T;P is a query on

every instance of T

M consists of instancesfrom different classes

M consists only of all instances of a class, C

Reduce M with Case Splitting to M1 where M1 = {Instance 1 of C};

Reduce M with Decomposition into M1, …, Mn;Reduce T to sub-transactions, T1, …, Tn

Reduce P to sub-properties on T1 , …, Tn;

<M, T, P, A>

Yes

Yes

Yes

No

No

No

17




• 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, P0 : After Request (i) Eventually TicketHeld(i) or TryLater (i) or SoldOut(i);

20

Reduction Steps for Checking P0

Customers, DispatcherAgents, Ticket Sever

Step 1: Symmetry Reduction

Step 2: Decomposition



Step 5: Case SplittingStep 6: Symmetry Reduction

P0


P1

Customers Dispatcher Agents, Ticket ServerP21 , P22 P31 , P32

P33 , P23

Agents, Ticket ServerP41 , P42

P43 , P44

Ticket Server AgentsP41 , P42

P43 , P44

P5

Ticket ServerP6 AgentP41 , P42

P43 , P44

21



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

• P1: After Request(1) Eventually TicketHeld(1) or TryLater(1) or SoldOut(1)

P0



P1

22



• P21: After Request(1) and Forall k {D.Agent_Free[k] = FALSE} Eventually TryLater(1)

• P22: After Request(1) and Exists k {D.Agent_Free[k] = 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)

P1

Customers Dispatcher Agents, Ticket Server


P21 , P22 P23

P31 , P32, P33

• P31: After A(j).$ = Idle Always A(1).$ = Idle UntilAfter Assignment (j)• P32: After Assignment (j) and A(j).$ = Idle Eventually Reset(j);• P33: After Reset(j) Eventually A(j).$ = Idle

Assuming

23


Agents, Ticket Server

• 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


• 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) and A(1).$ = Idle


P31 , P32

P33 , P23

Agents, Ticket ServerStep 3: Symmetry Reduction P41 , P42

P43 , P44

24


• 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


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


Agents, Ticket ServerStep 3: Symmetry Reduction

Ticket Server AgentsStep 4: Decomposition P41 , P42

P43 , P44

P5

P31 , P32

P33 , P23

P41 , P42

P43 , P44

25

Step 5: Case Splitting

• 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



Ticket Server AgentsStep 4: Decomposition P41 , P42

P43 , P44

AgentStep 5: Case Splitting P41 , P42

P43 , P44

P5

26


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

AgentStep 5: Case Splitting


Ticket Server AgentsStep 4: Symmetry Reduction

• P6: After Hold(1) Eventually Held(1) or Later(1) or Out(1)

P5

Ticket Server


P6

P41 , P42

P43 , P44

P41 , P42

P43 , P44

27

Reduction Steps for Checking P0






Step 5: Case SplittingStep 6: Symmetry Reduction

P0


P1

Customers Dispatcher Agents, Ticket ServerP21 , P22 P31 , P32

P33 , P23

Agents, Ticket ServerP41 , P42

P43 , P44

Ticket Server AgentsP41 , P42

P43 , P44

P5

Ticket ServerP6 AgentP41 , P42

P43 , P44

28

Presentation Agenda

• Problem

• Our Approach

• Evaluation

• Related 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.

integrated state space reduction for model checking executable object-oriented software system...

Documents

reduction t

xuml level model

process of model

problem model

reduction manager

model checking task

xuml model of s t

design model level