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

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

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

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

6. 5 Approaches to the problem 1. 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 2. 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)

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

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

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

10. 9 How models can be affected by parameterization? 1. Models add/remove processes when the system size is increased/decreased (commonly seen in literature) Hardware systems Protocols that communcate by a shared bus 2. 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

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

12. 11 How models are affected by parameterization? (Cont.) An example of second kind P1P2P3 S(n) S(n) needs to be aware of every process’s existence and each P_i must communicate with S(n) by a private channel

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

14. 13 Synchronization structure transformed by refactoring P1P2P3 S(n) P1P2P3P1P2P3P1P2P3 T1T2 T3 S S’s behavior is now independent of system size S’s behavior is now independent of system size So, if we increase the system size by one: So, if we increase the system size by one: P1P2P3 T1T2 T3 S P4 T4 It satisfies the assumption It satisfies the assumption Induction framework is enabled by the new architecture Induction framework is enabled by the new architecture

15. 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)

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

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

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

19. 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 ?

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

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

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

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

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

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

26. 25 Refactoring of INTR -call(0)alert0-call_end(0) -call(0)alert0 -call_end(0)  -call(1)alert1-call_end(1) -call(1)alert1 -call_end(1)  A0 B0 A1 B1 Emulate the loss of alert A0 B0 A1 B1 00 10 01 11 A0 A1

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

28. 27 A summary of refactored RTSS Task Name Names of tasks after refactoring CP_MODULE CP_MODULE, CP_MODULE, CP_SUB0, CP_SUB1 INTR INTR INTR,INTR_SUB0,INTR_SUB1 TINTR TINTR, TINTR, TINTR_SUB0, TINTR_SUB1 DP_MODUL E DP_MODULE DP_MODULE,DP_SUB0,DP_SUB1 UI UI UI,UI_SUB0,UI_SUB1 Device[i]Not refactored Furnace[i]Not refactored

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

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

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

32. 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)

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

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

35. 34 A prototype Chera

36. 35 A prototype

37. 36 Refactoring of INTR (cont). A0 B0 A1 00 10 01 11 A0 B0 A0 B0 A1 B1 A1 B1 A0 B0 A0 B0