1 / 20

Chapter 25 Formal Methods

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

ronniehood
Download Presentation

Chapter 25 Formal Methods

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. Chapter 25Formal Methods 329-25

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related