Lecture #8 : Program Specification and Proof Rules for Program Correctness

Topics 1) Formal Specification for Imperative programs 1.1) A Little Programming Language 1.2) Partial Correctness Specification 1.3) Total Correctness Specification 1.4) Auxiliary Variables in Program Specifications 1.5) Examples of various Program Specifications 2) Floyd-Hoare Logic for proving Partial Correctness 2.1) Axiom for SKIP, Assignment, Sequential commands 2.2) Rule for Precondition Strengthening 2.3) Rule for Postcondition Weakening 2.4) The Block Rule 2.5) The conditional Rule 2.6) The while Rule - Invariant 2.7) Finding Invariants

Overview
This lecture is concerned with formal specification Natural language specifications are often inconsistent ambiguous difficult to follow (long rambling sentences) cannot be reasoned about

Formal specifications
A formal specification: describes a programs effect in a mathematically precise notation Formal specifications: force the software designer to think more precisely about what the specification says provide less scope for confusion about the meaning of the specification can be used to prove the correctness of programs can be used to generate test cases Our formal notation: is based on predicate calculus applies to imperative programs is due to Professor C.A.R. Hoare of Oxford

Some Terminology
The symbols V, V1, , Vn stand for arbitrary variables. For example, X, R, Q. The symbols E, E1, , En stand for arbitrary expressions (or terms). For example, X + 1, Y!, Z The symbols C, C1, , Cn stand for arbitrary commands of our programming language which will be discussed next. The symbols S, S1, , Sn stand for arbitrary statements. These are conditions (assertions) like X < Y, X2 = 1, which can be either true or false. Note that statements are used for expressing conditions on program variables, and they are parts of specifications.

A Little Programming Language

The following is the syntax of integer expressions in our language. E ::== N | V | E1 + E2 | E1 E2 | E1 E2 | where N is any integer. The following is the syntax of boolean expressions in our language. B ::== T | F | E1 = E2 | E1 E2 | where T stands for true and F stands for false. The following is the syntax of commands in our language. C ::== SKIP | V := E | C1 ; C2 | IF B THEN C1 ELSE C2 | BEGIN VAR V1; ; VAR Vn; C END | WHILE B DO C

Imperative Programs
Imperative Programming Language is a kind of programming language which allows destructive assignment, eg. x := y. Examples of imperative programming languages are PASCAL, C, etc. Our litter programming language is also an imperative prog. lang. Executing an imperative program has the effect of changing the state A state consists of the values of program variables. Note that languages more complex than those described here may have states consisting of other things than the values of variables (e.g. I/O) To use an imperative program first establish an initial state i.e. set some variables to have values of interest then execute the program (to transform the initial state into a final one) One then inspects the values of variables in the final state to get the desired results

Specification of Imperative Programs

Acceptable Initial State X is greater than zero X>0

Acceptable Final State Y is the square root of X Y=X

Action of the Program

Partial Correctness Specification

An expression { P } C { Q } is called a partial correctness specification P is called its precondition Q its postcondition C is an imperative program. P and Q are some kinds of mathematical and logical expressions. { P } C { Q } is true if whenever C is executed in a state satisfying P and if the execution of C terminates then the state in which Cs execution terminates satisfies Q Definition 1 Partial Correctness {P}C{Q} [ ( C is executed in state P C terminates ) C terminates in state Q ] These specifications are partial because for { P } C { Q } to be true it is not necessary for the execution of C to terminate when started in a state satisfying P. It is only required that if the execution terminates, then Q holds

Some Examples
{ X = 1 } Y:=X { Y = 1 } this says that if the command Y := X is executed in a state satisfying the condition X = 1 i.e. a state in which the value of X is 1 then, if the execution terminates (which it does for this case) then condition Y = 1 will hold clearly this specification is true. { X = 1 } Y:=X { Y = 2 } this says that if the execution of Y := X terminates when started in a state satisfying X =1 then Y=2 will hold this is clearly false. {X = 1 } WHILE T DO SKIP { Y=2 } Note that T stands for true. this specification is true! This is because the command WHILE T DO SKIP does not terminate. (See definition 1 for the partial correctness)

Total correctness Specification

A stronger kind of specification is a total correctness specification There is no standard notation for such specification We shall use [P] C [Q] where - P and Q stand for pre-condition and post-condition, and - C is an imperative program. A total correctness specification [P] C [Q] is true if and only if Whenever C is executed in a state satisfying P, then the execution of C terminates After C terminates Q holds Definition 2 Total Correctness [P]C[Q] [ C is executed in state P ( C terminates C terminates in state Q ) ]

10

Some Examples
[X = 1] Y:=X [Y = 1] this says that if the command Y := X is executed in a state satisfying the condition X = 1 then, the execution will terminate and the condition Y =1 will hold of the final state clearly this specification is true [X = 1] Y:=X; WHILE T DO SKIP [Y = 1] this says that execution of Y:=X; WHILE T DO SKIP terminates when started in a state satisfying X = 1 after which Y = 1 will hold this is clearly false

11

Total Correctness
Informally Total correctness = Termination + Partial correctness Total correctness is the ultimate goal Usually easier to show partial correctness and termination separately Termination is usually straightforward to show, but there are examples where it is not: no one knows whether the program below terminates for all values of X WHILE X >1 DO IF ODD(X) THEN X := (3 X) + 1 ELSE X := X DIV 2 If X = 2, this program terminates. But how about X = 3 ? The expression X DIV 2 produces the result of rounding down X/2 to a whole number. Exercise: Write a specification which is true if and only if the program above terminates Solution {T}P{X0}

12

Auxiliary Variables
{X=x Y=y} R:=X; X:=Y; Y:= R {X=y Y=x} this says that if the execution of R:=X; X:=Y; Y:=R terminates (which it does) then the values of X and Y are exchanged Note that variables X and Y are called program variables since they appear in the program. The variables x and y, which dont occur in the command and are used to name the initial values of program variables X and Y. They are called auxiliary variables. also called ghost variables. Informal convention program variable are upper case auxiliary variable are lower case

13

More simple examples

{X=x Y=y} BEGIN X:=Y; Y:=X END {X=y Y=x} this says that BEGIN X:=Y; Y:=X END exchanges the values of X and Y this is not true {T} C {Q} this says that whenever C halts, Q holds {P} C {T} this specification is true for every condition P and every command C because T is always true In other words, there is no requirement on the final state. [P] C [T] this says that C terminates if initially P holds it say nothing about the final state [T] C [P] this says that C always terminates and ends in a state where P holds

14

A More Complicated Example

Let consider the following specification. We shall use C to stand for the program in the specification. {T} BEGIN R:=X; Q:=0; WHILE Y R DO BEGIN R:=R-Y; Q:=Q+1 END END {R < Y X = R + (Y Q)}

This program is to calculate the result of dividing X by Y, giving to Q, and the remainder R of the division. This is {T} C {R < Y X = R + (Y Q)} where C is the program above the specification is true if whenever the execution of C halts, then Q is quotient and R is the remainder resulting from dividing Y into X

15

Some Easy Exercises

When is [T] C [T] true? Write a partial correctness specification which is true if and only if the command C has the effect of multiplying the value of X and Y and storing the result in X Solution {X = x} C {X= x Y} Write a specification which is true if the execution of C always halts when execution is started in a state satisfying P

16

Specification can be Tricky

The program must set Y to be the maximum of X and Y [T] C [Y = max(X,Y)] A suitable program: IF X Y THEN Y := X ELSE SKIP Another? IF Y X THEN X := Y ELSE SKIP Or even? Y := X Later you will be able to prove that these programs are correct The postcondition Y=max(X,Y) says Y is the maximum of X and Y in the final state

17

Specification can be Tricky (ii)

The intended specification was probably not properly captured by ! { T } C { Y=max(X,Y) } The correct formalisation of what was intended is probably ! { X=x Y=y } C { Y=max(x,y) } The lesson it is easy to write the wrong specification! a proof system will not help since the incorrect programs could have been proved correct testing would have helped!

18

Sorting
Suppose Csort is a command that is intended to sort the first n elements of an array To specify this formally, let SORTED(A,n) mean A(1) A(2) A(n) A first attempt to specify that Csort sorts is {1 N} Csort {SORTED(A,N)} Not enough: SORTED(A,N) can be achieved by simply putting zero into the first n elements of A

19

Permutation Required
It is necessary to require that the sorted array is a rearrangement, or permutation, of the original array To formalise this, let PERM(A,A,N) mean that A(1),A(2),..,A(n) is a rearrangement of A(1),A(2),..,A(n) An improved specification of Csort sorts: {1 N A=a} Csort {SORTED(A,N) PERM(A, a, N)}

20

Still Not Correct The following specification is true {1 N} N:=1 {SORTED(A, N) PERM(A, a, N)} Must say explicitly that N is unchanged A better specification is thus: {1 N A=a N=n} Csort {SORTED(A, N) PERM(A, a, N) N=n} Is this the correct specification? what if N is larger than the size of the array?

21

Summary
We have given a notation for specifying the partial correctness of programs the total correctness of programs Specifications can still be incorrect however, their meaning is precise We next describe the predicate calculus: the precise language upon which they are based

22

Overview of Proof Rules for Program Correctness

The proof rules that follow constitute an axiomatic semantics of our programming language. They can be used to prove that programs meet partial correctness specifications.

23

Judgements
Three kinds of things that could be true or false have been introduced statement of mathematics, e.g. (X+1)2 = X2 + (2 X) +1 partial correctness specifications {P} C {Q} total correctness specifications [P] C [Q] These three kinds of things are examples of judgements a logical system provides rules for establishing the truth (i.e. proving) various kinds of judgements Floyd-Hoare logic provides rules for proving partial correctness specifications the laws of arithmetic, which are assumed known, provide ways of proving statements about integers ! S means statement S can be proved We have discussed the predicate calculus, first-order predicate logic, in particular its proof theory. This course covers axioms and rules for proving program correctness statements

24

Notation for Axioms and Rules

The axioms of Floyd-Hoare logic are specified by schemas these can be instantiated to get particular partial correctness specifications. The inference rules of Floyd-Hoare logic will be specified with a notation of the form ! S1 , . . ., ! Sn ! S this means the conclusion ! S may be deduced from the hypotheses ! S1 , . . ., ! Sn the hypotheses can be either all theorems of Floyd-Hoare logic or a mixture of theorems of Floyd-Hoare logic with theorems of predicate calculus Recall that given a set S of first-order formulae and F a formula, if S ! F means that F is a logical consequence (a theorem) of assumptions S.

25

Skip
Syntax: SKIP Semantics: the state is unchanged The Skip Axiom ! {P} SKIP {P}

It is a single axiom schema P can be instantiated with different values Instances of the skip axiom are: ! {Y = 2} SKIP {Y = 2} ! {T} SKIP {T} ! {R=X+(Y Q)} SKIP {R=X+(Y Q)}

26

Assignments
Syntax: V := E Semantics: the state is changed by assigning the value of the term E to the variable V Example: X :=X+1 this adds one to the value of the variable X

27

Preamble to the Assignment Axiom

The assignment axiom says that the value of a variable V after executing an assignment command V:=E equals to the value of the expression E in the state before executing it If a statement, called P(V), is to be true after the assignment Then the statement obtained by replacing V in P by E must be true before executing it. (eg. P(V)[E/V] is true in the state before executing V := E). Every statement about V in the postcondition must correspond to a statement about E in the precondition. in the initial state V has a value which is about to be lost

28

Substitution Notation
Define P[E/V] to mean the result of replacing all occurrences of V in P by E read P[E/V] as P with E for V for example, (X+1 > X)[Y+Z/X] = ((Y+Z)+1 > Y+Z)

29

The Assignment Axiom

The Assignment Axiom ! {P[E/V]} V:=E {P} Where V is any variable, E is any expression, P is any statement and the notation P[E/V] denotes the result of substituting the term E for all occurrences of the variable V in the statement P.

Instances of the assignment axiom are ! {Y = 2} X:=2 {Y = X} where P stands for Y = X , and P[2/X] is just Y = 2. ! {X+1 = n+1} X:=X+1 {X = n + 1} ! {E = E} X := E {X = E} (if X does not occur in E) if X occurs in E, the postcondition X = E may not hold even after the execution of X := E. for example, suppose E is X+1, clearly it is not true that { X+1 = X+1} X := X+1 { X = X+1 }.

30

V:=E

P(E)

P(V)

Where P(E) stands for a statement which contains E.

31

The Backwards Fallacy

Many people feel that the assignment axiom is backwards An erroneous intuition is that it should be ! { P } V:=E { P[E/V] } this has the false consequence ! {X=0} X:=1 {1=0} which follows by talking P to be X = 0, V to be X and E to be 1. The axiom above is wrong because the statement P represents any assertion (expression) that is needed to be true in the resultant state.

32

Validity
The fact that it is easy to have wrong intuitions about the assignment axiom shows that it is important to have rigorous means of establishing the validity of axioms and rules. We will not go into this topic here it is possible to give a formal semantics of our little programming language and then to prove that axioms and rules of inference of Floyd-Hoare logic are sound this will only increase our confidence in the axioms and rules to the extent that we believe the correctness of the formal semantics The simple assignment axiom about is not valid for real programming languages G. Ligler has shown that is can fail to hold in six different ways for the language Algol 60

33

Expressions with Side-effects

The validity of the assignment axiom depends on expressions not having side effects. Suppose that our language were extended so that if contained the block expression BEGIN Y :=1; 2 END this expression has value 2, but its evaluation also side effects the variable Y by storing 1 in it If the assignment axiom applied to block expressions, then it could be used to deduce ! {Y=0} X :=BEGIN Y:=1; 2 END {Y=0} which is wrong ???? since (Y=0)[E/X] = (Y=0) (because X does not occur in (Y=0)) this is clearly false; after the assignment Y will have the value 1 the problem is that the command X := BEGIN Y:=1; 2 END updates the values of two variables X and Y, but the assignment axiom deals with a single variable X.

34