I our sytax, a Assume statemet will be used to record what must be true at the begiig of the program i order for it to work correctly. Similarly, a Cofirm statemet is used to record what should be true after the code is executed. Assume y ¹ 0; z : = w/y; if z ³ 0 the abs := z else abs := -z edif; Cofirm abs = w/y ; This program computes a real quotiet, so we must be sure that the divisor y is ozero. The Assume clause accomplishes this. The Cofirm statemet claims that, upo executio of the code, the value of the variable abs will be the absolute value of the quotiet w/y. We ca see that the Assume ad Cofirm clauses together serve to specify what the program does, by first screeig out usatisfactory iput ad fially by statig what will be true after program executio. I additio to providig formal specificatios, these assertios permit verificatio by formig a basis for developig appropriate proof rules. I the absolute value program, the costructs used are the If the else ad the assigmet statemets, ad so we eed proof rules for these costructs ad a explaatio of what they mea. The form of typical proof rules is illustrated by the rule for if the else statemets: code: Assume B; code1; Cofirm Q; code; Assume B; code2; Cofirm Q; --------------------------------------------------------------------------- code; If B the code1 else code2; edif; Cofirm Q; The meaig of this rule (ad of all future rules) is that the correctess of the bottom lie ca be deduced from the correctess of the top lies. The code at the 1
begiig of each of the above lies is a sequece of statemets, the first of which is usually a Assume statemet. Similarly, code1 ad code2 also represet sequeces of statemets. To illustrate this rule we apply it to the absolute value example, but first we eed a basic uderstadig of the overall proof process. I geeral, we will have a proof rule to cover each differet kid of statemet i our programmig laguage, ad our proof costructio process will ivolve the creatio of a successio of lemmas. This process begis with the statemet immediately precedig the fial Cofirm statemet ad progresses backward through the code, applyig the appropriate rule at each poit. More will be said about this order of rule applicatio later. I our example, the code precedig the If the else statemet cosists of a Assume statemet ad a assigmet. Applyig the If the else rule backwards yields two assertive programs which must the be proved correct: (1) Assume y ¹ 0; z : = w/y; Assume z ³ 0 ; abs := z; Cofirm abs = w/y ; (2) Assume y ¹ 0; z : = w/y; Assume ( z ³ 0) ; abs := -z; Cofirm abs = w/y ; We ote that whe we applied this rule, the If the else costruct itself disappeared, havig bee replaced by two hypotheses, each cotaiig fewer programmig costructs tha the origial program. Sice both these hypotheses cotai assigmet statemets, we look ext at the proof rule for assigmets: 2
x ; ------------------------------------------------ code; x := exp; Cofirm Q; code; Cofirm Q[ exp] As usual, the meaig of the rule is that i order to prove the bottom lie, it is sufficiet to prove the top lie. The symbol ca be read as replaced by. This rule says that we omit the assigmet statemet ad rewrite the Cofirm clause Q replacig all the istaces of x by the expressio exp, which was to have bee assiged to x. Applyig this rule to our absolute value proof, we get: (1) Assume y ¹ 0; z := w/y; Assume z ³ 0; Cofirm z = w/y ; (2) Assume y ¹ 0; z := w/y; z ³ 0 ; Assume ( ) Cofirm z = w/y ; We ow eed a rule for Assume statemets: code; Cofirm P Þ Q; ------------------------------------ code; Assume P; Cofirm Q; Applyig the rule for Assume, we obtai: (1) Assume y ¹ 0 ; z := w/y; Cofirm z ³ 0 Þ z = w/y ; (2) Assume y ¹ 0; z := w/y; Cofirm z < 0 Þ -z = w/y ; Now we apply the assigmet rule to each brach: (1) Assume y ¹ 0; Cofirm w/y ³ 0 Þ w/y = w/y ; (2) Assume y ¹ 0 ; Cofirm w/y < 0 Þ - w/y = w/y ; 3
Aother applicatio of the Assume rule yields: w/y ³ 0 Þ w/y = w/y ; (1) Cofirm y ¹ 0 Þ ( ) (2) Cofirm y ¹ 0 Þ ( w/y 0Þ w/y = - w/y ) < ; To complete the proof we eed a rule for Cofirm: Q -------------- Cofirm Q; Applyig the Cofirm rule produces the followig mathematical propositios: w/y ³ 0 Þ w/y = w/y (1) y ¹ 0 Þ ( ) (2) y ¹ 0 Þ ( w/y < 0Þ - w/y = w/y ) As the example illustrates, every reverse rule applicatio produces oe or more ew hypotheses, each of which has fewer programmig costructs tha the coclusio lie. Ultimately, all the programmig laguage sytax disappears, leavig hypothesis writte strictly i the laguage of the uderlyig mathematical theory. I this case that theory happes to be real umber theory, which allows us to coclude that both of these assertios are true from the defiitio of absolute value. The part of the proof ivolvig oly the mathematical theory may strike the reader as particularly easy, ad oe may fear that oly such obviously cotrived examples as this will be so simple to verify. However, throughout this thesis, example after example will show that this pheomeo is ot peculiar to this simple program, but rather is a commo occurrece. I fact, we have ot yet foud ay example i which the proof of program correctess requiresd more tha simple use of mathematical defiitios ad straightforward applicatios of the appropriate theory. This is really o surprise if oe stops to cosider that, i order to write the correct code, the programmer must kow at a ituitive level whatever theorems uderlie the reasoig he is usig for program developmet. 4
I the verificatio literature, associated with every loop is a clause called the loop ivariat. As the ame suggests, the loop ivariat is a assertio, which is true both before ad after each iteratio of the loop. The sytactic marker for the loop ivariat is the keyword Maitaiig. A simple example illustratig the while loop costruct is: Assume ³ 0; sum := 0; i := 0; Maitaiig i while i < do i := i + 1; sum := sum +1; ed; Cofirm sum = Ù sum = å j å j i Here the ivariat states that i ever exceeds ad that at the begiig or ed of ay iteratio, the variable sum cotais the total of the first i itegers. This exactly describes what the loop is doig, amely computig a sequece of partial sums util it fially has the sum of the first itegers. For coveiece i what follows, we will ame this particular loop ivariat Sum_Iv. That is, Sum_Iv = i Ù sum = i å j. I order to verify this program, we will eed the proof rule for while statemets: code; Cofirm Iv; Assume Iv Ù B; body; Cofirm Iv; Assume Iv Ù B; Cofirm Q; ---------------------------------------------------------- code; Maitaiig Iv while B do body ed; Cofirm Q: Here the first hypothesis is that the ivariat Iv be true before the loop is executed. The secod hypothesis requires that if Iv is true ad the coditioal B for the 5
loop is true ad the body is executed, the Iv is true after executio, i.e., that Iv truly is a ivariat. The third says that the truth of Q should follow from the truth of Iv ad B, sice they will both hold true whe the loop termiates. We will ow use this rule i establishig the correctess of the summatio program. As before, we will take for grated that the variables have bee declared. Sice the while loop is the last costruct of this program, we apply that rule first, obtaiig three hypotheses: (1) Assume ³ 0; sum := 0; i := 0; Cofirm Sum_Iv; (2) Assume Sum_Iv Ù i < ; i := i + 1; sum := sum + i; Cofirm Sum_Iv; (3) Assume Sum_Iv Ù i ³ ; Cofirm sum = å j; To prove correctess of the program, we must apply the appropriate proof rules to each of these hypotheses. For the first, applyig the assigmet rule to i := 0 yields: (1) Assume ³ 0; sum := 0; Cofirm 0 Ù sum = 0 å j ; Applyig the assigmet rule to sum := 0 leads to: Assume ³ 0; Cofirm 0 Ù 0 = 0 å j; Fially, usig the rule for Assume, followed by the Cofirm rule, we obtai: ³ 0 Þ 0 Ù 0 = å j; This follows from the defiitio of å. I hypothesis (2), the body of the loop cosists of two assigmets, so we apply the assigmet rule twice to obtai: (2) Assume i < Ù Sum_Iv; Cofirm i + 1 Ù sum + i + 1 = i + 1 å j; j= 1 Applyig the Assume ad Cofirm rules, we get 6
i < Ù i Ù sum = i å j Þ j= 1 i + 1 Ù sum + i + 1 = i + 1 å j j= 1 This ca be see to be correct by addig i + 1 to both sides of the equatio for sum i the hypothesis. Hypothesis (3) expads out to: (3) Assume i Ù sum = å j Cofirm sum = å j; i Ù i ³ ; Applyig the rules for Assume ad Cofirm, we obtai: From i Ù sum = sum = å j i å j Ù i ³ Þ i ad i ³, it follows that i =, ad we have the desired result. To write the loop ivariat, the programmer eeded to kow that the loop will have the total of the first i itegers i sum after i iteratios ad that the highest value i will achieve is. But, of course, had the programmer ot kow both of those facts implicity, he would ot have bee able to write this program. The poit here is that loop ivariats are ot mysterious, or do they requires deep mathematical isights, which most programmers are ulikely to have. Loop ivariats are simply descriptios of what the loop does. Just as a compiler must keep iformatio about procedures so that it ca do type checkig of parameters ad ca fid appropriate code ito which to trasfer cotrol, the verifier must kow certai iformatio about procedures i order to be able to geerate correctess proofs. 7
Whe a procedure call is made i a program, the verifier does ot eed to see the code for that procedure at all, but rather it must kow what the code does, i.e. what its specificatios are. So wheever a procedure is declared, the headig, which cotais its specificatios, is recorded i what we will call the program s cotext. To illustrate how procedures look, what the headig is, ad where the specificatios appear, we will preset a example of a program fragmet i which the umber of permutatios of objects take r at a time is computed. To facilitate the computatio, a procedure for calculatig factorials is used. The declaratio of the factorial procedure is show first: Proc Fid_Factorial (cost : iteger, var fact: iteger) requires ³ 0; esures fact =!; fact := 1; i := 0; Maitaiig fact = i! Ù i while i < do i := i + 1; fact := i * fact ed ed; The requires clause is a programmer supplied assertio which tells what restrictios must be met i order that, if the code is correct, the esures clause will hold upo completio of the procedure body. Together, the requires ad esures clauses form the specificatios of the procedure. The headig of the procedure cosists of the first lie ad the specificatios: Proc Fid_Factorial (cost : iteger, var fact: iteger); requires ³ 0; esures fact =!; 8
For ay give block of code, the verifier will first look at the declaratios ad put appropriate iformatio ito the cotext, i.e., save iformatio which will be eeded i order to apply the proof rules. The the verifier begis at the peultimate statemet ad proceeds toward the begiig of the program (usually a Assume statemet), applyig the appropriate rule as we have see i the proceedig examples. So, i this example, the verifier will have to put the headig of Fid_Factorial ito the correct cotext before applyig the other rules ecessary for provig correctess. Hece, if ad whe Fid_Fact is called, the specificatios tellig what Fid_Factorial does will be available. It is clear that we eed two ew proof rules, oe to hadle procedure declaratios ad oe for procedure calls. The followig is a simplified versio of the procedure declaratio rule: C È {p_headig} \ Assume pre; Remember x; body; Cofirm post; C È {p_headig} \ code; Cofirm Q; ---------------------------------------------------------------------- C \ Proc p(var x: T); requires pre; esures post; body; ed code; Cofirm Q; Both hypotheses of the declaratio rule idicate that the headig of the procedure beig declared (but ot its body) is to be placed i the cotext. This makes all the ecessary iformatio about the procedure available so that it ca be called from ay part of the program, icludig from withi itself. The first hypothesis of the rule establishes that the procedure works as specified by requirig that, if the requires clause is met, the the esures clause is true upo completio of the body of the procedure. The requires clause pre is called the precoditio of the procedure ad the esures clause post is called the postcoditio. I applyig the procedure declaratio rule to Fid_Factorial, we ote that the first hypothesis to cosider will be: 9
C È {Fid_Fact_Headig} \ Assume ³ 0; Fid_Fact_Body; Cofirm fact =!; Here C stads for whatever cotext already exists at the poit of declaratio of Fid_Factorial, ad as the rule shows, the Fid_Fact_Headig is added to that cotext by the verifier. The \ mark separates the cotext from the assertive program to be proved correct. Fid_Fact_Body is a abbreviatio to stad for the code i the body of the Fid_Factorial procedure. We ote that this hypothesis is i a already familiar form because it looks just like the precedig examples. Ideed, i order to establish the stated hypothesis, we proceed exactly as we did i the examples already give, ad we will fid that the rules we eed are oes we have see before. Sice the body of Fid_Factorial eds with a while loop, it is the while rule that we apply first, thereby geeratig three hypotheses to check: (1) Assume ³ 0; fact := 1; i := 0; Cofirm fact = i! Ù i ; (2) Assume fact = i! Ù i Ù i < ; i := i + 1; fact := i * fact; Cofirm fact = i! Ù i ; (3) Assume fact = i! Ù i Ù i ³ ; Cofirm fact =!; For (1) we apply the assigmet rule twice, obtaiig: (1) Assume ³ 0; Cofirm 1 = 0! Ù 0 ; Applyig the rules for Assume ad Cofirm, we get: ³ 0 Þ1= 0! Ù 0 ; The fact that 1 = 0! is a defiitio from umber theory. Hypothesis (2) also requires two applicatios of the assigmet rule ad use of the rules for Assume ad Cofirm. The result is: 10
fact = i! Ù i Ù i < Þ (i + 1) * fact = (i + 1)! Ù i + 1 The first part of the coclusio ca be prove by multiplyig both sides of the equatio fact = i! by i + 1. The other part of the coclusio is obvious sice i <. For hypothesis (3) we eed to verify: (3) Assume fact = i! Ù i Ù i ³ ; Cofirm fact =!; Applyig the assume ad cofirm rules yields: fact = i! Ù i Ù i ³ Þ fact =!; Sice i ad i ³, i =. Hece fact = i! implies that fact =!. We have see that a applicatio of the proof rule for procedure declaratios causes the cotext to be eriched with the procedure headig. Such a applicatio also establishes that if the parameters to the procedure meet the requires clause, the upo completio of the procedure body, the esures clause is met. I case the post coditio refers to old values of oe of the parameters, we eed the Remember rule: C \ code; Cofirm RP[@s s, @t t]; C \ code; Remember s, t; Cofirm RP/_ s, @s, t, @t, u, v, _\; Next we will see how procedure calls work by examiig a call to Fid_Factorial. The followig program fragmet computes the umber of permutatios of objects take r at a time: C \ Assume ³ r ³ 0; Fid_Factorial(, fact); d := r; 11
Fid_Factorial(d, dfact); Perm := fact/dfact; Cofirm Perm = P ; r To show correctess of this program fragmet, we will eed to apply the assigmet rule first, followed by two applicatios of the call rule with a assigmet betwee the two calls. The followig is a simple versio of the proof rule for procedure calls: C \ code; Cofirm pre[x a] C \ code; Cofirm "?a: T, post[@x a, x?a] Þ Q[a?a] ---------------------------------------------------------------------- C \ code; p(a); Cofirm Q Sice the declaratio rule establishes that if the requires clause is satisfied, the the esures clause is met upo completio of the procedure body, the first hypothesis of the call rule checks that the requiresclause pre holds whe the actual parameter a is substituted for the formal parameter x. The secod hypothesis asks that the esures clause post imply Q. The @ sig i frot of the variable x refers to the value of x at the begiig of the procedure. This distiguishes the old value of x from the curret value. The extra complicatio here is the itroductio of a ew variable?a to stad for the value of the actual parameter a after the procedure p has modified it. The call rule is simpler to uderstad i the versio preseted above, but i ormal usage we do t wat to break out two separate hypotheses whe a sigle, slightly legthier oe will do. So we ordiarily combie this rule i a sigle hypothesis rule: C \ code; Cofirm pre[x a] Ù "?a: T, post[@x a, x?a] Þ Q[a?a] ----------------------------------------------------------------------- C\ code; p(a); Cofirm Q 12
With this rule available to us, we are ready to establish correctess of our program fragmet. Sice the last executable statemet i our fragmet is a assigmet, we apply the assigmet rule first, obtaiig: C \ Assume ³ r ³ 0 ; Fid_Factorial(, fact); d := r; Fid_Factorial(d, dfact); Cofirm fact/dfact = P ; r Next we eed the call rule; C \ Assume ³ r ³ 0 ; Fid_Factorial(, fact); d := r; Cofirm d ³ 0 Ù "?dfact : iteger,?dfact! fact/?dfact = P ; r Applyig the assigmet rule results i: C \ Assume ³ r ³ 0 ; Fid_Factorial(, fact); Cofirm - r ³ 0 Ù "?dfact fact/?dfact = P ; r Þ : iteger,?dfact Aother applicatio of the call rule yields: C \ Assume ³ r ³ 0 ; Cofirm ³ 0 Ù "?fact,?fact =! Þ - r ³ 0 Ù "?dfact : iteger,?dfact = ( - r)! Þ?fact/?dfact = P ; r = ( - r)! Þ Upo applyig the rules for Assume ad Cofirm, we get a implicatio: ³ r ³ 0 Þ ³ 0 Ù "?fact,?fact =! Þ ( - r ³ 0 Ù "?dfact : iteger,?dfact = ( - r)! Þ?fact/?dfact = P ; r 13
Sice ³ r ³ 0, ³ 0. Sice?fact =! ad?dfact = ( r)!, by a defiitio i combiatorics,?fact/?dfact = is correct. P, sice r P =!/( r)! Hece our program fragmet r The two examples we have just preseted performed calculatios o itegers i a programmig style, which is typical for maipulatig small objects, i.e., a costat parameter was passed to a procedure which performed some calculatios ad the assiged the resultig value to a variable parameter. This is typical ad reasoable because small objects take up little space, ad psychologically it seems reasoable to have a ew variable to represet the result of the operatio while the origial variable retais its value. I the case of Fid_Factorial, the costat parameter remaied fixed while the variable parameter fact had a ew value after the computatio was completed. Our simplified procedure declaratio rule was sufficiet for provig the correctess of procedures writte i this style. However, this programmig style is ot desirable whe programmig with large objects, or eve small oes i some cases. For example, i sortig the elemets of a array, a programmer would ot wat to create a ew array each time a permutatio of the give elemets is made. I order to cosume both time ad space, it is preferable to modify the existig array. This meas that there must be a way to specify what modificatio has bee made, ad this requires us to referece values of variables both before ad after the chage takes place. To accommodate this eed we have itroduced the use of the symbol @ to be placed i frot of a variable var_ame to idicate that its value at a give poit i the program must be remembered as @var_ame. 14
To illustrate the use of this idea, cosider a trivial procedure which icremets a give iteger by a costat value. Here, eve though it may ot require a lot of space to create a ew iteger to hold the icremeted value, psychologically we expect the give variable to have its old value destroyed ad replaced by its icremeted value. This procedure might be part of a iteger package: Procedure Icremet(var : iteger, cost c: iteger); requires mi_it + c max_it; esures = @ + c; := + c; ed; The requires clause makes sure that the result is withi the bouds permitted for itegers. The esures clause states that the ew value of will be the old value of icremeted by c. Verificatio of procedures whose clauses refer to old values requires us to supplemet our declaratio rule as follows: C È {p_headig} \ Remember; Assume pre; body; Cofirm post; code; Cofirm Q; ------------------------------------------------------------------ C \ Proc p(var x, cost y); requires pre; esures post; code; Cofirm Q; The ew keyword, which appears here idicates that values of all variables are to be saved as of this poit i the program. The proof rule for Remember is: C \ code; Cofirm Shift(Q); -------------------------------------------------- C \ code; Remember; Cofirm Q; where Shift(Q) is defied by: Shift(x) = x Shift(c) = c for ay costat c Shift(@x) = x Shift(f(e1,e2)) = f(shift(e1), Shift(e2)) The Shift fuctio removes oe-poud sig from ay give variable if oe is there. 15
At this poit, we ca ow make some geeral observatios about how our proof system works. Although the programmer must supply certai clauses specifyig program behavior, the geeratio of itermediate assertios is mechaical. A automated verifier ca determie sytactically what rule to apply at each step of the proof. Moreover, whe all the pertiet rules have bee applied, the statemet which remai are oes ivolvig oly the mathematical theory for the give program, ad the proof reasoig ca the be completed usig oly traditioal mathematical reasoig. A automatic verifier will perform three major tasks: (1) geeratio of assertios by applyig the rules, (2) simplificatio of these assertios, probably as the verifier proceeds through the code, rather tha all at oce, ad (3) applicatio of axioms ad theorems of the uderlyig mathematical theories i a attempt to prove the fial assertio. 16