1 / 36

Refactoring Design Models for Inductive Verification

Refactoring Design Models for Inductive Verification. Yung-Pin Cheng Dept. of Info. & Comp. Edu. National Taiwan Normal Univ. TAIWAN Michal Young Dept. of Comp. & Info. Sci. Univ. of Oregon USA. Outline. An overview of verifying parameterized concurrent systems

haroun
Download Presentation

Refactoring Design Models for Inductive Verification

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. Refactoring Design Models for Inductive Verification Yung-Pin Cheng Dept. of Info. & Comp. Edu. National Taiwan Normal Univ. TAIWAN Michal Young Dept. of Comp. & Info. Sci. Univ. of Oregon USA

  2. Outline • An overview of verifying parameterized concurrent systems • An overview of induction framework • Using refactoring transformations to enable induction framework for systems with parameterized behaviors • Related work • Conclusion • Future work

  3. Parameterized concurrent systems • Concurrent systems can be parameterized in many ways, such as • The number of identical components • e.g., processes • The number of data values • e.g., the length of a bounded buffer • The number of control commands • e.g., a protocol that allows retransmission of messages over a lossy channel at most n time • Increasing the size parameters often causes state explosion

  4. The general verification problem of parameterized systems • : system of size i : a family formed by • The verification problem: whether every in F satisfies a given property • Parameterization induces infinite-state space • The problem is undecidable in general but experience shows that many subclasses are decidable.

  5. Approaches to the problem • Project the infinite-state space into finite-state space and then apply the finite-state techniques • Often limited to a particular topology of networks (such as ring, chain, or a central control process with many identical user processes.) • Usually requires manual proof • Find a network invariant to pass the induction tests (which we call induction framework) • In principle, not restricted by network topology • Induction test is automatic • More popular • The main problem is network invariant may not exist or difficult to find (due to the undecidability)

  6. Induction framework – An overview • By Wolper & Lovinfosse1989 and Kurshan & McMillan 1995. • A popular approach to extend finite-state verification techniques to verify parameterized systems

  7. : a preorder relation (e.g., simulation relation) : a property of interest such that Induction framework – An overview • Assume , where I is some identical component • Find a network invariant Inv to pass three tests

  8. Induction framework – An overview • Why with the 3 tests? (use (3)) (use (2)) (use assumption and (1))

  9. How models can be affected by parameterization? • Models add/remove processes when the system size is increased/decreased(commonly seen in literature) • Hardware systems • Protocols that communcate by a shared bus • The behaviors (transition relation and number of states) of processes grow/shrink when the system size is increased/decreased • communication channels of a process varied by size • data values varied by size (e.g., buffer size) • Some process needs to be aware of new process’s existence

  10. How models are affected by parameterization? (Cont.) • Typical examples of the first kind P1 P2 P3 The three process share the same port of S (adding P4 does not change S’s behaviors) S P1 Ring structure: processes only communicate with their left/right-hand sides. (only channel relabelling is needed while adding a new process) P2 P4 P3

  11. How models are affected by parameterization? (Cont.) • An example of second kind S(n) needs to be aware of every process’s existence and eachP_i must communicate with S(n) by a private channel P1 P2 P3 S(n)

  12. When the induction framework fails • For a system whose behaviors are parameterized by n • This is where the induction would fail • This problem has been ignored or avoided in the past

  13. P1 P2 P3 P4 T4 T3 T1 T2 S P1 P2 P3 P1 P2 P3 P1 P2 P3 P1 P2 P3 S(n) T3 T1 T2 • It satisfies the assumption S Synchronization structure transformed by refactoring • S’s behavior is now independent of system size • So, if we increase the system size by one: • Induction framework is enabled by the new architecture

  14. Refactoring • Use a sequence of transformations (selected from a set) and apply them in a right order to transform a model into a final model • Each maintains behavioral equivalence (weak bisimulation)

  15. Refactoring Preprocessor LTS refactoring Models in Design Languge e,g, Promela, Ada-like design language LTS LTS LTS Property Verification result Parallel Composition analysis Global State space

  16. A case study - a remote temperature sensor system (RTSS)[Yeh&Young 1994,Sanden 1989] The parameterized control parts Lossy channel The parameterized control parts

  17. Refactoring CP_MODULE (interface behaviors) • Modeled by CCS (Milner) CP_MODULE -send(0) call(0) -send(1) -send(0) UI INTR -send(1) call(1) call(0) call(1) call_end call_end call_end

  18. Refactoring strategy • A general refactoring strategy is to separate behaviors which are linked to different control parts • for example -send(0), call(0) furnace 0 -send(1), call(1) furnace 1 call_end ?

  19. call_end(0) call_end(1) Transformation I: Edge relabeling • Ada’s accept/do block or Promela’s atomic INTR UI CP_MODULE call(0) -send(0) -call(0) -call_end(0) -call_end -send(0) call(1) -send(1) -send(1) call(1) call(0) -call(1) -call_end -call_end(1) call_end call_end(1) call_end(0) call_end call_end

  20. Behavioral equivalence • View CP_MODULE and INTR as a subsystem, we have where is the weak bisimulation

  21. CP_SUB0 call(0) -send(0) call_end(0) -send(0) -release(0) call(0) call_end(0) -send(0) -send(0) -send(0) -send(0) -send(0) -send(0) -send(0) -send(0) call(0) call(0) call(0) call(0) call(0) call(0) call(0) get(0) -send(0) call_end(0) call_end(0) call_end(0) call_end(0) call_end(0) call_end(0) call_end(0) -get(0) release(0) release(0) Transformation II: Behavior decomposition 1. Identify segment 2. Decompose segment and make it into a new process 3. Add new synchronizations to preserve equivalence UI call(0) -send(0) call(1) -send(1) call(1) -send(1) call_end(0) call_end(1) call_end(1) CP_MODULE

  22. Transformation II: Behavior decomposition • behavioral equivalence is again preserved as

  23. CP_SUB0 call(0) call(1) -send(1) -send(0) call_end(0) call_end(1) -release(0) -send(1) -send(0) -get(1) -get(0) -send(0) -send(0) call(1) call(0) call_end(0) call_end(1) get(1) -send(1) -get(0) release(0) release(1) release(0) Transformation III: Behavior decomposition call(0) -release(1) UI -get(1) release(1) CP_SUB1

  24. CP_SUB0 -release call(1) call(0) -send(0) -send(1) call_end(0) call_end(1) -release(0) -send(0) -send(1) -get(0) -get(1) -get -send(0) -send(0) -send(0) call(0) call(1) call_end(1) call_end(0) get get -send(1) -send(0) -release -get(0) release release(1) release(0) -get Transformation IV: Semaphore simplification UI call(0) -release(1) -get(1) • CCS two-way rendezvous • When increase size by 1, we add another CP_SUB2 release • The system may no longer meaningful to user CP_SUB1

  25. Refactoring of INTR A0 -call(0) alert0 -call_end(0) -call_end(0) B0 -call(0) alert0 A0 A0 A1 Emulate the loss of alert t B0 B1 A1 -call(1) alert1 -call_end(1) A1 A1 A0 -call_end(1) B1 -call(1) alert1 B0 B1 t

  26. -call(0) -call(1) -call(0) -call(1) t t alert0 alert1 -call(1) -call(0) alert1 alert0 alert0 alert1 -call_end(0) -call_end(1) release release -call_end(0) -call_end(1) The result of refactoring INTR -get -release -release -get

  27. A summary of refactored RTSS

  28. The induction of RTSS • The safety property is translated into a deadlock detection (Cheung & Kramer1999) • Property can be inserted into F0 and R0 • for example send(1),alert1 send(0) p send_end(0)

  29. The induction of RTSS (cont) • We need to find a network invariant to pass Note that we replace the preorder by weak bisimulation • Let Inv= RTSS(1) \{actions linked to furnace 0} • Finally, we test (3) by checking • Inv is an effective network invariant

  30. Other systems • A continuously running part of elevator system • Alternating bit protocol • …….

  31. Related work • Yeh and Young [STVR 1994] • Redesign RTSS for compositional analysis • Avrunin et. al. [UMass technical report,1999] Chiron interface – a decomposed dispatcher task • Valmari and Kokkarinen [ ICACSD 1998] • A protocol that can retransmit the message at most n times • With a brave titile: …10^any states and beyond • CSP (multi-way rendezvous)

  32. Conclusion • We propose a technique called refactoring to transform (equivalence preserving) system structure • We enable induction framework for systems with parameterized behaviors • Partially automated tool support

  33. Future research • More tool support • Full automation for subclasses • Looking for a unified family of transformations • Extend refactoring to Java threads Question?

  34. A prototype Chera

  35. A prototype

  36. A0 A0 B0 B0 A0 A0 B0 B0 Refactoring of INTR (cont). A0 A1 B0 B1 A1 A1 A0 B0 B1

More Related