An Assume-Guarantee Method for Modular An Assume-Guarantee Method - PowerPoint PPT Presentation

An Assume-Guarantee Method for Modular An Assume-Guarantee Method for Modular Verification of Evolving Component-Based Software Verification of Evolving Component-Based Software Pham Ngoc Hung, Nguyen Truong Thang, and Takuya Katayama Japan Advanced Institute of Science and Technology – JAIST {hungpn, thang, katayama}@jaist.ac.jp

Contents Contents Introduction Background A Framework for Modular Verification of Evolving CBS Assumption Regeneration Method Related Work & Conclusion 2 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Component-Based Software (CBS) Component-Based Software (CBS) Structured from a set of well-defined components � Ideally, components are plug-and-play Advantages: low development cost and time, flexible for � changes, etc. One of key issues of CBS is " component consistency " � The currently well-known technologies as CORBA, COM/DCOM or .NET, JavaBeans and EJB (Sun), etc. only support " component plugging " -> plug-and-play mechanism often fails A potential solution: modular verification based on � assume-guarantee reasoning 3 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Evolving CBS Evolving CBS A set of individual CBS evolution seems to components be an unavoidable task CBS development � Bug fixing, adding or Assume-Guarantee Verification removing some features, etc. <A(p)> F <p> � -> the whole evolved CBS <true> C 1 <A(p)> Verifying consistency must be rechecked <true> <p> F ║ C 1 among components How to recheck the CBS evolution evolved CBS by reusing • Evolving by adding the previous verification some behaviors of the existing components results? • How to recheck the evolved CBS? 4 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Background (1/3) Background (1/3) Input Labeled Transition Systems (LTSs) send in A LTS M = <Q, α M, δ , q 0 > � 1 0 2 ack Parallel Composition Operator " ║ " Output � Synchronizing the common actions send out a b c � Interleaving the remaining actions ack Safety LTS, Safety Property, Satisfiability Input ║ Output Input ║ Output � A safety LTS: a deterministic LTS that ack ack contain no π state ( π denotes the special out out 0,a 0,a 0,b 0,b 0,c 0,c error state) in in in in in in 1,a 1,a 1,b 1,b 1,c 1,c out out � A safety property is specified as a safety send send out out LTS p 2,a 2,a 2,b 2,b 2,c 2,c A LTS M satisfies p (M ╞ p) iff ∀δ ∈ L(M): � ( δ↑ α p) ∈ L(p) 5 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Background (2/3) Background (2/3) 〈 A(p) 〉 F 〈 p 〉 1. Assume-guarantee reasoning 2. 〈 true 〉 C 1 〈 A(p) 〉 � “Divide and conquer mechanism” for 〈 true 〉 F || C 1 〈 p 〉 decomposing a verification task into subtasks about the individual components of software in � <A(p)> F <p>, <true> C 1 <A(p)> both hold -> F ║ C 1 ╞ p out � To check <A(p)> F <p>: Creating p err from p: δ perr = δ p ∪ {(q,a, π )| not exist 1. q’ ∈ Q p : (q,a,q’) ∈ δ p } 2. Computing A(p) ║ F ║ p err If π is unreachable -> satisfied 3. Checking <true> C 1 <A(p)> by computing � C 1 ║ A(p) err 6 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Background (3/3) Background (3/3) Component refinement � Adding some states and transitions into the old component C 1 =<Q 1 , α C 1 , δ 1 , q 0 1 >, C 2 =<Q 2 , α C 2 , δ 2 , q 0 � 2 >: C 2 is the 2 refinement of C 1 iff Q 1 ⊆ Q 2 , δ 1 ⊆ δ 2 , q 0 1 = q 0 => L(C 1 ) ⊆ L(C 2 ) Output’ send Output send out send out refinement ack ack 7 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Contents Contents Introduction Background A Framework for Modular Verification of Evolving CBS Assumption Regeneration Method Related Work Conclusion 8 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Framework (1/2) Framework (1/2) Suppose that the system contains a framework F and an C 1 C 2 refinement extension C 1 and F ║ C 1 ╞ p A(p) Generating an assumption A(p) � Strong enough for F to satisfy p but F weak enough to be discharged by C 1 � <A(p)>F<p> and <true>C 1 <A(p)> hold � When C 1 is refined into C 2 � The goal: checking F ║ C 2 ╞ p by reusing the previous assumption A(p) 9 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Framework (2/2) Framework (2/2) C 1 C 2 Solution refinement � Only check <true>C 2 <A(p)> A(p) If yes -> F ║ C 2 ╞ p � F Otherwise, F ║ C 2 ╞ p or A(p) � is too strong for C 2 to satisfy A new (p) is generated if A(p) is too � A new assumption A new (p) is strong for C 2 to satisfy re-generated by reusing A(p) if A(p) is too strong C 2 How to generate the new A new (p) assumption A new (p)? F 10 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Assumption regeneration process Assumption regeneration process counterexample – strengthen assumption Setting A 0 =A(p) Model Checking A i false 1. A i ║ F |= p Learning true true p holds 2. C 2 |= A i in F||C 2 false cex ∉ L(A i ) N Y real p violated error? counterexample – weaken assumption in F||C 2 cex ║ F | ≠ p ? 11 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Effectiveness Effectiveness To obtain the assumption A new (p), instead of starting from λ [Cobleigh’03], we start from the previous assumption A(p) This improvement reduces some steps of the assumption regeneration process 12 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Correctness and termination Correctness and termination Theorem: Given F, C 2 is a refinement of C 1 , a property p and an assumption A(p): <A(p)>F<p>, <true>C 1 <A(p)>. The process terminates and returns A new (p) if F ║ C 2 ╞ p and false otherwise Correctness � � Guaranteed by the compositional rule � Always achieving A new (p) by starting from A(p) C 2 ╞ A(p) and C 2 ╞ A new (p) -> A new (p) is weaker than A(p) � � Termination � At any iteration, it returns true or false and terminates or continues by providing a counterexample to L* Learning |A 0 | ≤ |A 1 | ≤ … ≤ |A W | � � In the worst case: L* Learning produces A W -> terminates! 13 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Related Work Related Work Assume-guarantee verification [Cobleigh’03] � The basic case: two components C 1 , C 2 � Assumption generation by using L* algorithm Verification of evolving software [Sharygina’05] � Key idea: component substitutability analysis � Containment check: all local behavior of the old component contained in new one � Compatibility check: safety w.r.t other components in assembly OIMC [Thang&Katayama’04] � Focus on the interaction between two components Base and Extension � Deriving a set of preservation constraints at the interface states of Base 14 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Conclusion Conclusion A framework for evolving CBS verification in the context of component refinement An assumption regeneration method � Reuse the previous assumption � Reduce several steps of the process Future work � Evaluating the effectiveness formally Applying the method for some larger case studies � 15 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Thanks for your listening! Thanks for your listening! 16 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Assume-guarantee verification [Cobleigh’03] Assume-guarantee verification [Cobleigh’03] � The main ideas base on Assume-Guarantee � The system has only two components; M 1 , M 2 � The main goal: checking M 1 ║ M 2 ╞ p without composing M 1 with M 2 ? � Finding an assumption A satisfying the compositional rule by using L* � If these components are changed -> assumption generation process re-runs on the whole system from beginning 17 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Verification of evolving software [Sharygina’05] Verification of evolving software [Sharygina’05] Key idea: component substitutability analysis � Obtain a finite behavioral model of all components by abstraction � Containment check: all local behavior of the old component contained in new one � Use under- and over- approximations � Compatibility check: safety w.r.t other components in assembly � Use dynamic assume-guarantee reasoning (dynamic L*) 18 DSN 2007 – WADS, Edinburgh, UK June 27, 2007

Verification of evolving software [Sharygina’05] Verification of evolving software [Sharygina’05] Component refinement: adding and removing some behavior of component implementation Using abstraction to obtain a new model of the upgraded component Try to reuse the old assumption to verify the new system by improving L* -> dynamic L* Our opinion: adding is enough We want not only to reuse the previous assumptions but also to reuse the previous models 19 DSN 2007 – WADS, Edinburgh, UK June 27, 2007