Chapter 25 Formal Methods

1
Chapter 25Formal Methods
2
Formal methods

• Specify program using math
• Develop program using math
• Prove program matches specification using math
• prove program is correct

3
Problems with Conventional Specification

• contradictions
• ambiguities
• vagueness
• imcompleteness
• mixed levels of abstraction

4
Formal Specifications

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

5
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 http//www.schemers.org/Documents/
  Standards/R5RS/HTML/

6
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

7
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.

8
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

9
Example Banking

• Operations
• Deposit(amount, date, account)
• Precondition amount is positive, account.balance
  b, account.transactionst
• Postcondition account.balancebamount,
  account.transactiont (transaction with amount,
  date, deposit, and account)

10
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

11
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
• http//www.afm.sbu.ac.uk/z/
• http//softeng.comlab.ox.ac.uk/usingz/

12
Formal Program Development

• Program transformations
• Hoare axiomatics
• C.A.R. Hoare
• Weakest preconditions
• Edsger Dijkstra

13
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

14
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

15
Hard part

• Loops
• Procedures
• Pointers
• Concurrency

16
Weakest Precondition

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

17
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

18
Disadvantages of Formal Methods

• Most programmers dont know math well enough
• Most customers cant read the specification
• Can lead to false expectations - formal
  development does not eliminate all errors
• Bad specifications
• Mistakes in proofs/bugs in tools

19
Disadvantages of formal methods

• Some things hard to specify
• GUIs
• Sound/graphics
• Concurrency
• Can take a long time and be expensive

20
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