Proof Transformations for Evolutionary Formal Software Development Axel Schairer
Dieter Hutter
[email protected],
[email protected] German Research Center for Artificial Intelligence (DFKI GmbH) Stuhlsatzenhausweg 3, 66123 Saarbrucken, ¨ Germany
AMAST’2002, September 9-13, 2002
Overview Background and motivation Problem description Solution: proof transformations Example transformations Conclusions and future work
Schairer/Hutter
AMAST’2002
Background: Formal Development Formal Methods in early phases of development process Security model – (axiomatic) specifications of – high level system functionality/behaviour – (security) properties of the system Proof Security Properties
System Specification sat
Model of computation/spec. formalism
Schairer/Hutter
AMAST’2002
Background: Formal Development Security models – What properties is the system supposed to have? – Which details do I need to model to express them? – Iterate! ˆ of rigorous inspections to (Interactive) proofs play the role – find errors – assess design decision Changes are core part of process, not accidental
Schairer/Hutter
AMAST’2002
Background: Formal Development Large, structured specifications Translation of specification into verification conditions (VCs) VCs discharged with theorem prover (partially interactive)
tool support needed (e.g. Verification Support Environment, Inka & Maya, . . . ) Need support for: – Incremental development: add functionality in stages – Evolutionary development: change specification according to experience gained in preceding steps, e.g. failed proof attempts
Schairer/Hutter
AMAST’2002
Problem Several aspects, typically specified incrementally E.g.: file store, access control, memory management, process management, . . . Several intuitive ‘dimensions’ E.g.: state space, commands, properties, . . . Aspects and dimensions partly independent of each other intuitively, but not formally
Schairer/Hutter
AMAST’2002
Examples for Dependencies Adding/changing a command – Many properties are invariants over execution of command sequences – These proofs affected because induction axiom (case distinction) is changed Adding or removing slot of state space (used by some commands and for some properties only) – All properties affected – All commands affected Dependencies orthogonal to structure of specification Many dependencies are not deep (e.g. syntactical) Schairer/Hutter
AMAST’2002
State of the Art Change specification Compute new verification conditions Reconsider proofs – Some are still valid – Some have to be patched trivially – Some have to be heavily re-engineered – Some can be repaired by heuristic replay – Some have to be constructed from scratch
Patching (of proofs, proof scripts etc.) done ad hoc/manually
Works, but: Changes are prohibitively expensive Evolutionary development difficult
Schairer/Hutter
AMAST’2002
Motivation Situation handled quite well in informal reasoning Claim: We can support the same kind of reasoning in a formal setting! Example: assume interpreter for set of commands – Commands specified by pre- and postconditions on interpreter state – Properties proved for execution traces, e.g. invariants
Schairer/Hutter
AMAST’2002
Motivation
case split
ind
Add a new command! Schairer/Hutter
AMAST’2002
Motivation
Schairer/Hutter
case split
ind
AMAST’2002
Motivation
∆ ψ
Γ ϕ
!
∆
Γ ϕ
Γϕ
∆ "
Need to strengthen precondition ϕ of command i to ϕ ψ Schairer/Hutter
AMAST’2002
Motivation
∆
Γ ϕ ψ
"
∆ ψ
Γ ϕ ψ
*
)
+
(
'
&
"
% $
#
Schairer/Hutter
"
Γϕ ψ
∆
AMAST’2002
Proposed Solution Transformation of developments (specification together with proofs) Provide preconceived basic transformation steps Use specialized knowledge to support repair of proofs according to specification change Take care of low-level changes May introduce new open goals Result: Tool to simulate the informal mode of reasoning in a completely rigorous way Turns out to be quite general Schairer/Hutter
AMAST’2002
Proposed Solution
,
,
, -
Sig: Sent:
.
/ 0
Schairer/Hutter
AMAST’2002
Proposed Solution
, -
-
4
1 -
5
2 6
3
Schairer/Hutter
,
,
Sig: Sent:
,
,
,
Sig: Sent:
AMAST’2002
Proposed Solution
, -
-
:
7 -
;
8
=
ind
Add a new command!
Schairer/Hutter
AMAST’2002
Proposed Solution
N
M
L
K
J I H
G F
Schairer/Hutter
case split
ind
AMAST’2002
Proposed Solution
, -
-
R
O -
S
P T
Q
Schairer/Hutter
,
,
Sig: Sent:
,
,
,
Sig: Sent:
AMAST’2002
Proposed Solution
, -
-
X
U -
Y
V Z
W
Schairer/Hutter
,
,
Sig: Sent:
,
,
,
Sig: Sent:
AMAST’2002
Proposed Solution
, -
-
^
[ -
_
\ `
]
Schairer/Hutter
,
,
Sig: Sent:
,
,
,
Sig: Sent:
AMAST’2002
Proposed Solution
, -
-
d
a -
e
b f
c
Schairer/Hutter
,
,
Sig: Sent:
,
,
,
Sig: Sent:
AMAST’2002
Proposed Solution
, -
-
j
g -
k
h l
i
Schairer/Hutter
,
,
Sig: Sent:
,
,
,
Sig: Sent:
AMAST’2002
Proposed Solution
, -
-
p
m -
q
n r
o
Schairer/Hutter
,
,
Sig: Sent:
,
,
,
Sig: Sent:
AMAST’2002
Example Set of Basic Transformations add/remove type, add/remove function, add/remove predicate add/remove axiom, add/remove lemma add/remove constructor rename type/function/predicate/constructor add/remove argument swap arguments replace occurrence, with special cases – wrap – capture Schairer/Hutter
AMAST’2002
Example Set of Basic Transformations Basic transformations extracted from examples and problems that occurred frequently in past projects and case studies Additional basic transformations due to symmetry reasons This example set is: – Dependent on specification formalism – Dependent on relation between specification and proof obligations – Not dependent on application domain
Schairer/Hutter
AMAST’2002
Example Set of Basic Transformations Different effects of transformations – Extending/restricting signature – Changing existing signature items – In particular: changing induction scheme – Adding/removing assumptions and proof obligations – Replacing (sub-)formulae Basic transformation can have more than one effect
Schairer/Hutter
AMAST’2002
Changing Signature Item
s
Example: Add argument, e.g. change operation f : τ1 τ2 τ to f : τ1 τ2 τ3 τ t
s
s
t
Add new (dummy) constant a : τ3 to specification v
Replace each (sub-) term of the form f t1 t2 by f t1 t2 a throughout specification and proofs w
u
v
v
w
u
All objects (formulae, terms) well-formed (type-correct) Proofs again valid, structure unchanged Occurrences of a can later be changed into appropriate terms using change occurrence Schairer/Hutter
AMAST’2002
Changing Formulae
Pi
x
Pi (T-3) Ti A
z
y
x y
Ti A
z P2
x
P2 P1
x
P1
(T-2)
{ x { x
y
y
|{
||
z
z
T A
z
x y
S
x}
y
z
T X
z
T A
y
}
S
Q A P1 Pn
x
P
{ z zz z y y y y { || { |
Q X @ T1 X @ Tn X
x}
P
(T-4)
For details see [EFSD 2002] Schairer/Hutter
AMAST’2002
Changing Formulae – Dependent Subproof Example for wrap formula (same polarity)
Γ1 ϕ ψ Γ2 "
v
v
v
v
Schairer/Hutter
∆
~
Γ1 ϕ Γ2
∆
AMAST’2002
Changing Formulae – Dependent Subproof Example for wrap formula, same polarity
v
v
v
"
v
v
v
v
Schairer/Hutter
∆
~
Γ1 ϕ Γ2
∆ ∆
"
Γ1 ϕ ψ Γ2 Γ1 ϕ ψ Γ2
:l
AMAST’2002
Changing Formulae – Dependent Subproof Example for wrap formula, same polarity
v
v
v
"
v
v
v
v
Schairer/Hutter
∆
~
Γ1 ϕ Γ2
∆ ∆
"
Γ1 ϕ ψ Γ2 Γ1 ϕ ψ Γ2
:l
AMAST’2002
Changing Formulae – Dependent Subproof Example for wrap formula, same polarity
Γ1 ϕ ψ Γ2
∆
v
"
v
v
v
v
v
v
v
v
Schairer/Hutter
v
v
∆
~
Γ1 ϕ Γ2
~
∆
Γ1 ϕ Γ2
"
∆ ∆
Γ1 ϕ ψ Γ2 Γ1 ϕ ψ Γ2
:l
AMAST’2002
Changing Formulae – Dependent Subproof Example for wrap formula, same polarity
v
v
v
"
v
v
v
v
∆
~
Γ1 ϕ Γ2
:l
v
v
v
∆
Γ1 ϕ Γ2 ∆ Γ1 ψ Γ2 Γ1 ϕ ψ Γ2 ∆ v
:l
v
v
v
v
Schairer/Hutter
∆
~
Γ1 ϕ Γ2
"
∆ ∆
Γ1 ϕ ψ Γ2 Γ1 ϕ ψ Γ2
AMAST’2002
Changing Formulae – Dependent Subproof Example for wrap formula, same polarity
v
v
v
"
v
v
v
v
∆
~
Γ1 ϕ Γ2
:l
v
v
v
∆
Γ1 ϕ Γ2 ∆ Γ1 ψ Γ2 Γ1 ϕ ψ Γ2 ∆ v
:l
v
v
v
v
Schairer/Hutter
∆
~
Γ1 ϕ Γ2
"
∆ ∆
Γ1 ϕ ψ Γ2 Γ1 ϕ ψ Γ2
AMAST’2002
Changing Induction Scheme Example: Add constructor ci to τ For each induction over τ, add new subgoal, corresponding to the new constructor
ind τ
Schairer/Hutter
ind τ
AMAST’2002
Changing Induction Scheme τ
t
Example: Add argument to constructor function c : τ1
For each induction over τ .. ξ Γ ∆ y : τ1 A c y Γ ∆ x:τ A x
v
w
w
u
u
ind τ
v
w
u
.. ξ ∆ y : τ1 z : τ2 A c y z Γ ∆ x:τ A x
v
v
v
w
w
u
u
Γ
ind τ
v
w
u
ξ transformed to ξ by combination of wrap quantifier and add argument for non-constructor Schairer/Hutter
AMAST’2002
Completeness and Adequacy Can transform any specification into any other? Yes, but . . . (pointless) Without losing proof effort unless absolutely necessary? No, but . . . (ill-defined) Interested in adequacy: – Definitely no worse than without – Common gotchas in past projects and case studies work – Reconstruction of a case study for incremental development works – Open ended: if a transformation is missing, we simply provide it Schairer/Hutter
AMAST’2002
Example (Sketch) ¨ Simplified reconstruction of Failure Transformation [Gartner/Mantel, 2000]
First: – Network of reliable processes – Each process runs a local, non-deterministic program – Verify: reliable broadcast
Then: – Add auxiliary datatypes, functions, and definitions – Add failure to possible state of processes – Add crash action as an additional command – Strengthen preconditions of other commands – Weaken property (reliable broadcast for running processes only) – Tackle new open goals (same as in paper)
Schairer/Hutter
AMAST’2002
Implementational Issues Transformations need not be part of trusted kernel (check proofs afterwards) Independent of paradigm for proof search Transformation can produce proofs that cannot be produced by search heuristics directly Dependent on “appropriate” explicit representation of proofs and interface Depends on rich and flexible interface to specification front-end and theorem prover
Schairer/Hutter
AMAST’2002
Future Work Consider more complicated dependency between specification and verification conditions Better integration with structuring mechanism (exploiting modularity of systems or specifications) Extend to equality reasoning Implement into existing verification tool More examples
Schairer/Hutter
AMAST’2002
Conclusions Basic specification transformations – Restricted set of changes – Change language, change subformulae Extended to proof transformations – Use knowledge about particular specification transformation – Minimal changes, structurally similar proof, possibly new open goals Complements other methods to minimize effort for changing specifications Works and is extremely useful! Schairer/Hutter
AMAST’2002
Proof Transformations for Evolutionary Formal Software Development Axel Schairer
Dieter Hutter
[email protected],
[email protected] German Research Center for Artificial Intelligence (DFKI GmbH) Stuhlsatzenhausweg 3, 66123 Saarbrucken, ¨ Germany
AMAST’2002, September 9-13, 2002
Changing Formulae – Dependent Subproof Example for capture, γ-formula
Γ1 z ϕ z Γ2 v
v
v
v
Schairer/Hutter
∆
~
Γ1 ϕ c Γ2
∆
AMAST’2002
Changing Formulae – Dependent Subproof Example for capture, γ-formula
Γ1 z ϕ z ϕ c Γ2 ∆ :l Γ1 z ϕ z Γ2 ∆ v
v
v
v
v
v
v
Schairer/Hutter
∆
~
Γ1 ϕ c Γ2
AMAST’2002
Changing Formulae – Dependent Subproof Example for capture, γ-formula
Γ1 z ϕ z ϕ c Γ2 ∆ :l Γ1 z ϕ z Γ2 ∆ v
v
v
v
v
v
v
Schairer/Hutter
∆
~
Γ1 ϕ c Γ2
AMAST’2002
Related Work Idea similar to Cynthia (an SML program editor) [Whittle 97, 99] Different from correctness-preserving transformations Orthogonal to – Heuristic replay – Proof scripts and script maintenance Proof transformations technically similar to low-level reuse, in particular extension of [Felty/Howe 94]
Schairer/Hutter
AMAST’2002
