Chapter 25 Formal Methods

Formal methods Specify program using math Develop program using math Prove program matches specification using math –“prove program is correct”

Problems with Conventional Specification contradictions ambiguities vagueness imcompleteness mixed levels of abstraction

Formal Specifications Lots of approaches –State machines –Denotational semantics –Pre and post conditions –Z –Algebraic specifications –and many more

Denotational semantics Used to specify programming language Denotational semantics of a language is a function from programs to meanings. “Revised Report on the Algorithmic Language Scheme” Standards/R5RS/HTML/ Standards/R5RS/HTML/

Uses of Denotation Semantics Understanding a language Making sure a language is well-defined Proving things about language (type safe programs can never have a run-time error) Generating a compiler automatically

Pre and post conditions A program consists of some data types and operations on those data types. A running program has a state consisting of a set of variables with values. Operations change the state. Pre and post conditions specify how operations change state.

Example: Banking Types: –BankAccount. Has a balance, which is a number. –Transaction. Has a date, an amount, a type (deposit, withdrawal), and a BankAccount. Invariant: –For each BankAccount, balance = sum of deposits - sum of withdrawals

Example: Banking Operations –Deposit(amount, date, account) Precondition: amount is positive, account.balance = b, account.transactions=t Postcondition: account.balance=b+amount, account.transaction=t + (transaction with amount, date, “deposit”, and account)

Z(ed) Language based on math Logic, sets, sequences, relations, functions Z specification declares variables and predicates that are always true of the variables Some variables are used for input or for output

Z A little like a programming language Not used for assertions about a program, but to specify an entire system Can be extended to refer to a program There are tools to check syntax of Z specifications, to typeset them, and to test them

Formal Program Development Program transformations Hoare axiomatics –C.A.R. Hoare Weakest preconditions –Edsger Dijkstra

Program Transformation Start with a formal specification Make it executable Optimize the “program” by applying transformations to it –“For all x there is a y” is replaced by an algorithm that takes an x and produces a y –A lot like proving a theorem –A lot like an optimizing compiler

Hoare Axiomatics For each kind of statement, there is a rule that shows how a precondition leads to legal postconditions {P} if (e) then S1 else S2 {P  e} S1 {R} {P  ¬ e} S2 {T} {P} if (e) then S1 else S2 {R  T}

Hard part Loops Procedures Pointers Concurrency

Weakest Precondition Like Hoare Axiomatics, but backwards Start with result and work forward. Let’s you derive a program, not just make sure it meets the spec. Both techniques need a language like Z for writing assertions

Advantages of Formal Methods Decreases errors Precise - more likely to agree on meaning of a specification Automatable - easier to make tools to process specification –Error checking –Code generation

Disadvantages of Formal Methods Most programmers don’t know math well enough Most customers can’t read the specification Can lead to false expectations - formal development does not eliminate all errors –Bad specifications –Mistakes in proofs/bugs in tools

Disadvantages of formal methods Some things hard to specify –GUIs –Sound/graphics –Concurrency Can take a long time and be expensive

When to use formal methods When it is very important to get it right –Security –Space shuttle –Pace makers When you have the right people Big payoff often comes from small part of the system