Connecting with Computer
Science, 2e
Chapter 12
Problem Solving and Debugging
Objectives
• In this chapter you will:
– See an overview of the history of problem-solving
techniques
– Learn some problem-solving approaches for many
fields
– Learn the 13 rules of debugging
– See some examples of the 13 rules in action
Connecting with Computer Science, 2e
2
Why You Need to Know About...
Problem Solving and Debugging
• Computer science
– The art and science of developing solutions to
problems
– Problem solving
• Debugging
– Process of finding and fixing a problem
Connecting with Computer Science, 2e
3
The Mental Game of Problem Solving
• Brief history
– Early 20th century
• Scientific study commenced using laboratories
• Focus: stripped-down math or logic problems
– 1970s
• Research moved to specific problem domains
• Less focus on finding general problem-solving processes
• Key discovery recognized and included study of intuition
and emotion roles in problem solving
• Experience in solving similar problems is a valuable skill
Connecting with Computer Science, 2e
4
The Mental Game of Problem Solving
(cont’d.)
Figure 12-1, The Tower of Hanoi puzzle
Connecting with Computer Science, 2e
5
The Mental Game of Problem Solving
(cont’d.)
• Techniques to stay positive while debugging
– Boast aloud and visualize or write down positive
results
– Think positively about the process
– Be patient (debugging takes time)
Connecting with Computer Science, 2e
6
Why Are Software Problems So Hard
to Solve?
• Problem might be easy to solve
– Depends on underlying cause
• Five bug categories:
– Coding bugs
• Easiest to find and fix
• Cause: not understanding the programming language
thoroughly
– Logic bugs
• More difficult to fix
• Example: index counter counting past end of the array
and accessing an out-of-bounds memory location
Connecting with Computer Science, 2e
7
Why Are Software Problems So Hard
to Solve? (cont’d.)
• Five bug categories (cont’d.)
– Bad data bugs
• Logic bug offshoot
• Example: simple program only handles expected input
– Compatibility bugs
• Even more difficult to debug
• Closely aligned with coding bugs
• Cause: not understanding platforms thoroughly
– Architecture bugs
• Most difficult to debug
• Might require complete code rewrite
Connecting with Computer Science, 2e
8
Why Are Software Problems So Hard
to Solve? (cont’d.)
• Reasons software is difficult to debug
– The fog of war
• Difficult to see program internals and logic
– Multiple goals
• Affect or contradict each other
– Complexity
• Program has many interrelated items with variation
– Constant change
• Program characteristics change frequently
• Leads to unpredictable results
Connecting with Computer Science, 2e
9
Problem-Solving Approaches
• Straw man argument
– Build up a problem theory knowing it will likely be
knocked down
• Rules of thumb (heuristics)
– Consist of “good enough” approximations
– Based on your experiences
• Follow a procedure
– Detailed checklist of what steps need to be followed
Connecting with Computer Science, 2e
10
The Scientific Method
• Inductive reasoning
– Basic approach to problem solving
• Steps:
–
–
–
–
Observe what is happening
Propose a theory for why it is happening
Test the theory
Repeat until the theory is strong enough to stand on
its own
Connecting with Computer Science, 2e
11
Debugging
• “Thirteen I’s”
– I will:
• Own the problem
• Remain calm and remember the mental game of
debugging
• Use the scientific method and problem-solving
approaches
• Read the manual
• Make it fail
• Look before I assume
• Divide and conquer the problem
Connecting with Computer Science, 2e
12
Debugging (cont’d.)
• “Thirteen I’s” (cont’d.)
– I will:
•
•
•
•
•
•
Isolate changes
Write down what I do (keep a debugging log)
Check the fuel level
Get another perspective
Check that the problem is fixed
Ask three questions
Connecting with Computer Science, 2e
13
Copy editor:
Heading OK
though actually
appears above
heading in PDF
(p. 413)?
Debugging (cont’d.)
Figure 12-2, The bug found by Grace Hopper
Connecting with Computer Science, 2e
14
Rule 1: I Will Own the Problem
• Programmer responsibility
– Solving problems in code he or she writes
• Do not look for scapegoats
– Wastes time and energy
• Coding bugs
– Most common category of bugs
Connecting with Computer Science, 2e
15
Rule 2: I Will Remain Calm and Remember
the Mental Game of Debugging
• Keeping a positive mind-set and being patient
–
–
–
–
–
–
–
–
Take a deep breath
Recite a positive mantra
Attack problem calmly and patiently
Use problem-solving approaches
Find someone else who might find the problem
Take different path around the problem
Do not give up easily or procrastinate
Sleep on the problem if necessary
Connecting with Computer Science, 2e
16
Rule 2: I Will Remain Calm and Remember
the Mental Game of Debugging (cont’d.)
• Thomas Edison often slept
thinking of a problem
– Held metal ball bearing in
hand
– When his hand relaxed, the
ball dropped to the floor
– Startled him into waking up
– Often had the answer he
was looking for
Figure 12-3, Thomas Edison in his lab
Connecting with Computer Science, 2e
17
Rule 3: I Will Use the Scientific Method
and Problem-Solving Approaches
• Review approaches for uncovering error origins
– Straw man arguments
– Rules of thumb (heuristics)
– Following a procedure
• Review scientific method steps
–
–
–
–
Observe
Create a theory
Test the theory
Repeat
Connecting with Computer Science, 2e
18
Rule 4: I Will Read the Manual
• Important step:
– Read pertinent manual
• Examples:
– HTML definitions at World Wide Web Consortium
(W3C) Web site
– Documentation for borrowed code
– Online discussion boards, blogs, and wiki posts
• Manuals may have errors but still contain valuable
information
Connecting with Computer Science, 2e
19
Rule 5: I Will Make It Fail
• Re-create bug to figure out how to fix it
• Intermittent bugs are especially difficult to trace
– Force program to fail
• Examine how it fails
• Determine why it fails
• Look for ways to fix it
– It is important to see when a bug does not occur
– Save all debugging tools for the future
Connecting with Computer Science, 2e
20
Rule 5: I Will Make It Fail (cont’d.)
• Methods
– Run program repeatedly
• Make changes one at a time
– Start over and re-create the program
– Automate process of running the program repeatedly
• Provide slight variations in input each time
– Look for all external effects on the program
• Include user input
Connecting with Computer Science, 2e
21
Rule 6: I Will Look Before I Assume
• Do not assume cause of the failure
– May try to fix good code
• Double-check what is actually happening
• Focus debugging efforts
– Examine what is working and not working in the code
– Use available debugging tools
• Print statements in code
– Make one or more copies for experimentation
• Use descriptive naming conventions
Connecting with Computer Science, 2e
22
Rule 7: I Will Divide and Conquer the
Problem
• Start with the low-hanging fruit
– Fix obvious problems first
• Good chance of correcting more serious bugs
– Recognize that bugs likely cause other bugs
• Memory allocation problems can cause havoc
Connecting with Computer Science, 2e
23
Rule 7: I Will Divide and Conquer the
Problem (cont’d.)
• Narrow the search with continual approximation
– Occam’s razor principle
• Simplest explanation for a phenomenon is most likely
the correct explanation
– “Keep it simple, stupid” (KISS) rule
• Complexity makes finding a problem and solution more
difficult
– Breakpoint
• Stop command inserted to prevent program from
executing past that point
Connecting with Computer Science, 2e
24
Rule 7: I Will Divide and Conquer the
Problem (cont’d.)
• Create easy-to-spot patterns
– Use test data providing easy-to-spot patterns
• Makes problems jump out more obviously
– Examples:
• Create a database with similar but fewer records
• Create an input file with the same line of text used
everywhere
Connecting with Computer Science, 2e
25
Rule 8: I Will Isolate Changes
• Change one thing at a time
• Change the fewest lines of code possible
– Back out if change does nothing
• Keep more than one version of a program
– Compare differences
– Send output to different files
• Run a compare program: UNIX diff command
• Use an iterative approach when writing a program
– Saves debugging time and provides a baseline
Connecting with Computer Science, 2e
26
Rule 9: I Will Write Down What I Do
• Use a debugging log
– Keep record of the changes made
• Keep program versions
– Use version control software
• Microsoft Visual SourceSafe
– Manually record version in simple text file or
spreadsheet
• Electronic logs can be shared
• Write down changes in order
– Record results of changes and review correlations
Connecting with Computer Science, 2e
27
Rule 9: I Will Write Down What I Do
(cont’d.)
Table 12-1, FtoC_versionX.src debug log, 5-17-10
Connecting with Computer Science, 2e
28
Rule 9: I Will Write Down What I Do
(cont’d.)
Table 12-1, FtoC_versionX.src debug log, 5-17-10 (cont’d.)
Connecting with Computer Science, 2e
29
Rule 9: I Will Write Down What I Do
(cont’d.)
• Reason to record information
– May work on other people’s programs
– Programs run on a variety of operating systems and
interact with other software and hardware
• May not have been originally designed for them
– Programmer might not have documented well
• As time passes, they may no longer understand the
reasoning behind some of the code
Connecting with Computer Science, 2e
30
Rule 10: I Will Check the Fuel Level
• Start with the most likely problems and move up
– Coding (syntax errors), logic problems, compatibility
issues, and architecture problems
• Make sure assumptions are correct
– Verify the running program is the correct program
– Make sure program is starting with correct initial
conditions
• Verify that debugging tools are working correctly
Connecting with Computer Science, 2e
31
Rule 11: I Will Get Another Perspective
• Obtaining input from other people saves time and
frustration
– Process of explaining problem may add insight
• Use others as a sounding board
• Talk out loud when solving problems
• Take advantage of others’ experience
• Always report exactly what is happening
– Do not present theories
– Stick to facts
Connecting with Computer Science, 2e
32
Rule 12: I Will Check That the Problem
Is Fixed
• Test both working and nonworking versions
– Verify the solution
• Bugs do not go away by themselves
– If bug seems to solve itself, this usually means
program conditions are not the same
• Others may make a change that fixes the bug
– Example: updates to a programming language
– Understanding how the bug was fixed provides
confidence it will not return
• Track bugs that cannot be fixed
Connecting with Computer Science, 2e
33
Rule 13: I Will Ask Three Questions
• Is this mistake occurring anywhere else?
• What next bug is hidden behind this one?
• What should I do to prevent similar bugs?
Connecting with Computer Science, 2e
34
The Rules in Action
• Review the rules related to Story 1
Story 1: A student asked me why his picture wasn’t showing up on
his Web page. He had tried the Web page on his PC, and it
worked, so he loaded the page on the server we’re using. I asked,
“Where’s the picture file?” Frustrated, he responded, “Right here,
on my computer!” I told him the picture file needs to be on the
server. He uploaded it, but he still couldn’t display the picture. The
problem was he had changed the filename to include spaces, and
the server was running Linux. I’d told my students that in Linux,
spaces in filenames aren’t typical and could cause problems. Of
course, if you’re used to Windows, you use spaces in filenames all
the time. The student changed the spaces to underscores, but he
also changed uppercase letters in the filename to lowercase
letters, and Linux is case sensitive.
Connecting with Computer Science, 2e
35
The Rules in Action (cont’d.)
• Review the rules related to Story 2
Story 2: I was working on a program and wondered why a
variable wasn’t changing. I’m new to programming in PHP, so I
assumed that variable scope (where in the program a variable is
visible) was the same as in other languages I’ve used. I kept
banging away at it, changing different parts of the program one at
a time and seeing it break repeatedly. Finally, I asked a coworker
for help, who suggested I look up variable scope in PHP. Sure
enough, my assumptions were wrong. It took about 5 minutes of
looking up information to solve the problem versus the 45
minutes I had spent changing the code every which way.
Connecting with Computer Science, 2e
36
The Rules in Action (cont’d.)
• Review the rules related to Story 3
Story 3: I decided to write a little client/server game as a way to
learn about sockets. Based on what I’d read, I assumed the
process should go like this: I send a message to the server. It
responds “I’m here.” Then I send the message “Here’s the work to
do.” The server responds with “Working” or “Here’s the answer.”
However, it didn’t work that way. The server responded with one
message: “I’m here and here’s the answer.” Now it appeared to be
working the way I’d assumed it should, but the response didn’t
match what I’d read in the manual, so I had to experiment.
Connecting with Computer Science, 2e
37
The Rules in Action (cont’d.)
• Review the rules related to Story 4
Story 4: I had to write an ASCII program for converting file types.
It worked flawlessly, so I took it to my boss, and he gave me a 2.5
GB file. Well, the program wouldn’t work. It took me a while to
realize that the file was too big. I had to rewrite the program
completely because no one told me the program had to handle
such a large input. Of course, we were both at fault. I should
have asked, but my boss should have told me.
Connecting with Computer Science, 2e
38
The Rules in Action (cont’d.)
• Review the rules related to Story 5
Story 5: My mom called me and complained that she couldn’t enter
her password for her e-mail account. My first question was “Can
you enter text anywhere else?” Turns out she couldn’t. My next
thought was that the keyboard wasn’t hooked up. I knew she had a
wireless keyboard, so I told her to try resetting it, and if that didn’t
work, try replacing the batteries. It worked!
Connecting with Computer Science, 2e
39
One Last Thought
• Print the rules
– Post them near the computer
• Reference this chapter after reading other chapters
• In the debugging world:
– It is mind over (virtual) matter
– Breathe deeply and stay positive
Connecting with Computer Science, 2e
40
Summary
• Computer science is problem solving
• Brief history of problem-solving techniques
– Scientific study commenced using laboratories
– Research moved to specific problem domains
– Study of intuition and emotion roles
• Stay positive while debugging
• Five bug categories
– Coding bugs, logic bugs, bad data bugs, compatibility
bugs, architecture bugs
Connecting with Computer Science, 2e
41
Summary (cont’d.)
• Reasons software is difficult to debug
–
–
–
–
The fog of war
Multiple goals
Complexity
Constant change
• Problem-solving approaches
– Straw man argument
– Rules of thumb (heuristics)
– Follow a procedure
Connecting with Computer Science, 2e
42
Summary (cont’d.)
• The scientific method
–
–
–
–
Observe
Propose a theory
Test
Repeat preceding steps until theory strong enough to
stand on its own
• 13 rules of debugging
– Useful guidelines for what to remember when
debugging
Connecting with Computer Science, 2e
43
Descargar

faculty.cs.weber.edu