1 / 20

Testing and Verifying Invariant Based Programs in the SOCOS Environment

This paper discusses a constructive approach and a posteriori verification in invariant-based programming, providing program code, contracts, and verification conditions. It also presents the SOCOSEnvironment for testing and verifying programs.

sibylh
Download Presentation

Testing and Verifying Invariant Based Programs in the SOCOS Environment

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. Ralph-Johan Back, Johannes Eriksson and Magnus Myreen Testing and Verifying Invariant Based Programs in theSOCOSEnvironment Turku Centre for Computer Science Centre for Reliable Software Technology Åbo Akademi University Turku, Finland TAP: Tests and Proofs, 12 February 2007

  2. Approaches “constructive approach” “a posteriori verification” “invariant based programming” Program code Contracts Invariants Verification conditions

  3. A: Int[N] A: Int[N] Sorted(A,0,N) A=A0 Permutation(A,A0) Example: Sort an array! Start with a pre-/postcondition specification

  4. Example: Sort an array! Extract common invariant A: Int[N] A: Int[N] Sorted(A,0,N) A=A0 Permutation(A,A0)

  5. Example: Sort an array! 0 k N Construct a loop sorted unsorted A: Int[N] less than or equal to all A[k..N-1] ! A=A0 Sorted(A,0,N) Permutation(A,A0) k: Int 0≤k≤N LOOP Sorted(A,0,k) ∀i,j:Int • 0≤i<k ∧ k≤j<N ⇒ A[i]≤A[j]

  6. 0: Int 0≤0≤N Sorted(A,0,0) ∀i,j:Int • 0≤i<0 ∧ 0≤j<N ⇒ A[i]≤A[j] Example: Sort an array! What needs to be checked? A: Int[N] Add initial transition A=A0 ⇒ A: Int[N] ✔ A: Int[N] ✔ Permutation(A,A0) Permutation(A,A0) ✔ A=A0 Sorted(A,0,N) ✔ ✔ ✔ k: Int 0≤k≤N Sorted(A,0,k) ∀i,j:Int • 0≤i<k ∧ k≤j<N ⇒ A[i]≤A[j] k:=0

  7. Trivial: Sorted(A,0,k) ∧ k=N ⇒ Sorted(A,0,N) Example: Sort an array! Add exit transition A: Int[N] Permutation(A,A0) A=A0 Sorted(A,0,N) k: Int [k=N] 0≤k≤N Sorted(A,0,k) ∀i,j:Int • 0≤i<k ∧ k≤j<N ⇒ A[i]≤A[j] k:=0

  8. A: Int[N] Permutation(A,A0) k: Int 0≤k≤N Sorted(A,0,k) ∀i,j:Int • 0≤i<k ∧ k≤j<N ⇒ A[i]≤A[j] A’: Int[N] Permutation(A’,A0) k+1: Int 0≤k+1≤N Sorted(A’,0,k+1) ∀i,j:Int • 0≤i<k+1 ∧ k+1≤j<N ⇒ A’[i]≤A’[j] Example: Sort an Array! Add loop transition BELIEVE ME k<N m=min(A,k,N) ∧ A’= A[ k←A[m], m←A[k] ] A: Int[N] ⇒ Permutation(A,A0) A=A0 Sorted(A,0,N) k: Int [k=N] 0≤k≤N Sorted(A,0,k) ∀i,j:Int • 0≤i<k ∧ k≤j<N ⇒ A[i]≤A[j] [k<N] k:=0 m:=min(A,k,N); A:=A[ k←A[m], m←A[k] ]; k:=k+1

  9. 0≤N-k Example: Sort an Array! Add a termination function A: Int[N] Variant decreases: N-(k+1) < N-k Bounded from below: 0≤k≤N ⇒ 0≤N-k Permutation(A,A0) A=A0 Sorted(A,0,N) k: Int [k=N] 0≤k≤N Sorted(A,0,k) ∀i,j:Int • 0≤i<k ∧ k≤j<N ⇒ A[i]≤A[j] [k<N] k:=0 A:=Swap(A,k,min(A,k,N)); k:=k+1

  10. TAP: Tests and Proofs, 12 February 2007 The SOCOS Tool • “Software COnstruction Site” • An editor for invariant diagrams • Higher-order specifications and formal semantics • Goal: higher assurance Extended static checking: Find common errors and insufficient (too weak) invariants Testing: Find common errors Interactive proofs: Total correctness

  11. TAP: Tests and Proofs, 12 February 2007 SOCOS User Interface

  12. TAP: Tests and Proofs, 12 February 2007 Program Constructs • Procedures with pre- and postconditions • Statements • if .. fi, assignment, assertion, procedure call • Simple data types • integers, booleans • strings, arrays • Data invariants

  13. Testing/Debugging

  14. TAP: Tests and Proofs, 12 February 2007 Formal Verification • Verification conditions can be generated for the whole program, or for a single procedure/transition/situation • Verification conditions are generated and sent to external proof tools • Three types of verification conditions: • Consistency(for transitions) • Completeness(for situations) • Termination(for loops)

  15. TAP: Tests and Proofs, 12 February 2007 Consistency • Each transition should establish its target: I1 ⇒ wp(S,I2)

  16. TAP: Tests and Proofs, 12 February 2007 Completeness (liveness) • At least one transition from each (non-terminal) situation should be enabled: I ⇒ wp(S*,False) magic . . . if … fi magic . . . if … fi I magic . . . if … fi magic

  17. TAP: Tests and Proofs, 12 February 2007 Termination • Every transition in a cycle must not increaseV: Ij ∧ V=V0 ⇒ wp(Sj,0≤V≤V0) (for all j) • At least one transition must decrease V: Ik ∧ V=V0 ⇒ wp(Sk,0≤V<V0) (for some k) Ik+1 Ik

  18. TAP: Tests and Proofs, 12 February 2007 Backends Higher assurance→ Testing Diagram is converted to a Python program, with run-time evaluation of invariants Static Checking Verification conditions are sent to Simplify, a fully automatic prover Full Verification PVS is used for full verification of the final components

  19. Conclusion and Future Work • Specifications and invariants main building blocks • Correct programs can be developed incrementally • Currently used in teaching program semantics • Future work • Scalability: refinement, object-orientation • Larger case studies • Background checking • Test case generation

  20. Thank Youhttp://mde.abo.fi/SOCOS

More Related