Chapter 25 Formal Methods 329 25 1 Formal

  • Slides: 20
Download presentation
Chapter 25 Formal Methods 329 -25 1

Chapter 25 Formal Methods 329 -25 1

Formal methods • Specify program using math • Develop program using math • Prove

Formal methods • Specify program using math • Develop program using math • Prove program matches specification using math – “prove program is correct” 329 -25 2

Problems with Conventional Specification • contradictions • ambiguities • vagueness • imcompleteness • mixed

Problems with Conventional Specification • contradictions • ambiguities • vagueness • imcompleteness • mixed levels of abstraction 329 -25 3

Formal Specifications • Lots of approaches – State machines – Denotational semantics – Pre

Formal Specifications • Lots of approaches – State machines – Denotational semantics – Pre and post conditions –Z – Algebraic specifications – and many more 329 -25 4

Denotational semantics • Used to specify programming language • Denotational semantics of a language

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/R 5 RS/HTML/ 329 -25 5

Uses of Denotation Semantics • Understanding a language • Making sure a language is

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 329 -25 6

Pre and post conditions • A program consists of some data types and operations

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

Example: Banking • Types: – Bank. Account. Has a balance, which is a number.

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

Example: Banking • Operations – Deposit(amount, date, account) • Precondition: amount is positive, account.

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) 329 -25 9

Z(ed) • Language based on math • Logic, sets, sequences, relations, functions • Z

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 329 -25 10

Z • A little like a programming language • Not used for assertions about

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/ 329 -25 11

Formal Program Development • Program transformations • Hoare axiomatics – C. A. R. Hoare

Formal Program Development • Program transformations • Hoare axiomatics – C. A. R. Hoare • Weakest preconditions – Edsger Dijkstra 329 -25 12

Program Transformation • Start with a formal specification • Make it executable • Optimize

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 329 -25 13

Hoare Axiomatics • For each kind of statement, there is a rule that shows

Hoare Axiomatics • For each kind of statement, there is a rule that shows how a precondition leads to legal postconditions • {P} if (e) then S 1 else S 2 • {P e} S 1 {R} • {P ¬ e} S 2 {T} • {P} if (e) then S 1 else S 2 {R T} 329 -25 14

Hard part • • Loops Procedures Pointers Concurrency 329 -25 15

Hard part • • Loops Procedures Pointers Concurrency 329 -25 15

Weakest Precondition • Like Hoare Axiomatics, but backwards • Start with result and work

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 329 -25 16

Advantages of Formal Methods • Decreases errors • Precise - more likely to agree

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 329 -25 17

Disadvantages of Formal Methods • Most programmers don’t know math well enough • Most

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 329 -25 18

Disadvantages of formal methods • Some things hard to specify – GUIs – Sound/graphics

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

When to use formal methods • When it is very important to get it

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 329 -25 20