Proof Transformations for Evolutionary Formal Software Development

4 downloads 203 Views 117KB Size Report
Evolutionary Formal Software Development ... Formal Methods in early phases of development process ... Example: assume interpreter for set of commands.
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