CS 641 meeting -*- Outline -*-
* motivation for program verification section
** the correctness problem
def: (informally) a specification says what a program (procedure) does.
formally, a specifictation is a relation between states,
which may be presented as a pair of predicates (cf. Hoare).
def: software is correct if it meets is specification
verification is one way to ensure correctness
*** why
Q: Why should software be correct?
make a list of the reasons
**** software is important, money and lives depend on it
if you're selling software, bugs hurt sales
Q: name a company whose financial existence depends on software?
american airlines? united? at&t?
Q: name an application of software on which human lives depend?
air traffic control, medical implants,
**** safety may be jepordized by bugs
def: safety means that the design takes into account the limitations
of hardware and software, humans, prevents bad things
from happening
Q: can a system be incorrect and still safe?
Yes,
We won't be studying safety. But ...
Q: if a system designed for safety, should it be implemented correctly?
yes, it's difficult (impossible?) to make a design that
takes into account potential problems
in carrying out the design
**** pride in work, quality
**** intellectual challenge
*** why not?
Q: any reasons why you might choose not to worry about correctness?
when prototyping
when time to market is more important
when financial resources don't allow it???
Note: correctness of code to specs is only part of
the problem in software engineering,
perhaps not even the most difficult,
and already one of the best understood.
more important are how to design and specify
we study correctness because of our interests in:
understanding how to code (programming), safe coding practice
semantics
language design
specification languages
*** how
**** verification
def: verification is proving that a procedure meets its specification
connotation is formally, using a logic (as Hoare did)
but it could also be using any
convincing mathematically sound means (proof)
**** testing
similar to verification, in that requires a specification
(contrary to common practice!)
Q: how does verification differ from testing?
***** black box testing vs. clear box testing
black box doesn't look at program
clear box makes test using knowledge of program
***** testing vs. verification
Dijkstra remarked that "testing can only reveal the presence of bugs,
not their absence".
Q: did he mean black box or clear box testing? Why?
Q: Could there be a way that you could use testing in verification?
Yes, instead of formally proving something assertion,
you might be able to test it.
Hybrid test and verification
see Matthew Geller,
"Test Data as an Aid in Proving Program Correctness",
CACM, Volume 21, Number 5, (May 1978), Pages 368-375.
**** other ways?
Q: Are there other ways of assuring correctness?
** careful development (engineering) vs. guessing and intuition (craft)
If you compare software to other engineering disciplines
you'll see that in many ways software is more of a craft
each program hand made, no standard way to do things,
no handbooks of accepted solutions,
no standards for how to write programs
no mathematical basis used in programming
Want to be able to have standard techniques,
and some mathematical basis for programming
not just guessing and testing
this will also help (Cohen says) explain and teach
Ref: Cohen, Chapter 0.
Q: what did you think of Cohen's exercise 0.0 (cake problem)?
If not, explain it. If so, have them do more of the following.
Consider the following problem (compare Cohen's section 0.1)
Imagine a circular cake and a number of distinct points
on its circumference.
From each point draw another circle, smaller than the original,
but going over the center of the cake, such that
any internal intersection is of exactly 2 such circles (no more).
Q: Is this well-specifed?
I.e., is it possible to draw
the circles so that the number of pieces is not a function
of the number of points? Why?
Q: What's the number of pieces of the cake made by N points?
play with it then show the calculation
N = number of points, P(N) = number of pieces
P(0) = 1
P(1) = 2
P(2) = 5
P(3) = 10
Q: What is P(4)?
P(4) = 17
-------------------
increase in number of pieces
by adding a circular cut
=
number of pieces divided by circular cut
=
number of arcs of the circular cut
=
1 + number of internal intersection points
on the circular cut
-------------------
Let I(N) = number of internal intersection points on circular cut
from the Nth point
So...
-------------------
(0) P(N) = P(N-1) + (1 + I(N))
-------------------
Now to compute P(N)
------------------
P(N)
=
P(N-1) + 1 + I(N)
=
P(N-1) + 1 + 2(N-1)
------------------
Q: Can you solve this to get a non-recursive form for P(N)?
It's N^2 + 1.
Q: Can you prove that by induction?
use a calculation.
idea of the calculational format:
no big steps (no rabbits out of the hat, makes convincing)
reasons for each step (increases precision)
mainly want to use equality, but also can use inequalities
(or implication) if goes in only one direction.
Q: What's the role of playing (creativity, guessing) in solution?
What is the role of calculation?
Do you think that calculation can guide creativity.