Major revision, 2017 Jan 18.
A 5-step framework for problem solving.
1. S is for State the Problem.
It helps to know what you’re trying to do, and if you can’t state it in words, you probably don’t. Even if you can state it in words, you still might not really know.
Problem 1: There’s a raccoon in my garage.
More correctly and positively stated in terms of the goal: I want the raccoon to be out of my garage.
Problem 2: I want to go to Chicago.
2. T is for Tools.
List the tools that you might use to do this job. Tools might be physical tools, such as hammer and saw; or software tools, such as a word processor, calculator, or drawing program; or conceptual tools or strategies, such as logical reasoning, scientific method, or the standard method for solving a linear equation with one variable.
Problem 1: What are some “tools” you could consider for getting the raccoon out of the garage?
Problem 2: For the trip to Chicago, there’s car, bus, airplane, bicycle; if you want to drive, you might look at Google Maps or something similar.
3. A is for Algorithm.
“Algorithm,” remember, means a procedure for solving a problem: a plan.
It is now time to evaluate the proposed tools, pick one or more of them, and if there is a combination, then decide in what order and how to apply them.
Problem 1: …
Problem 2: We decide to drive our car to Chicago, and use our smartphone’s Google Maps app for navigation.
4. I is for Implementation.
Implementation means doing it, carrying out the plan. Mistakes may be made at this stage, and surprises may occur.
Problem 1: …
Problem 2: On our road trip, we could miss a turn, we could run out of gas, we could have a flat tire, get caught in a blizzard … or everything could go perfectly according to plan.
5. R is for Refinement.
After (or while) implementing the plan, review the result. Did we achieve the goal? If not, what went wrong?
(This is debugging.)
Things could go wrong at any of the four preceding steps.
In the implementation: We missed a turn or ran out of gas.
In the algorithm: We might have chosen the wrong tool, or the wrong set of tools, or combined them in the wrong way or in the wrong order. We might have forgotten our credit card and not carried enough cash to buy gas to get us to Chicago.
In the list of tools: We might have omitted a tool that is essential. Can we get to London by bus, plane, or bicycle?
In the problem definition:
During the Cold War, computers monitoring radar systems to detect Russian missile attack over the North Pole signaled an attack within a few weeks of being switched on for the first time. It turned out that the radar was reflecting off the rising moon. Software developers had defined the problem formally in a specifications document. The software correctly solved the problem defined in the specifications document. The specifications had incorrectly defined the problem.
So you figure out what went wrong and go back and fix it.
The farther back you have to go, the more work is involved in making it right.
(Tools)
If some part of the page does not display in the web browser or displays differently than expected, the error in the HTML is probably near the last part before that that displays correctly.
Notepad++ and other good text editors show syntax highlighting. If something is not the right color, there’s probably an error there or nearby.
Web browsers such as Firefox and Chrome also show syntax highlighting, with errors marked in red. View the “page source” (HTML code) usually by pressing Control-U.
W3C and Nu validators will check for errors and describe any that they found—possibly in ways that are unclear to you, but ask the instructor.
There are two kinds of errors in software, whether it’s HTML pages or computer programs.
Syntax errors. “Syntax” means the grammar of the language. Here are two examples:
<a herf="http://www.iue.edu">IU East</a>
<par>There was a shaggy dog....</par>
Omitting or mistyping required punctuation is another common kind of syntax error.
When the web browser (or any program that has to process this code) encounters a syntax error, it simply doesn’t mean anything, so it will either try to guess what to do (which is what web browsers typically do) or just stop and complain about the error.
Logic errors. The syntax is correct, but you tell the computer to do something other than what you should. Examples:
<a href="http://www.purdue.edu">IU East</a>
<h5>There was a shaggy dog....</h5>
The computer will simply do what you tell it to do, without reporting an error. So this kind of error is often less easy to notice, because there is no error message.
Example: debug-this-page.html (right-click to download the file).
When a problem is too complex, break it down into subproblems. Then apply your creative problem-solving mind to one subproblem after another.
When you’ve solved all the pieces of the puzzle, put them together.
Problem 3: Plan a trip to Chicago.
Decomposition:
Problem 4: I want to create a web page (or site) about George Washington.
One possible problem decomposition:
Sometimes the subproblems themselves need to be divided.
Problem 4.2: make a web page (or web site) about George Washington.
One decomposition is:
Another:
There’s often more than one way to do it. Sometimes one way is better than another, and sometimes not.
(See p. 143) Be able to:
Computers do what we say, not what we mean.
Pay attention to feedback from the system
Possible sources of errors that occur when we use software (developed by competent programmers):
Of these, #1 and 2 are our responsibility and the most common.
Not guaranteed to work, but a useful framework.
Debug this web page: debug-this-page.html (right-click to download the file).
[Snyder’s example:]
What steps didn’t seem to fit in the framework?
Debugging a printing problem; discovering the print queue.