Invariant Patterns for Program
Reasoning
Andrew Ireland
Dependable Systems Group
School of Mathematical & Computer Sciences
Heriot-Watt University
Edinburgh
Dependable Systems Group
© Andrew Ireland
Outline
• Context and background
• The problem
• Our approach
• Results and future horizons
Dependable Systems Group
© Andrew Ireland
Context
• Investigate the role of proof planning within the
SPARK approach to high integrity software
• EPSRC Critical Systems programme (GR/R24081)
• Praxis Critical Systems (collaborator)
• Bill Ellis (Research Associate)
• Tommy Ingulfsen (Undergraduate Student)
Dependable Systems Group
© Andrew Ireland
The SPARK Approach
• A subset of Ada that eliminates potential
ambiguities and insecurities (Praxis Critical Systems)
• Supports data & information flow analysis and
formal verification via code level annotations
• Supports “correctness-by-construction” and is
advocated by US National Cyber Security
Partnership (April 2004)
• Applications include SHOLIS: UK MoD’s first
Def Standard 00-55 project
Dependable Systems Group
© Andrew Ireland
SPARK
code
Examiner
Proofs
SPADE
Simplifier
Dependable Systems Group
Verification
conditions
© Andrew Ireland
SPARK
code
Failure!
Dependable Systems Group
Examiner
Verification
conditions
SPADE
Simplifier
© Andrew Ireland
SPARK
code
Examiner
Verification
conditions
Failure!
SPADE
Proof Checker
Dependable Systems Group
© Andrew Ireland
SPARK
code
Examiner
Verification
conditions
SPADE
Proof Checker
Dependable Systems Group
© Andrew Ireland
SPARK
code
Examiner
Verification
conditions
NuSPADE
Command
file
SPADE
Proof Checker
Dependable Systems Group
© Andrew Ireland
Achievements
Proof automation with respect to:
• Exception freedom proofs: prove that no exceptions
will be raised at runtime, e.g. buffer overflows
[ ASE-2003, IFM-2004 ]
• Partial correctness proofs: prove program correct
with respect to a Floyd-Hoare style specification
[ MICAI-2004 ]
Dependable Systems Group
© Andrew Ireland
Program Reasoning Challenge
• Long history: Goldstine & von Neumann 1947,
Turing 1949, Floyd 1967, Hoare 1969
• Strong AI focus dating back to 1970s: Wegbreit,
German, Katz & Manna, …
• Renewed interest: proof carrying code, SLAM
(Microsoft), ESC/Java (HP), SPARK (Praxis),
Verifying Compiler – UK “grand challenges” in
computing (Hoare)
• Key challenges: proof automation and proof
annotations, e.g. loop invariants
Dependable Systems Group
© Andrew Ireland
NuSPADE
Investigate the role of proof planning within
the SPARK approach to high integrity software
program
analysis
NuSPADE
specification
analysis
proof-failure
analysis
Dependable Systems Group
© Andrew Ireland
Proof Planning
• Use of high-level proof outlines, known as proof
plans, to guide proof search
• Supports middle-out reasoning, i.e. the use of meta
variables to delay choice during proof search
• Automatic proof patching via proof failure analysis,
e.g. conjecture generalization, lemma discovery,
induction revision, case splitting, loop invariant
discovery, fixing faulty conjectures
• Inductive and non-inductive applications
Dependable Systems Group
© Andrew Ireland
A Broader View Of Proof Planning
Invariant Patterns
Conjectures
Theory
Proof planning
methods + critics
Proof checking
tactics
Dependable Systems Group
© Andrew Ireland
Bubble Sort Example
package BubbleSort is
Min: constant:= 0;
Max: constant:= 9;
subtype Index_Type is Integer range Min..Max;
type Array_Type is array(Index_Type) of Integer;
…
procedure Bubble_Sort(Table: in out Array_Type);
--# derives Table from Table;
--# pre true;
--# post Ordered(Table, Min, Max) and
--#
Perm(Table, Table~);
end BubbleSort;
Dependable Systems Group
© Andrew Ireland
Bubble Sort
package body BubbleSort is
…
procedure Bubble_Sort(Table: in out Array_Type)is
T: Integer;
begin
for I in Index_Type range 1..Max loop
for J in reverse Index_Type range I..Max loop
if Table(J-1) > Table(J) then
T:= Table(J-1);
Table(J-1):= Table(J);
Table(J):= T;
end if;
end loop;
end loop;
end Bubble_Sort;
end BubbleSort;
Dependable Systems Group
© Andrew Ireland
Program Analysis
• Proof construction properties
1  i  i  max
i  j  j  max
• Proof search properties
mono_inci, for_loop_i 
mono_dec j, for_loop_j 
constant i, for_loop_j 
Dependable Systems Group
© Andrew Ireland
Specification Analysis
• Definition
ordered  A, L, U  
P : int.L  P  P  U   ele A, P   ele A, P  1
• Unfolded specification
p : int.0  p  p  max  eletable,  p  eletable,  p 1
• Schematic specification
p : int.0  p  p  F1 i   eletable,  p  eletable,  p 1
• Schematic specification
p : int.G1  j   p  p  max  eletable,  p  eletable,  p 1
Dependable Systems Group
© Andrew Ireland
Proof-Failure Pattern
L
T1 T2
U
1. A goal is unprovable within the current proof
context and matches the following pattern:
ele A, T1 Rel ele A, T 2



blocked
2. Terms T1 and T2 contain a counter variable
in common
Dependable Systems Group
© Andrew Ireland
Proof Patch
Proof patch involves generalizing the goal, i.e.
 X : int .L  X  X  T1 




  Y : int .T1  Y  Y  U  
 
 
ele A, X  Rel ele A, Y  
 
Generalized goal represents an auxiliary invariant
Dependable Systems Group
© Andrew Ireland
Alternative Generalizes
L
Dependable Systems Group
T1 T2
U
© Andrew Ireland
Proof-Failure Analysis
eletable, i  F2 i  1  eletable, i  F2 i  1  1
 p : int .0  p  p  i  F2 i  1 



  q : int .i  F2 i  1  q  q  max 

 
 
ele table,  p   ele table, q  
 
Dependable Systems Group
© Andrew Ireland
Outer-Loop Invariant
 p : int .0  p  p  i  2 



 
  q : int .i  2  q  q  max 
 
 
ele table,  p   ele table, q  
 
1  i  i  max
• Invariant states that the array table is partitioned
into two parts, i.e. all elements in the lower part
are less-than-or-equal to those in the upper part
• Invariant generated via program, specification and
proof-failure analysis
Dependable Systems Group
© Andrew Ireland
Results & Future Horizons
• Industrial focus is on exception freedom proofs,
so partial correctness examples drawn mainly
from text books
• Currently exploring the use of external
reasoners to support planning and program
analysis, e.g. CLP, Simplify (ESC/Java)
• Building on NuSPADE project:
Knowledge transfer project with Praxis (2005)
NASA Ames potential collaboration
Dependable Systems Group
© Andrew Ireland
Conclusion
• Integrated approach to program reasoning, i.e.
program, specification and proof-failure analysis
• Proof planning provides the basis for integration
• Integration broadens the role of proof planning,
i.e. proof planning exploits program knowledge
Dependable Systems Group
© Andrew Ireland