0
Dynamic Component Substitutability Analysis<br />Edmund Clarke<br />Natasha Sharygina*<br />Nishant Sinha<br />Carnegie Me...
Motivation<br /> Model checking is a highly time consuming, labor intensive effort<br /> For example, a system of 25 compo...
Software Evolution<br /> Software evolution is inevitable in any real system:<br /> Changing requirements<br />Bug fixes<b...
Substitutability Check<br />P<br />Assembly A<br />?<br />Component C<br />Component C’<br />
Motivation<br />Component-based Software<br />Software modules shipped by separate developers<br />Undergo several updates...
Substitutability Check<br />Incremental in nature<br />Two phases:<br />Containment check<br />All local behaviors (servic...
Containment, Compatibility Duality<br />Upgraded Component<br />C’<br />Component<br />C<br />New<br />Behaviors<br />Lost...
Substitutability Check<br />Approaches<br />Obtain a finite behavioral model of all components by abstraction: Labeled Kri...
Predicate Abstraction into LKS<br />p<br />Labeled Kripke Structures<br /><Q,,T,P,L><br />Composition semantics<br />Sync...
Component Assembly<br />C1<br />C2<br />C3<br />Component Assembly C<br />Predicate Abstraction<br />M1<br />M2<br />M3<br...
lock=1<br />if (x < y)<br />if (x < y)<br />x >= y<br /><br /><br />L2<br />lock = 0<br />if (x >= y)<br />if (x >= y)<b...
Containment Check<br />Goal: Check C µ C’<br />All behaviors retained after upgrade<br />Cannot check directly: need appro...
M<br />C’<br />C<br />M’<br />Containment (contd.)<br />C<br />C’<br />over-approx<br />under-approx<br />M<br />M’<br />µ...
Containment (contd.)<br />Computing over-approximation<br />Conventional predicate abstraction<br />Computing under-approx...
Compatibility Check<br />C’<br />C<br />Assume-guarantee to verify assembly properties<br />Identical<br />New <br />Lost<...
Cobleigh et. al. at NASA Ames
Use learning algorithm for regular languages, L*
Goal: Reuse previous verification results</li></li></ul><li>Learning Regular languages: L*<br />a<br />a<br />b<br />b<br ...
Learning for Verification<br />Model checker as a Teacher<br />Possesses information about concrete components<br />Model ...
Compatibility Check<br />-CE for A<br />Teacher<br />R1:      M1 || A ² P<br />L* Assumption<br /> Generation<br />A<br />...
Handling Multiple Components<br />R1:      M1 || A ² P<br />R2:        M2² A<br />M1 || M2² P<br />AG-NC is recursive<br /...
Upgrade<br />M’1k M2² P<br />M1k M2² P<br />M’1k A’1² P<br />M2² A’1<br />M1k A1² P<br />M2² A1<br />Reuse?<br />Compatibi...
NO: upgrades may change the unknown U to be learned
 Requires Dynamic L*</li></li></ul><li>Dynamic L*<br />Learn DFA A corresponding to U<br />Unknown language U changes to U...
Dynamic L*<br />L* maintains a table data-structure to store samples<br />Definition:Valid Tables<br />All table entries a...
Dynamic AG<br />Upgrade<br />M’1k M2² P<br />M1k M2² P<br />M’1k A’1² P<br />M2² A’1<br />M1k A1² P<br />M2² A1<br />Re-Va...
Implementation<br />Comfort framework – explicit model checker<br />Industrial benchmark <br />ABB Inter-process Communica...
Upcoming SlideShare
Loading in...5
×

20100522 software verification_sharygina_lecture02

209

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
209
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "20100522 software verification_sharygina_lecture02"

  1. 1. Dynamic Component Substitutability Analysis<br />Edmund Clarke<br />Natasha Sharygina*<br />Nishant Sinha<br />Carnegie Mellon University<br />The University of Lugano<br />
  2. 2. Motivation<br /> Model checking is a highly time consuming, labor intensive effort<br /> For example, a system of 25 components (~20K LOC) and 100+ properties might take up to a month of verification effort <br /> Discourages its widespread use when system evolves<br />
  3. 3. Software Evolution<br /> Software evolution is inevitable in any real system:<br /> Changing requirements<br />Bug fixes<br />Product changes (underlying platform, third-party,etc.)<br />
  4. 4. Substitutability Check<br />P<br />Assembly A<br />?<br />Component C<br />Component C’<br />
  5. 5. Motivation<br />Component-based Software<br />Software modules shipped by separate developers<br />Undergo several updates/bug-fixes during their lifecycle<br />Component assembly verification<br />Necessary on upgrade of any component<br />High costs of complete global verification<br />Instead check for substitutability of new component<br />
  6. 6. Substitutability Check<br />Incremental in nature<br />Two phases:<br />Containment check<br />All local behaviors (services) of the previous component contained in new one<br />Compatibility check<br />Safety with respect to other components in assembly: all global specifications still hold<br />
  7. 7. Containment, Compatibility Duality<br />Upgraded Component<br />C’<br />Component<br />C<br />New<br />Behaviors<br />Lost <br />Behaviors<br />Identical Behaviors<br />Compatibility Check<br />(global)<br />Containment Check<br />(local)<br />
  8. 8. Substitutability Check<br />Approaches<br />Obtain a finite behavioral model of all components by abstraction: Labeled Kripke structures<br />Containment: <br />Use under- and over- approximations<br />Compatibility: <br />Use dynamic assume-guarantee reasoning<br />
  9. 9. Predicate Abstraction into LKS<br />p<br />Labeled Kripke Structures<br /><Q,,T,P,L><br />Composition semantics<br />Synchronize on shared actions<br />Represents abstractions<br /><br /><br />q<br /><br />!q<br />!p<br />Predicate Abstraction<br />C Component<br />Component LKS<br />Abstraction<br />
  10. 10. Component Assembly<br />C1<br />C2<br />C3<br />Component Assembly C<br />Predicate Abstraction<br />M1<br />M2<br />M3<br />Abstraction M<br />A set of communicating concurrent C programs <br />No recursion, procedures inlined<br />Each component abstracted into a Component LKS<br />Communication between components is abstracted into interface actions<br />
  11. 11. lock=1<br />if (x < y)<br />if (x < y)<br />x >= y<br /><br /><br />L2<br />lock = 0<br />if (x >= y)<br />if (x >= y)<br />x < y<br />x >= y<br /><br /><br />L3<br />lock = 0<br />Predicate Abstraction into LKS<br />L1<br />void OSSemPend(…) {<br /> L1: lock = 1;<br /> if (x < y) {<br /> L2: lock = 0;<br /> …<br /> }<br /> if (x >= y) {<br /> …<br /> L3: lock = 0;<br /> …<br /> } else {<br /> …<br /> }<br />}<br />lock=1<br />x < y<br />
  12. 12. Containment Check<br />Goal: Check C µ C’<br />All behaviors retained after upgrade<br />Cannot check directly: need approximations<br />Idea: Use both under- and over- approximations<br />Solution: <br />Compute M: C µ M<br />Compute M’: M’ µ C’<br />Check for M µ M’<br />Identical<br />New <br />Lost<br />Containment Check<br />C<br />C’<br />
  13. 13. M<br />C’<br />C<br />M’<br />Containment (contd.)<br />C<br />C’<br />over-approx<br />under-approx<br />M<br />M’<br />µ ?<br />True<br />False, CE<br />C µ C’<br />CE 2 C ?<br />False,<br />Refine M<br />True,<br />Refine M’<br />C * C’,<br />CE provided <br />as feedback<br />True<br />CE 2 C’ ?<br />False<br />
  14. 14. Containment (contd.)<br />Computing over-approximation<br />Conventional predicate abstraction<br />Computing under-approximation<br />Modified predicate abstraction<br />Compute Must transitions instead of May<br />
  15. 15. Compatibility Check<br />C’<br />C<br />Assume-guarantee to verify assembly properties<br />Identical<br />New <br />Lost<br />Compatibility Check<br /> M1 || A ² P<br /> M2² A<br />M1 || M2² P<br />AG - Non Circular<br /><ul><li>Automatically generate assumption A
  16. 16. Cobleigh et. al. at NASA Ames
  17. 17. Use learning algorithm for regular languages, L*
  18. 18. Goal: Reuse previous verification results</li></li></ul><li>Learning Regular languages: L*<br />a<br />a<br />b<br />b<br />Yes/No<br />±Counterexample/ Yes<br />Unknown<br />Regular Language<br />Proposed by D. Angluin, improved by Rivest et al. <br />Learning regular sets from queries and counterexamples, Information and Computation, 75(2), 1987.<br />Polynomial in the number of states and length of max counterexample<br />Minimally adequate <br />Teacher<br />L* learner<br />IsMember( trace  )<br />IsCandidate( DFA D )<br />Modelchecker<br />Minimum<br /> DFA<br />
  19. 19. Learning for Verification<br />Model checker as a Teacher<br />Possesses information about concrete components<br />Model checks and returns true/counterexample<br />Learner builds a model sufficient to verify properties<br />Relies on both learner and teacher being efficient<br />Finding wide applications<br />Adaptive Model Checking:Groce et al.<br />Automated Assume-Guarantee Reasoning: Cobleigh et al.<br />Synthesize Interface Specifications for Java Programs: Alur et al.<br />Regular Model Checking: Vardhan et al., Habermehl et al.<br />
  20. 20. Compatibility Check<br />-CE for A<br />Teacher<br />R1: M1 || A ² P<br />L* Assumption<br /> Generation<br />A<br />true<br />true<br />R2: M2²A<br />M1 || M2² P<br />CE <br />Actual CE<br />M1 || M22 P<br />CE Analysis<br />+CE for A<br />
  21. 21. Handling Multiple Components<br />R1: M1 || A ² P<br />R2: M2² A<br />M1 || M2² P<br />AG-NC is recursive<br />(Cobleigh et al.)<br />M1k M2k M3² P<br /><ul><li>Each Ai computed by a separate L* instantiation</li></ul>M2k M3² A1<br />M1k A1² P<br />M2k A2² A1<br />M3² A2<br />
  22. 22. Upgrade<br />M’1k M2² P<br />M1k M2² P<br />M’1k A’1² P<br />M2² A’1<br />M1k A1² P<br />M2² A1<br />Reuse?<br />Compatibility of Upgrades<br />C<br />C’<br />Identical<br />New <br />Lost<br />Suppose assumptions are available from the old assembly <br />Dynamic AG: Reuse previous verification results<br /><ul><li> Can we reuse previous assumptions directly?
  23. 23. NO: upgrades may change the unknown U to be learned
  24. 24. Requires Dynamic L*</li></li></ul><li>Dynamic L*<br />Learn DFA A corresponding to U<br />Unknown language U changes to U’<br />Goal: Continue learning from previous model A <br />Central Idea: Re-validate A to A’ which agrees with U’<br />
  25. 25. Dynamic L*<br />L* maintains a table data-structure to store samples<br />Definition:Valid Tables<br />All table entries agree with U<br />Theorem <br />L* terminates with any validobservation table, OT<br />When U changes to U’, <br />Suppose the last candidate w.r.t. U is A<br />Re-validate OTof Aw.r.t. U’<br />Obtain A’ from OT’<br />Continue learning from A’<br />
  26. 26. Dynamic AG<br />Upgrade<br />M’1k M2² P<br />M1k M2² P<br />M’1k A’1² P<br />M2² A’1<br />M1k A1² P<br />M2² A1<br />Re-Validate! and Reuse<br />
  27. 27. Implementation<br />Comfort framework – explicit model checker<br />Industrial benchmark <br />ABB Inter-process Communication (IPC) software<br />4 main components – CriticalSection, IPCQueue, ReadMQ, WriteMQ<br />Evaluated on single and simultaneous upgrades <br />WriteMQ and IPCQueuecomponents<br />Properties<br />P1: Write after obtaining CS lock<br />P2: Correct protocol to write to IPCQueue<br />
  28. 28. Experimental Results<br />
  29. 29. ComFoRT Schema<br />Yes<br />Abstraction<br />Model<br /> System<br />Abstraction<br />Guidance<br />System OK<br />Improved<br />Abstraction<br />Guidance<br />No<br />Yes<br />Abstraction<br />Refinement<br />Spurious<br />Counterexample<br />Dynamic<br />Assume-Guarantee Reasoning<br />Verification<br />No<br />Counterexample<br />Counterexample<br />Valid?<br />
  30. 30. Conclusion<br />Automated Substitutability Checking<br />Containment and Compatibility<br />Reuses previous verification results<br />Handles multiple upgrades<br />Built upon CEGAR framework<br />Implementation<br />ComFoRT framework<br />Promising results on an industrial example<br />
  31. 31. Future Directions<br />Symbolic analysis, i.e., using SATABS<br />Assume-Guarantee for Liveness<br />Other AG Rules, e.g., Circular<br />Combining static analysis with dynamic testing for facilitate abstraction and learning<br />
  32. 32. Ph.D. position is open<br />New EU project on verification of evolving networked software<br />Collaboration with IBM, ABB, VTT, Uni Milano and Oxford<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×