Learning Objectives

(See p. 79) Be able to:

• Describe three possible sources of errors when we are using software.
• Describe and apply the six-step strategy for debugging

Notes

Understanding Computer Errors

(p. 156) Computers do what we say, not what we mean.

(p 157–160) Pay attention to feedback from the system

• [“Situational awareness”]

Possible sources of errors that occur when we use software (developed by competent programmers):

1. Wrong data input
2. Wrong command input
3. “Broken system” i.e., error in the software

Of these, #1 and 2 are our responsibility and the most common.

Six-Step Strategy for Debugging

(p. 160)

1. Try to reproduce the error.
2. Be sure you know exactly what the problem is.
3. Eliminate obvious causes.
4. Divide parts that work from parts that do not.
5. If you reach a dead end, reassess your assumptions and inferences; back up.
6. Make predictions; test them.

Not guaranteed to work, but a useful framework.

Applications of the Strategy

(pp. 164–175) Debugging a web page:

• Reproduce
• What are the problems? Focus on one of them.
• Check obvious errors.
• Dividing the problem
  • [But instead of deleting each element, we can delete halves (binary search).]

What steps didn’t seem to fit in the framework?

• Use the Error Console
  • [(now the Browser Console in Firefox).]
• Take advantage of syntax coloring in the browser’s page source view or in any good text editor.
• [Generalization: use software tools that will help you to find bugs.]
• “We didn’t try the Validator, but it wouldn’t have been much help….” (p. 175) [— But there’s also a CSS validator.]

(pp. 175–178) Debugging a printing problem; discovering the print queue.

Software Reliability

It is hard to make software completely correct. It is impossible to make complex software correct. Much of the software we use today is incredibly complex.

[Why is it complex? Remember in Principles of Computer Operation we stepped through a program that added 5 numbers, using a counter, comparing it to a limit, and branching back to a certain instruction if the counter is not over the limit? It’s these conditional branches that are the culprit. Consider a series of branches:

• One conditional branch  ⇒  2 possible behaviors to test.
• Two branches  ⇒  4 possible behaviors
• 3 branches  ⇒  8 behaviors
• …
• N branches  ⇒ 2^N behaviors
• 20 branches in sequence  ⇒ 2²⁰ = 1, 048, 576 behaviors

Nobody can test this many situations.]

Careful testing helps, but does not eliminate bugs. Why?

Can we prove, mathematically, that the software meets the specification — does what it’s supposed to do?

Examples of really, really bad software errors:

• Computers monitoring radar systems to detect Russian missile attack over the North Pole signaled an attack when the radar reflected off the rising moon. The software was correct—according to its specifications; the specifications were wrong.
• Therac radiation therapy machines overdosed at least 6 patients in 1985–1987, causing serious disability and death.

More

(Not in the textbook)

• Problem solving
  • STAIR?
  • Problem decomposition
• Software development (or just development in general)
  • SDLC
    • Requirements/specifications, design, implementation, testing, maintenance
  • Waterfall
  • Agile methodologies
    • Scrum

Summary

Resources