Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Mathematic Induction and Program Correctness: Testing vs Proof, Assignments of Software Engineering

An overview of mathematic induction and its application to program correctness. Two approaches to ensuring program correctness: testing and proof. Testing is compared to csc370, where outputs are compared to expected results, but it requires much manual effort and cannot show that a program is error-free. Proof, on the other hand, is a rigorous, mathematical analysis of the algorithm, which is important for critical programs like medical diagnostic and flight avionics. The document also includes an example of euclid's algorithm and a proof of its termination.

Typology: Assignments

Pre 2010

Uploaded on 07/23/2009

koofers-user-zlg
koofers-user-zlg 🇺🇸

4.5

(2)

10 documents

1 / 3

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
12 September, Day 5
Handout – mathematic induction
Written Assignment #1 due (on Chemnitz/Student Data)
Return/Review Systems Assignment #0 (great ideas – Post)
“professional programming practice”
Written Assignment #2 (chapter 10) assigned – due in one week, Day 7
System Assignment #1 (first presentation) topic due next time
Chapter 10
Program Correctness
Two Approaches
1. Testing
recall issues of testing from CSC370
{Test Data Set} (input) -> [Program] -> Verify Output
Outputs are compared to expected (ie True results)
hard: must determine expected outputs beforehand
(manually)
hard: what’s a “good” test data set to use?
Problem:
much manual effort required – must know expected results
a. most real world programs are too large to fully test
ex: an air traffic control system
how many possible configurations of planes?!
b. testing can only show that errors exist – it can not show that
there
are NO errors
purpose of testing is to find and identify errors
a good test finds an error
testing can not show that a program is correct
2. Proof
work of CAR Hoare (1960s)
“proofs” are inductive after assertions are made on program
structure
model: - make assertions
- prove (inductively) program structure is correct
Important as some programs are critical (ex: medical diagnostic,
flight
avionics, etc) – impossible to test completely
proof is a rigorous, mathematical analysis of the algorithm (code)
Read, beginning on page 63
CSC 490 Course Notes and Outline, © Dr. Gary Locklair, Fall 2006
pf3

Partial preview of the text

Download Mathematic Induction and Program Correctness: Testing vs Proof and more Assignments Software Engineering in PDF only on Docsity!

12 September , Day 5 Handout – mathematic induction Written Assignment #1 due (on Chemnitz/Student Data) Return/Review Systems Assignment #0 (great ideas – Post) “professional programming practice” Written Assignment #2 (chapter 10) assigned – due in one week, Day 7 System Assignment #1 (first presentation) topic due next time Chapter 10 Program Correctness Two Approaches

  1. Testing recall issues of testing from CSC {Test Data Set} (input) -> [Program] -> Verify Output Outputs are compared to expected (ie True results) hard: must determine expected outputs beforehand (manually) hard: what’s a “good” test data set to use? Problem: much manual effort required – must know expected results a. most real world programs are too large to fully test ex: an air traffic control system how many possible configurations of planes?! b. testing can only show that errors exist – it can not show that there are NO errors purpose of testing is to find and identify errors a good test finds an error testing can not show that a program is correct
  2. Proof work of CAR Hoare (1960s) “proofs” are inductive after assertions are made on program structure model: - make assertions - prove (inductively) program structure is correct Important as some programs are critical (ex: medical diagnostic, flight avionics, etc) – impossible to test completely proof is a rigorous, mathematical analysis of the algorithm (code) Read, beginning on page 63

Note: debugging is different from testing Note: if proof is correct, we have confidence in program if proof fails, then it may be due to a logic error (bug) in the program and the proof helps us to find that error {test: it’s not just that proof fails, therefore, we have to debug entire program to find out what’s wrong – where proof fails points to error in program} Again, Dewdney “suddenly” does something on page 64. The 15, 9, and 3 bar are obvious. But what happens when he gets to 16 and 22 bar? Notice that we suddenly have something “left over” and this is repeated. Well, this is Euclid’s algorithm. Don’t get hung up here … keep reading. (As we mentioned before, good to read chapter straight through first, and then re-read) Follow algorithm on page 65 for 16, 22 while M=16 > 0 (M=16, N=22) L = N mod M = 22 mod 16 = 6 N = M = 16 M = L = 6 while M=6 > 0 (M=6, N=16) L = N mod M = 16 mod 6 = 4 N = M = 6 M = L = 4 while M=4 > 0 (M=4, N=6) L = N mod M = 6 mod 4 = 2 N = M = 4 M = L = 2 while M=2 > 0 (M=2, N=4) L = N mod M = 4 mod 2 = 0 N = M = 2 M = L = 0 while M=0 > 0 false N =2, the gcd Now, you “desk check” (follow) the algorithm for M=10 and N=35. What is GCD? What is N? (5) Interesting: relationship between graphical ruler on page 64 and modulo on page 65 Now, follow proof … beginning on bottom of page 66: