Harton-Presentation

Heather Harton
Clemson University
Research funded in part by NSF grants CCF-0811748 and DMS-0701187

Thesis Statement
Related Work
Details of the Verification System
Research Evaluation

Research Vision
Full specification and verification of production
software built from reusable components
Tony Hoare’s verifying compiler grand challenge
Hoare, T.: The verifying compiler: A grand challenge for
computing research. J. ACM 50(1) (2003) 63-69

Thesis Statement
It is possible to generate
provable verification conditions of correctness
mechanically for full behavioral verification
of object-based software in a modular fashion,
one component at a time.

Full Behavioral Specification and
Verification
Some systems only verify properties (e.g., no null
reference access)
Some systems only allow specs that define partial
behavior
Example: Eiffel
Other systems have the ability to verify more complex
properties and may provide full verification

Thesis Statement
It is possible to generate
provable verification conditions of correctness
mechanically for full behavioral verification
of object-based software in a modular
fashion, one component at a time.

Modular Verification
Ability to verify one component at a time using only
specifications of reused components
Component
A
Spec
Component
B
Spec
New
Component
Realization
External
Component
Realization
Component
C
Spec
New
Component
Spec
=Component
Realization
Component
Realization
Component
Realization

Scalability of Proof Rules
Limited Number of Proof Rules
Should work for any data type
Should work on Built-In or User-Created Data Types
 Integers
 Arrays
 Pointers
 Generic Objects

Mechanical Verification
Huge gap between principle and practice
Example: Hoare’s proof rule for loops from 1969 can’t be
mechanized for practical use without several changes
Undecidability is less of a concern
Both VC generation process and proofs of correctness
should be automatic
Programmers will need to provide annotated code
 Invariants
 Progress Metrics
Mathematicians will need to provide proofs of the more
complicated theorems used by the prover

Object-Based Verification
Mechanizable proof rules are needed for all modern
language constructs
 Module-Level Verification
 Generics
 Object Specifications
 Enhancement Specifications
 Concept Implementations
 Operation-Level Verification
 Local and External Operations
 Control Constructs
 Object Declarations
 Auxiliary Variables and Code
 Context Enrichment
 Iterative and Recursive Procedures
 Enhancement Implementations
 Facility Declarations
 Simple
 Detailed
 Operation Calls
 Operation Declarations
 Functional
 Relational

Other Verification Systems
SPARKAda
Spec#/Boogie
VDM
Verisoft
Why
πVC
…
CompCert
Dafny
Eiffel
ESC/Java
Jahob
JML/FSPV
Larch
PVS

Comparison of Verification Systems
Effort Implementation
Language
Specification
Language
Verification
Type
Prover Automation Logic
Compcert Clight, subset of
C
Coq Full Coq Interactive Higher-Order
Dafny Dafny (Research
Language)
Dafny Full Boogie/Z3 Automatic First-Order
Eiffel Eiffel Eiffel Verification of
Properties
(Currently only
runtime checks)
Automatic First-Order
ESC/Java Java JML Verification of
Properties
Simplify Automatic Higher-Order
Jahob Subset of Java Subset of
Isabelle
Full Isabelle, Others Interactive Higher-Order
JML/FSPV Java JML Full Isabelle/Simpl Interactive Higher-Order
Larch Various
Languages
Larch Full Larch Prover Interactive First-Order
RESOLVE RESOLVE RESOLVE Full RESOLVE Automatic Higher-Order

Comparison of Verification Systems
Effort Implementation
Language
Specification
Language
Verification
Type
Prover Automation Logic
PVS PVS PVS Full PVS Interactive Higher-Order
SPARK Ada Subset of Ada SPARK Verification of
Properties
SPADE Interactive Higher-Order
Spec#/
Boogie
Spec #, Extension
of C#
Spec # Verification of
Properties
Boogie/Z3 Automatic First-Order
VDM-SL/
VDM++
Various
Languages
VDM Full VDM Interactive Higher-Order
Verisoft Subset of C, C0 Isabelle Full Isabelle Interactive Higher-Order
Why C, Java, ML Why Full Isabelle and
Coq
Interactive First-Order
πVC C-like language,
PI
πVC Full πVC Automatic First-Order
RESOLVE RESOLVE RESOLVE Full RESOLVE Automatic Higher-Order

Current Verification System
Uses RESOLVE
RESOLVE Semantics
Research into Mechanization of Proof Rules
Provides Modular Verification

Architecture of the RESOLVE Verification System
Math SpecialistSoftware Specialist
VC
Generator
Specs
Proof
Checker
Automated
Prover
Annotated
Code
Verification
Conditions
Math
Definitions,
Results
Math
Proofs
Proof
Certificate
 



Architecture of the RESOLVE Verification System
Math SpecialistSoftware Specialist
VC
Generator
Specs
Proof
Checker
Automated
Prover
Annotated
Code
Verification
Conditions
Math
Definitions,
Results
Math
Proofs
Proof
Certificate
 


RESOLVE
Specification and implementation language
Object-based
Includes parametric polymorphism
Does not include dynamic typing
Clean language (Kulczycki 2004)
No references when passing parameters
Provides the swap operator
Relies on a developed math library for proofs
Language elements
Concepts and enhancements
Realizations
Facilities

Why RESOLVE?
JML Spec for Push Operation on a Stack
public Object push(Object item)
Specifications:
public model_program { ... }
also
public normal_behavior
requires typeof(item) <: this.elementType;
requires this.containsNull||item != null;assignable theCollection;
ensures this.theList.equals(old(this.theList).insertBack(item));
ensures this.theList.int_size() <= this.maxCapacity;
also
public normal_behavior
requires typeof(this) == type(java.util.Vector);
{| requires this.theList.int_size() < this.maxCapacity;
ensures not_modified(maxCapacity)&&not_modified(capIncrement);
also
requires this.theList.int_size() == this.maxCapacity;
{| requires 0 < this.capIncrement&&this.maxCapacity <= 2147483647-this.capIncrement;
assignable maxCapacity, theList; ensures this.maxCapacity == old(this.maxCapacity)+this.capIncrement;
also
requires this.capIncrement == 0&&this.maxCapacity == 0;
assignable maxCapacity, theList; ensures this.maxCapacity == 1;
also
requires this.capIncrement == 0&&this.maxCapacity > 0&&this.maxCapacity < 1073741823;
assignable maxCapacity, theList; ensures this.maxCapacity == old(this.maxCapacity)*2;
|}
|}
also
requires typeof(item) <: this.elementType; requires this.containsNull||item != null;
assignable elementCount; ensures this.elementCount == old(this.elementCount)+1;
Link: http://www.eecs.ucf.edu/~leavens/JML-release/javadocs/java/util/Stack.html#push(java.lang.Object)

Concept Example - Specification
Concept Queue_Template(type Entry; evaluates Max_Length: Integer);
uses Std_Integer_Fac, String_Theory;
requires Max_Length > 0;
Type Family Queue is modeled by Str(Entry);
exemplar Q;
constraint |Q| <= Max_Length;
initialization ensures Q = empty_string;
Operation Enqueue(alters E: Entry; updates Q: Queue);
requires |Q| < Max_Length;
ensures Q = #Q o <#E>;
Operation Dequeue(replaces R: Entry; updates Q: Queue);
requires |Q| /= 0;
ensures R = Destring(Substring(0,1,#Q)) and
Q = Substring(1,|#Q|,#Q);
…
Operation Clear(clears Q: Queue);
end Queue_Template;

Enhancement Example
Enhancement Rotating_Capability for Queue_Template;
Operation Rotate(updates Q: Queue);
requires |Q| /= 0;
ensures Q = Substring(1,|#Q|,#Q) o Substring(0,1,#Q);
end Rotating_Capability;
Realization Obvious_Rotate_Realiz
for Rotating_Capability of Queue_Template;
Procedure Rotate(updates Q: Queue);
Var TE: Entry;
Dequeue(TE, Q);
Enqueue(TE, Q);
end Rotate;
end Obvious_Rotate_Realiz;

Facility Example
Facility Queue_Rotate_User_Fac;
uses Queue_Template;
Facility QF is Queue_Template(Integer, 10)
realized by Circular_Array_Realiz
enhanced by Rotating_Capability
realized by Obvious_Rotate_Realiz;
Operation Main();
Procedure
Var Q: QF.Queue;
Enqueue(1, Q);
Enqueue(2, Q);
Enqueue(3, Q);
Rotate(Q);
end Main;
end Queue_Rotate_User_Fac;

Semantic Foundations
 Why do we need semantics?
 Need to define the meaning of programs beyond what
implementations do when they are executed
 Semantics capture state to state transformations
 Semantics help establish that the proof system for
verification is sound and (relatively) complete

RESOLVE Semantics
 Modularity (using only specifications)
 Specifications of Operations and Objects
 Operations with Relational Specifications

Modularity
 States may be “Stuck” States or “Normal” States
 Stuck States
 MW – Manifestly Wrong
 For example, this can be reached by violating the precondition of a
call
 VC – Vacuously Correct
 For example, this can be reached when a called operation ends in a
state that doesn't satisfy the ensures clause of the called operation,
i.e., the called op. is wrong.
 ‘Bottom’ – Non termination
 For example, this can be reached with a non-terminating loop
 Normal States
 A function from variable names to their values.

While Loop Semantics
 If the programmer-supplied invariant is false, then the
code will be invalid (MW).
 If invariant is omitted, it is assumed to be true.
 If the decreasing clause is wrong, then the code will be
invalid (MW).
 If the decreasing clause is omitted and the procedure is
expected to terminate with an ensures clause, then the
code is invalid (MW).

Goal-Oriented Vs. Tabular VC
Generation
 Dr. Krone’s dissertation explains the principles behind the
goal-oriented approach for VC Generation
 J. Krone, “The Role of Verification in Software Reusability,”
The Ohio State University, PhD. Thesis 1988.
 Dr. Heym’s dissertation explains the principles behind the
tabular approach for VC Generation
 W. Heym, “Computer Program Verification: Improvements
for Human Reasoning,” The Ohio State University, PhD.
Thesis 1995.
 There are many issues to move from principles of VC
generation to a practical, automated system.

So how are the Proof Rules
developed?
 Proof rules should be sound and (relatively) complete
 Proof rules need to be mechanizable
 Proof rules need to include the context
 Proof rules need to be generic
 Should work for any data type
 Should be composable

Queue Append
Enhancement Append_Capability for Queue_Template;
Operation Append(updates P: Queue; clears Q: Queue);
requires |P| + |Q| <= Max_Length;
ensures P = #P o #Q;
end Append_Capability;
Realization Iterative_Append_Realiz for Append_Capability of Queue_Template;
uses Std_Boolean_Fac;
Procedure Append(updates P: Queue; clears Q: Queue);
Var E: Entry;
While (Length(Q) /= 0)
changing P,Q,E;
maintaining (P o Q = #P o #Q) and (|P| + |Q| <= Max_Length);
decreasing |Q|;
do
Dequeue(E,Q);
Enqueue(E,P);
end;
end Append;
end Iterative_Append_Realiz;

Queue Append
Var E: Entry;
changing P,Q,E;
decreasing |Q|;
do
Dequeue(E,Q);
Enqueue(E,P);
end;
end Append;
CDP = Operation P(updates t: T1;
clears u:T2);
requires Pre/_t, u _;
ensures Post/_#t, t, #u _;
Operation Declaration Rule:
C {CDP}
____________________________________
C CDP;

Queue Append
Var E: Entry;
changing P,Q,E;
decreasing |Q|;
do
Dequeue(E,Q);
Enqueue(E,P);
end;
end Append;
CDP = Operation P(updates t: T1;
clears u:T2);
ensures Post/_#t, t, #u _;
Operation Realization Rule:
C {CDP}
Assume Pre  T1.Constraint(t) ^
T2.Constraint(u);
Remember;
body;
Confirm Post;
__________________________________
C {CDP} Proc P(… ); body; end P;

Assume (((min_int <= 0) and (0 < max_int)) and ((Last_Char_Num > 0) and
((Max_Length > 0) and (min_int <= Max_Length) and (Max_Length <= max_int))));
Assume ((|Q| <= Max_Length) and ((|P| <= Max_Length) and ((|P| + |Q|) <= Max_Length)));
Remember;
Var E:Entry;
maintaining
(P o Q) = (#P o #Q);
decreasing |Q|;
changing P, Q, E;
do
Dequeue(E, Q);
Enqueue(E, P);
end;
Confirm (P = (#P o #Q) and
Q = empty_string)
Concept Integer_Template;
uses Integer_Theory, Std_Boolean_Fac;
Definition min_int: Z;
Definition max_int: Z;
Constraint min_int <= 0 and 0 < max_int;
Type Family Integer is modeled by Z;
exemplar i;
constraint min_int <= i <= max_int;
initialization ensures i = 0;
Enhancement Append_Capability for
Queue_Template;
Operation Append(updates P: Queue;
clears Q: Queue);
Procedure Declaration Rule
Applied
Concept Character_Template;
uses Std_Boolean_Fac, Std_Integer_Fac;
Definition Last_Char_Num: N;
Constraint Last_Char_Num > 0;
Concept Queue_Template(type Entry;
evaluates Max_Length: Integer);
uses Std_Integer_Fac,
Modified_String_Theory;
requires Max_Length > 0;
Type Family Queue is modeled by
Str(Entry);
exemplar Q;
constraint |Q| <= Max_Length;
initialization ensures Q = empty_string;

Example: Hoare’s Loop Rule
For the while loop code with the invariant “Inv”:
While B
do
S;
end;
The Proof Rule is:
Inv ^ B {S} Inv
____________________________
Inv {While B do S} not(B) ^ Inv

Mechanized Proof Rule
Hoare’s Proof Rule:
Inv ^ B {S} Inv
_________________
Inv
{While B do S}
not(B) ^ Inv
RESOLVE While Loop Rule:
Context/ code;
Confirm Inv; Change Vlist;
Assume Inv and
NQV(RP, P_Val)= P_Exp;
If B then body;
Confirm Inv and
NQV(RP, P_Val)< P_Exp;
else Confirm RP end_if;
Confirm True;
________________________________
C/ code;
While B
maintaining Inv;
decreasing P_Exp;
changing Vlist;
do body end;
Confirm RP;

Development of Proof Rule –
Version 2
 Need to be able to prove generic assertions (not just the invariant)
 Need a syntactic slot for the Invariant
code; Confirm Inv;
Assume Inv and B; body; Confirm Inv;
Assume Inv and not(B); Confirm RP;
_________________________________
code;
While B
maintaining Inv;
do
body
end;
Confirm RP;

Version 3
 Need a Context
Context/ code; Confirm Inv;
Context/ Assume Inv and B; body; Confirm Inv;
Context/ Assume Inv and not(B); Confirm RP;
_________________________________
Context/ code;
While B
maintaining Inv;
do
body
end;
Confirm RP;
Example Queue Append Code:
Assume |P| + |Q| <= Max_Length;
Var E: Entry;
While Length(Q) > 0
maintaining (P o Q = #P o #Q);
do
Dequeue(E,Q);
Enqueue(E,P);
end;
Confirm P = #P o #Q;

Proof Rule –
Version 3
 Need a Context
Context/ Assume Inv and B; body;
Confirm Inv;
Context/ Assume Inv and not(B);
Confirm RP;
_________________________________
Context/ code;
While B
maintaining Inv;
do
body
end;
Confirm RP;
Context/
Var E: Entry;
Confirm P o Q = #P o #Q;
Context/
Assume P o Q = #P o #Q and
not(Length(Q) > 0);
Context/
Length(Q) > 0;
Dequeue(E,Q);
Enqueue(E,P);

Proof Rule –
Version 4
 Need to convert condition statements
to Mathematical Form
Context/ Assume Inv and Math(B);
body; Confirm Inv;
Context/ Assume Inv and not(Math(B));
Confirm RP;
_________________________________
Context/ code;
While B
maintaining Inv;
do
body
end;
Confirm RP;
Context/
Var E: Entry;
Context/
|Q| > 0;
Dequeue(E,Q);
Enqueue(E,P);
Context/
not(|Q| > 0);

Proof Rule –
Version 5
 Need to assume constraints
for variables
C/ code; Confirm Inv;
C/ Assume Inv and Math(B) and
Are_Constraints_Compliant(P, T);
body; Confirm Inv;
C/ Assume Inv and not(Math(B));
Confirm RP;
_________________________________
C Var P:Type1, Var T:Type2/ code;
While B
maintaining Inv;
do
body
end;
Confirm RP;
Context/
Var E: Entry;
Context/
|P| <= Max_Length and
|Q| <= Max_Length and
|Q| > 0;
Dequeue(E,Q);
Enqueue(E,P);
Context/
not(|Q| > 0);

Version 6
 Need to show termination
C/ Assume Inv and Math(B) and Are_Constraints_Compliant(P, T) and P_Val=P_Exp;
body;
Confirm P_Val<P_Exp and Inv;
Confirm RP;
_________________________________
While B
maintaining Inv;
decreasing P_Exp;
do
body
end;
Confirm RP;
Var E: Entry;
While Length(Q) > 0
decreasing |Q|;
do
Dequeue(E,Q);
Enqueue(E,P);
end;

Version 6
 Need to show termination
C/ Assume Inv and Math(B) and
Are_Constraints_Compliant(P, T) and
P_Val=P_Exp; body;
Confirm P_Val > P_Exp and Inv;
Confirm RP;
_________________________________
While B
maintaining Inv;
decreasing P_Exp;
do
body
end;
Confirm RP;
Context/
Var E: Entry;
Confirm Inv;
Context/
|Q| > 0 and
P_Val=|Q|;
Dequeue(E,Q);
Enqueue(E,P);
Confirm P_Val > |Q| and
P o Q = #P o #Q;
Context/
not(|Q| > 0);

Version 7
 Pre-conditions may exist for condition
C/ Confirm Invk_Cond(B);
Assume Inv and Math(B) and
Are_Constraints_Compliant(P, T) and
P_Val=P_Exp; body;
Confirm P_Val<P_Exp and Inv;
Confirm RP;
_________________________________
C/ Var P:Type1, Var T:Type2/ code;
While B
maintaining Inv;
decreasing P_Exp;
do body end;
Confirm RP;
Context/
Var E: Entry;
Context/
Confirm Invk_Cond(Length(Q) > 0);
|Q| > 0 and
P_Val=|Q|;
Dequeue(E,Q);
Enqueue(E,P);
Confirm P_Val > |Q| and
P o Q = #P o #Q;
Context/
not(|Q| > 0);

Final Version Simplify Rule by Converting to If Rule
 Add Changing List
 NQV introduces a new name for each variable listed
by appending a “?”.
Context/ code;
Confirm Inv;
Change Vlist;
Assume Inv and NQV(RP, P_Val)= P_Exp;
If B then body; Confirm Inv and NQV(RP, P_Val)< P_Exp;
Confirm True;
_________________________________
C/ code;
While B
maintaining Inv;
decreasing P_Exp;
changing Vlist;
do body end;
Confirm RP;
Var E: Entry;
While Length(Q) > 0
decreasing |Q|;
changing P, Q, E;
do
Dequeue(E,Q);
Enqueue(E,P);
end;

Final Version
Context/ code;
Confirm Inv; Change Vlist;
Assume Inv and
NQV(RP, P_Val)= P_Exp;
If B then body;
Confirm Inv and
NQV(RP, P_Val)< P_Exp;
Confirm True;
_________________________________
C/ code;
While B
maintaining Inv;
decreasing P_Exp;
changing Vlist;
do body end;
Confirm RP;
Context/
Var E: Entry;
P_Val=|Q|;
If (Length(Q) > 0) then
Dequeue(E,Q);
Enqueue(E,P);
Confirm P_Val<|Q| and
P o Q = #P o #Q;
Else Confirm P = #P o #Q;
end_if;
Confirm True;

Assertive Code
Assume (((min_int <= 0) and (0 < max_int)) and ((Last_Char_Num > 0) and
((Max_Length > 0) and (min_int <= Max_Length) and (Max_Length <= max_int))));
Assume ((|Q| <= Max_Length) and ((|P| <= Max_Length) and ((|P| + |Q|) <= Max_Length)));
Remember;
Var E:Entry;
maintaining
(P o Q) = (#P o #Q);
decreasing |Q|;
changing P, Q, E;
do
Dequeue(E, Q);
Enqueue(E, P);
end;
Confirm (P = (#P o #Q) and
Q = empty_string)

Queue Append VC Generation
Part 1:
Assume ((Last_Char_Num > 0) and(((min_int <= 0) and(0 <
max_int)) and((Max_Length > 0) and(min_int <=
Max_Length) and (Max_Length <= max_int))));
Assume ((|Q| <= Max_Length) and((|P| <= Max_Length)
and((|P| + |Q|) <= Max_Length)));
Remember; Var E:Entry;
Confirm (P o Q) = (#P o #Q);
Change P:Modified_String_Theory.Str(Entry),
Q:Modified_String_Theory.Str(Entry), E:Entry;
Assume ((P o Q) = (#P o #Q) and P_val' = |Q|);
Confirm true;
Assume |Q| /= 0;
Dequeue(E, Q);
Enqueue(E, P);
Confirm ((P o Q) = (#P o #Q) and (|Q| < P_val'));

Queue Append VC Generation
Part 1:
Q:Modified_String_Theory.Str(Entry), E:Entry, E:Entry;
Confirm true;
Assume |Q| /= 0;
Dequeue(E, Q);
Enqueue(E, P);
Confirm ((P o Q) = (#P o #Q) and(|Q| < P_val'));
CDP = Operation P( updates t: T1; alters u: T2);
ensures Post/_ #t, #u, t _;
Operation Call Rule:
C {CDP} code; Confirm Invk_Cond(P(a,b));
Assume Post[t⇝NQV(result, a), #t⇝a, #u⇝b];
Confirm result[a⇝NQV(result, a)];
____________________________________________
C {CDP} code; P( a, b); Confirm result/_ a, b _ ;

Operation Call Rule Applied
Confirm true;
Assume |Q| /= 0;
Dequeue(E, Q);
Confirm (|P| < Max_Length);
Assume P' = (P o <E>);
Confirm ((P' o Q) = (#P o #Q) and(|Q| < P_val'))
Operation Enqueue(alters E: Entry;
updates Q: Queue);
requires |Q| < Max_Length;
ensures Q = #Q o <#E>;

Assume Rule Applied
Confirm true;
Assume |Q| /= 0;
Dequeue(E, Q);
Confirm (|P| < Max_Length);
Confirm (((P o <E>) o Q) = (#P o #Q) and(|Q| < P_val'))

Confirm Rule Applied
Confirm true;
Assume |Q| /= 0;
Dequeue(E, Q);
Confirm ((|P| < Max_Length) and
(((P o <E>) o Q) = (#P o #Q) and(|Q| < P_val')))

Operation Call Rule, Assume
Rule, and Confirm Rule Applied
Confirm true;
Assume |Q| /= 0;
Confirm (|Q| /= 0 and(Q = (<E'> o Q') implies
((|P| < Max_Length) and
(((P o <E'>) o Q') = (#P o #Q) and
(|Q'| < P_val')))))

Assume Rule and Confirm Rule
Remember;
Var E:Entry;
Confirm ((P o Q) = (#P o #Q) implies
(|Q| /= 0 implies
(|Q| /= 0 and (Q = (<E'> o Q') implies
((|P| < Max_Length) and
(((P o <E'>) o Q') = (#P o #Q) and
(|Q'| < |Q|)))))))

Change Rule Applied
Remember;
Var E:Entry;
Confirm ((P' o Q'') = (#P o #Q) implies
(|Q''| /= 0 implies
(|Q''| /= 0 and (Q'' = (<E'> o Q') implies
((|P'| < Max_Length) and
(((P' o <E'>) o Q') = (#P o #Q) and
(|Q'| < |Q''|)))))))
Change Rule:
C code;
Confirm result[x⇝NQV(result, x)];
_____________________________________________
C code; Change x; Confirm result;

Confirm Rule Applied
Remember;
Var E:Entry;
Confirm ((P o Q) = (#P o #Q) and
((P' o Q'') = (#P o #Q) implies
(|Q''| /= 0 implies
(((P' o <E'>) o Q') = (#P o #Q) and
(|Q'| < |Q''|))))))))

Variable Declaration Rule
Remember;
Confirm ((P o Q) = (#P o #Q) and
((P' o Q'') = (#P o #Q) implies
(|Q''| /= 0 implies
(((P' o <E'>) o Q') = (#P o #Q) and
(|Q'| < |Q''|))))))))
Variable Declaration Rule:
C code; Assume T.Is_Initial(v); Confirm result;
_____________________________________________
C code; code; Var v: T; Confirm result;

Remember Rule
Confirm ((P o Q) = (P o Q) and
((P' o Q'') = (P o Q) implies
(|Q''| /= 0 implies
(((P' o <E'>) o Q') = (P o Q) and
(|Q'| < |Q''|))))))))
Remember Rule:
C code; Confirm result[#s⇝s, #t⇝t];
_____________________________________________
C code; Remember;
Confirm result/_ s, #s, t, #t, u, v, ⋯ _;

Assume Rule(s)
Confirm ((((min_int <= 0) and(0 < max_int)) and
((Last_Char_Num > 0) and((Max_Length > 0) and
(min_int <= Max_Length) and (Max_Length <= max_int))))
implies
(((|Q| <= Max_Length) and((|P| <= Max_Length) and((|P| +
|Q|) <= Max_Length))) implies
((P o Q) = (P o Q) and ((P' o Q'') = (P o Q) implies
(|Q''| /= 0 implies
(|Q''| /= 0 and
(Q'' = (<E'> o Q') implies
(((P' o <E'>) o Q') = (P o Q) and(|Q'| < |Q''|))))))))))

Final VCs:
Base Case of the Invariant of While Statement in Procedure
Append: Iterative_Append_Realiz.rb(8)
Goal:(P o Q) = (P o Q)
Given:
1: (min_int <= 0)
2: (0 < max_int)
3: (Last_Char_Num > 0)
4: (Max_Length > 0)
5: (min_int <= Max_Length) and (Max_Length <= max_int)
6: (|Q| <= Max_Length)
7: (|P| <= Max_Length)
8: ((|P| + |Q|) <= Max_Length)
(1 of 5)

Final VCs:
Requires Clause of Dequeue in Procedure Append:
Iterative_Append_Realiz.rb(11)
Goal:|Q''| /= 0
Given:
1: (min_int <= 0)
2: (0 < max_int)
4: (Max_Length > 0)
8: ((|P| + |Q|) <= Max_Length)
9: (P' o Q'') = (P o Q)
10: |Q''| /= 0
(2 of 5)

Final VCs:
Requires Clause of Enqueue in Procedure Append:
Goal:(|P'| < Max_Length)
Given:
1: (min_int <= 0)
2: (0 < max_int)
4: (Max_Length > 0)
8: ((|P| + |Q|) <= Max_Length)
9: (P' o Q'') = (P o Q)
10: |Q''| /= 0
11: Q'' = (<E'> o Q')
(3 of 5)

Final VCs:
Inductive Case of Invariant of While Statement in Procedure
Append: Iterative_Append_Realiz.rb(8)
Goal:((P' o <E'>) o Q') = (P o Q)
Given:
1: (min_int <= 0)
2: (0 < max_int)
4: (Max_Length > 0)
8: ((|P| + |Q|) <= Max_Length)
9: (P' o Q'') = (P o Q)
10: |Q''| /= 0
11: Q'' = (<E'> o Q')
(4 of 5)

Final VCs:
Termination of While Statement in Procedure Append:
Goal:(|Q'| < |Q''|)
Given:
1: (min_int <= 0)
2: (0 < max_int)
4: (Max_Length > 0)
8: ((|P| + |Q|) <= Max_Length)
9: (P' o Q'') = (P o Q)
10: |Q''| /= 0
11: Q'' = (<E'> o Q')
(5 of 5)

Assertive Code – Part 2
Assume (((min_int <= 0) and(0 < max_int))
and((Last_Char_Num > 0) and((Max_Length > 0) and(min_int
<= Max_Length) and (Max_Length <= max_int))));
Remember;
Var E:Entry;
Assume (P o Q) = (#P o #Q);
Confirm true;
Assume |Q| = 0;
Confirm (P = (#P o #Q) and Q = empty_string)

Additional VCs (from Part 2):
Ensures Clause of Append: Iterative_Append_Realiz.rb(13)
Goal: P' = (P o Q)
Given:
1: (min_int <= 0)
2: (0 < max_int)
4: (Max_Length > 0)
8: ((|P| + |Q|) <= Max_Length)
9: (P' o Q') = (P o Q)
10: |Q'| = 0
(1 of 2)

Additional VCs (from Part 2):
Ensures Clause of Append: Iterative_Append_Realiz.rb(13)
Goal: Q' = empty_string
Given:
1: (min_int <= 0)
2: (0 < max_int)
4: (Max_Length > 0)
8: ((|P| + |Q|) <= Max_Length)
9: (P' o Q') = (P o Q)
10: |Q'| = 0
(2 of 2)

Data Abstraction Verification
Array
Template
Array
Realization
Facility
Queue
Template
=Array
Realization

Data Abstraction Verification
Conceptual
Space
Representation
Space
Constraints ConventionsCorrespondence

Modular Verification
Queue
Template
Sort
Realization
Queue_Sort
FacilitySort
Specification
=Array
Realization

Evaluation
Experimental Evaluation
Benchmarks
Educational Evaluation
“What If” Example

Benchmark #1:
 Adding and Multiplying Numbers
 Problem Requirements:
Verify an operation that adds two numbers by
repeated incrementing. Verify an operation that
multiplies two numbers by repeated addition,
using the first operation to do the addition.
Make one algorithm iterative, the other
recursive.

Benchmark #2:
 Binary Search in an Array
Verify an operation that uses binary search to
find a given entry in an array of entries that are
in sorted order

Benchmark #3:
 Sorting a Queue
Specify a user-defined FIFO ADT that is generic
(i.e., parameterized by the type of entries in a
queue). Verify an operation that uses this
component to sort the entries in a queue into
some client-defined order.

Benchmark #4:
 Layered Implementation of a Map ADT
Verify an implementation of a generic map
ADT, where the data representation is layered
on other built-in types and/or ADTs.

Benchmark #5:
 Linked-List Implementation of a Queue ADT
Verify an implementation of the queue type
specified in benchmark #3, using a linked data
structure for the representation.

Educational Evaluation
 In use in Classrooms
 Students write RESOLVE code and generate VCs
 Used to evaluate students understanding of VC
Generation
 Used to evaluate their ability to do proofs of VCs
 Used by students at various institutions:
 Clemson University
 Denison University
 Western Carolina University
 University of Alabama
 Depauw University
 …

Conclusions and Contributions
 A Mechanical, Scalable, and Full Verification System is
attainable
 Mechanization of proof rules for the RESOLVE language
 VCs can be generated for the RESOLVE language
 Educational Uses
 Experimentation with Benchmarks

Future Directions
 Complete Semantics
 Additional Experimentation
 VCs should be automatically proved
 Minimalist Prover for RESOLVE
 Verified Verifier
 Performance Profiles
 Educational Tool

Harton-Presentation

More Related Content

What's hot

Viewers also liked

Similar to Harton-Presentation

Harton-Presentation