1 / 19

The ideal of program correctness

The ideal of program correctness. Tony Hoare Budapest September 2006. Basic questions of Engineering. What does the product do? what is the specification? How does the product work? what are its components? what are their interfaces? how are they connected?.

candy
Télécharger la présentation

The ideal of program correctness

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. The ideal of program correctness Tony Hoare Budapest September 2006

  2. Basic questions of Engineering • What does the product do? • what is the specification? • How does the product work? • what are its components? • what are their interfaces? • how are they connected?

  3. Basic questions of Science • Why does it work? • what scientific theory does it rely on? • How do we know the answers are correct? • by experiment, • by calculation, • by proof • all checked by computer.

  4. A program verifier • automatically checks that a program conforms to its specification • serves as an essential tool for research into the science of programming. • proposed in 1969 • still a Grand Challenge for Computing research

  5. A Grand Challenge project • (eg. the Human Genome 1991-2004) • pursues scientific ideals • involves hundreds of scientists • with many specialist skills • for many years • delivers a measurable outcome • with prospects of widespread exploitation

  6. Program Correctness • is a scientific ideal • like accuracy of measurement in physics • purity of materials in chemistry • completeness of theory in logic • pursued for its own sake • beyond the needs of the present market • because one day.....

  7. A measurable outcome • One million lines of verified code • plus specifications, designs, assertions,... • machine-checked by a program verifier • at various levels of assurance • with hundreds of programs/modules • of various sizes: 100 to 100K lines • drawn from a wide range of applications • held in a public Repository.

  8. Levels of assurance • freedom from overflows, exceptions • soundness of internal interfaces • continuity of service (crash-proofing) • resistance to intrusion (security) • avoidance of damage (safety) • total functional correctness (the ideal)

  9. Applications drawn from • critical systems • embedded control • operating system kernels • web services • desktop applications • open source library classes • program generators • compilers ...

  10. Repository • conserves programs verified so far • and the tools that checked them • and the relevant journal record. • Also: challenge codes not yet verified • and specifications not yet coded • and tools that apply to them ... selected by the research community

  11. Tools • design environments • reverse engineering aids • test case generators • program analysers • verification condition generators • model checkers, decision procedures, • constraint satisfiers, proof engines ... ...all contributing to the program verifier

  12. Vision • software based on rational design • programmers make less mistakes • mistakes are detected immediately • software is delivered sooner • evolves more easily • resists attack from virus/worm/spam • and is cheaper to develop and use

  13. Cheaper “Based on [our] software developer and user surveys, the [US] national costs of an inadequate infrastructure for software testing is estimated to range from $22.2 to $59.5 billion. Over half these costs are borne by users...” The Economic Impact of Inadequate Infrastructure for Software Testing. Planning report 02-03, National Institute of Standards & Technology, May 2002.

  14. Many skills • Theory • to cover pointers, inheritance, concurrency,... • Tools • exploit the theory in analysers, checkers, VC generators, provers, decision procedures, ... • Experiments • apply the tools to verify the challenge codes and specifications • provide feedback for tool evolution

  15. Theory • Theories abound. • They must be unified and integrated • and developed for incorporation in tools • for application by other scientists • ...and later by software engineers

  16. Tools • Tools are exciting and prestigious. • They need maintenance • and customer support • They need adaptation for inter-working • and later for integration • allowing continued separate evolution ... to meet user needs

  17. Experiments • Experiments are hard work. • They apply other peoples’ prototype tools • to other peoples’ realistic programs • to reach scientifically valid conclusions • and gain experience for later advances (... that will make earlier work trivial)

  18. IFIP Working Conference • Verified Software: theories, tools, experiments. • Zurich: 10 -14 Oct. 2005 • Chairmen: Tony Hoare, Jay Misra, Natarajan Shankar • Sponsor: IFIP WG2.3 (programming methodology)

  19. A Program Verifier One can dream of routinely using a verifying compiler as an everyday tool. In the context of this idea our work has been extremely modest and must be considered as a small first step. We only hope that, indeed, this has been a first step of a progression which will allow this dream to come to fruition. A Program Verifier Thesis by James C. King Carnegie Institute of Technology September 1969

More Related