Presentation on theme: "Connecting with Computer Science, 2e Chapter 12 Problem Solving and Debugging."— Presentation transcript:
Connecting with Computer Science, 2e Chapter 12 Problem Solving and Debugging
Connecting with Computer Science, 2e2 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, 2e3 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
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, 2e4
5 Figure 12-1, The Tower of Hanoi puzzle The Mental Game of Problem Solving (cont’d.)
Connecting with Computer Science, 2e6 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)
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, 2e7
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, 2e8
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, 2e9
10 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
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, 2e11
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, 2e12
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, 2e13
Connecting with Computer Science, 2e14 Figure 12-2, The bug found by Grace Hopper Debugging (cont’d.) Copy editor: Heading OK though actually appears above heading in PDF (p. 413)? Copy editor: Heading OK though actually appears above heading in PDF (p. 413)?
Connecting with Computer Science, 2e15 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
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, 2e16 Rule 2: I Will Remain Calm and Remember the Mental Game of Debugging
Connecting with Computer Science, 2e17 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
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, 2e18
Connecting with Computer Science, 2e19 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, 2e20 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, 2e21 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, 2e22 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
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, 2e23
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, 2e24
Connecting with Computer Science, 2e25 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, 2e26 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
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, 2e27
Connecting with Computer Science, 2e28 Table 12-1, FtoC_versionX.src debug log, Rule 9: I Will Write Down What I Do (cont’d.)
Connecting with Computer Science, 2e29 Table 12-1, FtoC_versionX.src debug log, (cont’d.) Rule 9: I Will Write Down What I Do (cont’d.)
Connecting with Computer Science, 2e30 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, 2e31 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, 2e32 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, 2e33 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
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, 2e34
Connecting with Computer Science, 2e35 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, 2e36 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, 2e37 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, 2e38 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, 2e39 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 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, 2e40 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, 2e41 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, 2e42 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
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, 2e43