09-progver

09-progver - Program verification Readings: Chapter 4. In...

Info iconThis preview shows pages 1–6. Sign up to view the full content.

View Full Document Right Arrow Icon
Program verification Readings: Chapter 4. In this module, we define and work with a formal proof system for proving programs correct. The motivation is similar to that of previous modules: a proof can provide confidence of correctness in a situation where exhaustive semantic checking is time-consuming or impossible. 1
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Testing versus verification Current practice is to gather evidence for program correctness by testing – both black-box testing (in which tests are designed independent of the code) and white-box testing (in which tests are designed based on the code). This is analogous to checking that a propositional formula is a theorem by trying a few valuations, or to checking that a predicate formula is a theorem by constructing a few models and interpretations. Exhaustive testing is difficult even for small programs, and impossible in the case where a program can consume an unbounded amount of data. 2
Background image of page 2
The process of formal verification starts with the formal description of a specification for a program in some symbolic logic, following that with a proof (in some proof system) that the program meets the formal specification. If the proof system is sound, then this implies that the program meets its specification for all inputs. The question of whether the formal specification conforms to the informal notion of what the program should do is not a technical question, but a social and organizational matter, and properly the subject of a course in software development or engineering. 3
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Formal specification and verification can help reduce or eliminate bugs, aid in code development, maintenance and extension, and facilitate interoperability and code reuse. While formal specification is widespread in industry, formal verification is most often applied in safety-critical situations (airplanes, cars, medical equipment, nuclear power plants). Researchers continue to try to develop systems to automate verification, and to develop programming methodologies in which proofs of correctness are produced along with programs. 4
Background image of page 4
We will describe a proof system for programs written in a simple language that contains the core features of languages such as C/C++, Java, and Pascal, though it may differ slightly in syntax from these. The program syntax is part of the proof system. This approach was first described by Tony Hoare in 1969, and has been elaborated upon and extended since then. In contrast, the techniques of chapters 3 and 5 (which we will not discuss here) assume a fixed program or set of programs, and reason about the behaviour of the system. Both approaches are valuable, but this one is more commonly used in informal reasoning about programs (e.g. when learning about algorithms).
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 6
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 63

09-progver - Program verification Readings: Chapter 4. In...

This preview shows document pages 1 - 6. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online