1 / 32

Fei Xie and James C. Browne Dept. of Computer Sciences Univ. of Texas at Austin

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. Presentation Agenda. Problem Our Approach Evaluation Related Work Conclusions and Future Work. Problem.

dinos
Download Presentation

Fei Xie and James C. Browne Dept. of Computer Sciences Univ. of Texas at Austin

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. 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 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. Verification Task Decomposition Abstraction Symmetry Reduction User-Driven State Space Reduction Verification Subtasks Reduced xUML Model Reduced xUML Level Query Partial Order Reduction Symbolic Verification Localization Reduction Basic Model Checking Process 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. Yes Empty(ToDo) Halt No T = Dequeue (ToDo); Yes No Directly_model_checkable (T) <T1, …, Tn> = User_driven_state_reduction (T); No Model_check(T) Valid (T, < T1, …, Tn>) Property holds No Yes Error_report_generation( ); Invoke_user_interface( ); Done = Done + {T}; Enqueue (ToDo, T1, …, Tn); 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, <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 <M, T, P, A> 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 Yes Reduce M with Decomposition into M1, …, Mn; Reduce T to sub-transactions, T1, …, Tn Reduce P to sub-properties on T1 , …, Tn; 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. Branching Point 1 Request Branching Point 2 Assignment TryLater Hold Held/Later/Out Branching Point 3 TicketHeld/TryLater/SoldOut Branching Point 4 Payment Buy/Release Ticket Reset 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. Customers, Dispatcher Agents, Ticket Sever Step 1: Symmetry Reduction P1 Customers, Dispatcher Agents, Ticket Sever Step 2: Decomposition P21 , P22 P31 , P32 P33 , P23 Customers Dispatcher Agents, Ticket Server P41 , P42 P43 , P44 Step 3: Symmetry Reduction Agents, Ticket Server Step 4: Decomposition P41 , P42 P43 , P44 P5 Agents Ticket Server P41 , P42 P43 , P44 Step 5: Case Splitting Agent P6 Ticket Server Reduction Steps for Checking P0 P0 Step 6: Symmetry Reduction

  21. Customers, Dispatcher Agents, Ticket Sever Step 1: Symmetry Reduction P1 Customers, Dispatcher Agents, Ticket Sever • P1: After Request(1) Eventually TicketHeld(1) or TryLater(1) or SoldOut(1) Step 1: Symmetry Reduction • P0: After Request(i) Eventually TicketHeld(i) or TryLater(i) or SoldOut(i) P0

  22. P21 , P22 P23 Customers, Dispatcher Agents, Ticket Sever P31 , P32, P33 Step 2: Decomposition Customers Dispatcher Agents, Ticket Server Assuming • 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 Step 2: Decomposition P1 • 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)

  23. P41 , P42 P43 , P44 Agents, Ticket Server Step 3: Symmetry Reduction Agents, Ticket Server • 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 Eventually TicketHeld(1) or TryLater(1) or SoldOut(1) 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. P41 , P42 P43 , P44 P5 Agents, Ticket Server Step 3: Symmetry Reduction Agents, Ticket Server Step 4: Decomposition Agents Ticket Server 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. P41 , P42 P43 , P44 Agents, Ticket Server Step 4: Decomposition Agents Ticket Server Step 5: Case Splitting Agent 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 P6 Agents, Ticket Server Step 4: Symmetry Reduction Agents Ticket Server • P6: After Hold(1) Eventually Held(1) or Later(1) or Out(1) Step 5: Case Splitting Agent Ticket Server 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. Customers, Dispatcher Agents, Ticket Sever Step 1: Symmetry Reduction P1 Customers, Dispatcher Agents, Ticket Sever Step 2: Decomposition P21 , P22 P31 , P32 P33 , P23 Customers Dispatcher Agents, Ticket Server P41 , P42 P43 , P44 Step 3: Symmetry Reduction Agents, Ticket Server Step 4: Decomposition P41 , P42 P43 , P44 P5 Agents Ticket Server P41 , P42 P43 , P44 Step 5: Case Splitting Agent P6 Ticket Server 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 P0on 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.

  30. Evaluation of SPOR and SMC • SPOR and SMC scale directly model-checkable tasks. • Four model checking runs directly checking P21and using different combinations of SPOR and SMC:

  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.

More Related