CTL Model-checking for Systems with Unspecified Components

1. CTL Model-checking for Systems with Unspecified Components Summer-1384 Hajar Niamehr Neda Noroozi

2. Outline • Introduction to component based systems • Problem definition in unspecified component-based system verification • Testing options • Formal verification methods • Model checking driven black-box testing • System model • Related procedures of verification • Examples

3. Introduction • Component-based software development has gained great popularity in building large software systems • Advantages • Reusing valuable software assets • Reducing development costs • Improving productivity • Disadvantages • Serious challenges in quality assurance • Prefabricated component could be a new source of system failures

4. Problem? how to ensure that a component functions correctly in the host system where the component is deployed?

5. Assurance of component functionality • When integrating a component into a system, system developers could: • Trust the component provider’s claim and go ahead to use it • Extensively retest the component alone • Hook the component to the system and conduct integration testing • Software components are generally built with multiple sets of functionality and testing all the functionality of a software component is • expensive • infeasible, considering the potentially huge state space of the component interface This option is not always applicable. Because, software components could be applied for dynamic upgrading or extending a running system that is costly or not supposed to shut down for retesting at all.

6. Formal verification techniques • Testing-based strategies are not sufficient to solve the problem for critical systems. • We need formal methods like model-checking!

7. Formal verification techniques cont. • Formal verification techniques not directly applicable • Design details • Source code of the component are not available to the developers of the host system.

8. Verification of systems with unspecified components • A new approach: Model-checking driven black-box testing • Advantages • Strong confidence about the reliability of the system • System developers can customize the testing with respect to specific system properties • Intermediate model-checking results can be reused to avoid integration testing

9. The system Model • Consider system with only one unspecified component. • M: host system • X: an unspecified component Both M and X are finite-state transition systems communicating synchronously with each other via a finite set of input and output symbols.

10. System Model cont. • X is defined as a deterministic Mealy machine whose internal structure is unknown. • X is defined as a triple • : set of X’s input symbols • : set of X’s output symbols • m : an upper bound for the number of states in X ( the m is given) • A run of X is a sequence of alternating input-output symbols, α0β0α1β1 …such that, starting form the initial state sinit.

11. System Model cont. • The host system M is defined as 5-tuple • S: a finite set of state • Г: a finite set of events • Renv⊆S ×Г ×S defines a set of environment transitions. • Rcomm ⊆ S × Σ×∇×S defines a set of communicationtransitions. • I ⊆ S isM’s initial states.

12. System Model cont. • An execution pathof the system can be represented as a sequence ζ of states and symbols, s0c0s1c1... • each si∈S • each ci is either a symbol in Гor a pair αiβi . • ζ satisfies the following requirements: • s0 is an initial state of M; • for each ci∈Г, (si, ci, si+1) is an environment transition of M; • for each ci = αiβi, (si, αi, βi, si+1) is a communication transition of M.

13. System Model cont. • The communication traceof ζ, denoted by ζX, is the sequence obtained from ζ by retaining only symbols in Σ and ∇. • For any given state s∈S, we say that the system Sys can reachs iff Sys has an execution path ζ on which s appears ζX and X (if not empty) is also a run of X.

14. An example System

15. Model-checking driven black-box testing • ‹M,X›╞ f holds, where f is a CTL formula specifying some requirement for system. • Model-checking procedure drives from the M and f a condition P over the component X. • The system satisfies f iff P is satisfied by X. • Condition P over component X is checked through adequate black-box testing. • Condition P is in the form of communication graph, called witness graph

16. Ideas • For each subformula h in the form of EX g, E[g1Ug2] or EG g, the witness graph (WG) is constructed. • :Represents exactly all the path that witness h is true at some state. • If K is the total number of the CTL operators in f, the algorithm construct k WG (from 2 to k+1, 1 is reserved for true). • : denotes the ID number of h’s WG • If h is in the form of ¬ or V, the state which holds h is labeled as follows: • ID := 1 | 2 | … | k+1 • Ψ:= ID | ¬ Ψ | Ψ V Ψ • Ψ is set of all the ID expressions. • Lh: S  Ψ: labeling function to record the ID expression of each state for each subformula h.

17. The Algorithm for solving CTL Problem.

18. Processing the CTL Formula

19. Processing the CTL Formula – HandleUnion and HandleNegation • HandleUnion • If state s is in both Lg1’s and Lg2’s domain, Lh labels s with 1 if either Lg1 or Lg2 labels s with 1 and label s with ID expression Lg1(s)∨Lg2(s) otherwise; • If state s is in Lg1’s domain but not in Lg2’s domain, let L label s with Lg1 (s). • HandleNegation • If state s is not in the domain of Lg, let Lh label s with 1; • If state s is in the domain of Lg but not labeled with 1 by Lg, Lh labels s with ID expression ¬Lg(s).

20. Processing the CTL Formula- HandlingEX • If state s has a successor s′ in the domain of Lg • if s′ is reachable through an environment transition and s′ is labeled with 1 by Lg then Lh also labels s with 1 • otherwise Lh labels s with the current value of the global variable id. • The witness graph of EX g is created as triple: • N is a set of nodes and E is a set of annotated edges.

21. Processing the CTL Formula- HandlingEX cont. • The witness graph is created as follows: • Add one node to N for each state that is in the domain of Lg. • Add one node to N for each state that has a successor in the domain of Lg. • Add one edge between two nodes in N to E when M has a transition between two states; • if the transition involves a communication with X then annotate the edge with the communication symbols. • Increase the global variable ID by 1(since one new witness graph has been created).

22. Processing the CTL Formula- HandlingEU • Labeling function is constructed recursively • Fist, Lh labels state s in the domain of Lg2 with Lg2(s). • Second, if state s has a successor s′ in the domain of Lh • if both s and s′ is labeled with 1 by Lg1 and Lh respectively and s can reach s′ through an environment transition then Lh also labels s with 1 • otherwise Lh labels s with the current value of the global variable id. • Notice that, in the second step, if a state s can be labeled with both 1 and the current value of id, let Lh label s with 1.

23. Processing the CTL Formula- HandlingEU cont. • The witness graph is created as a 4-tuple, • N is a set of nodes and constructed by adding one node for each state that is in the domain of Lh • E is a set of edges and constructed in the same way as that of HandleEX. • At last the global variable id is increased by 1.

24. Processing the CTL Formula- HandlingEG • The labeling function Lh is constructed : • state s that can reach a loop C through a path p such that every state (including s) on p and C is in the domain of Lg, • If every state (including s) on p and C is labeled with 1 by Lg • And if no communications are involved on the path and the loop then Lh also labels s with 1 • otherwise Lh labels s with the current value of the global variable id. • The witness graph is created as triple, • The graph is constructed in a same way as that of HandleEU.

25. The algorithm CheckCTL gives a definite “yes” or “no” answer or reduces the problem to check whether the ID expression Ψ labeled to s0 can be evaluated true at the state. The evaluation procedure is carried out by the following recursive procedure TestWG, after an input sequence π has been accepted by the component X. Testing a Witness Graph

26. Testing a Witness Graph- TestEX • For checking whether an EX witness graph G can be evaluated true at a state s0: • test whether the system M can reach from s0 to another state s′∈dom(Lg) through a transition in G such that the ID expression Lg(s′) can be evaluated true at s′.

27. Testing a Witness Graph- TestEU • For checking whether an EU witness graph G can be evaluated true at a state s0: • traverse all paths p in G with length less than mn • m is an upper bound for the number of states in the unspecified component X • n is the maximal number of communications on all simple paths between s0 and s′ • test the unspecified component X to see whether the system can reach some state s′∈dom(Lg2) through one of those paths. • In the meantime, it should also check whether Lg2(s′) can be evaluated true at s′ and whether Lg1(si) can be evaluated true at si for each si on p (excluding s′) by calling TestWG.

28. Testing a Witness Graph- TestEG • For checking whether an EG witness graph G can be evaluated true at a state s0, it is sufficient to find an infinite path in G along which the system can run forever. • Procedure TestEG • first decomposes G into a set of SCCs. • Then, for each state sf in the SCCs, it calls another procedure SubTestEG to test whether the system can reach sf from s0 along a path not longer than mn, as well as whether the system can further reach sf from sf for m−1 times.

29. Ξ Example The EG witness graph:

30. References • G. Xie, Z. Dang, CTL Model-checking for Systems with Unspecified Components, 3rd Workshop on Specification and Verification of Component-based Systems at ACM SIGSOFT, California, October 31-November 1, 2004 • G. Xie, Decompositional Verification of Component-based System- A Hybrid Approach,19th IEEE International Conference on Automated Software Engineering (ASE'04 Doctoral Symposium), Linz, Austria, pp. 414-417, September 20, 2004. • D. Hung, D. Vu Anh, Model Checking Component Based Systems with Black-box Testing, International Institute for software technology, October 2004 • D. Hung, D. Vu Anh, Model Checking Real-time Component Based Systems With Black-box Testing, 2004 • N. Aguirre, T. Maibaum, Hierarchical Temporal Speci¯cations of Dynamically Recon¯gurable Component Based Systems, FESA 2004. • G. Xie, Z. Dang, Model checking Driven Blackbox Testing Algorithms for Systems with Unspecified Components, 2004