1 / 14

Back Substitution: Strong and Weak Preconditions and Postconditions

This text explores the concept of back substitution in program development and how it is used to derive strong and weak preconditions and postconditions. It also discusses the limitations and problems associated with this approach.

walkerann
Download Presentation

Back Substitution: Strong and Weak Preconditions and Postconditions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Simple Example • {i < 10 & i >= 0} j := i * i {j < 100} • Can we ‘verify’ this triple? • Only if we know the semantics of assignment.

  2. The Assignment Rule • {P} x := f {Q} • where P and Q are the same, except that all the occurrences of x is P have been replaced by f. • {i+1 > 0} i := i + 1 {i > 0}

  3. Back To Our Simple Example • {i < 10 & i >= 0} j := i * i {j < 100} • Ignore P for now and start with Q. • Think backwards: • “If j < 100 after j becomes i squared, then i squared must have been less than 100.” • We have used the assignment rule backwards.

  4. Back Substitution • Back substitution is playing a “what if?” game by strict rules. • Dijkstra’s “weakest precondition” method of correct program development is based on deriving the minimal precondition that must be satisfied such that the execution of the code results in the postcondition being true.

  5. Back Substitution • “At first glance, it may seem a bit odd to be working backward through the program. The advantage of working this way is that our reasoning is goal directed: At each step, knowing what we wish to be true at the conclusion of some part of the program, we compute what needs to be true prior to that part. When we reach the start of the program, we have the weakest pre-condition ... We complete the proof by showing that the given pre-condition implies the weakest precondition” • B. Liskov and J. Guttag. Abstraction and specification in program development. MIT Press, 1987.

  6. Why Not Work Forward? • By starting at the precondition and working forward we compute the strongest postcondition. • To complete the proof we show that the strongest postcondition implies the desired postcondition. • Problem: A lot of unneeded information might get carried along as the strongest postcondition is derived. • How does symbolic execution address this issue?

  7. Simple Assignment Example {i < 10 & i >= 0}original P {i * i < 100} “weaker precondition” j := i * i {j < 100}original Q We need to show that {i < 10 & i >= 0} implies {i * i < 100}

  8. Stronger Preconditions Both {i < 10 & i >= 0} and {i <= 0 & i > -10} are stronger assertions than {i * i < 100}

  9. Another “Correct” Program {i < 10 & i >= 0} j := i * i; i := -100 {j < 100} Be careful what you ask for in your postconditions!

  10. A Stronger Postcondition {i < 10 & i >= 0} j := i * i; i := -100 {j < 100 & i = i’} Use the “prime” notation to indicate the value of a variable in the previous state.

  11. Discovering the Side Effect {i < 10 & i >= 0} j := i * i; {j < 100 & -100 = i’} i := -100 {j < 100 & i = i’}

  12. Discovering the Side Effect {i < 10 & i >= 0} {i * i < 100 & -100 = i’} j := i * i; {j < 100 & -100 = i’} i := -100 {j < 100 & i = i’}

  13. The Problem Revealed What do we do with {i < 10 & i >= 0} implies {i * i < 100 & -100 = i’}? drop the primes since there is no code left to consider attempt to prove that the antecedent implies the consequent

More Related