Problem solving and program development A Problem Solving

Why do we need this? • The DJ story • So how do we go about solving problems or designing programs? • How do we define a problem? – A program should solve the problem • First we define the problem Copyright © 2005 -2011 Curt Hill

Problem definition • What needs to be done? • What do we have to start with? – Data and tools • Is it feasible? – Can a program actually solve this kind of problem – Consider the registration problem • Do we have an algorithm that can solve it? Copyright © 2005 -2011 Curt Hill

What is an algorithm? • Algorithm: A prescribed set of well defined rules and processes for solving a problem in a finite number of steps • Prescribed: known in advance • Well defined: unambiguous, clear • Finite: always ends • Not every program implements an algorithm, but most do Copyright © 2005 -2011 Curt Hill

Find phone number • 1. Start with whole telephone book • 2. Find middle page of the candidate pages • Is name on page? • Yes search sequentially • Done • 3. Is name less than on page • • • Eliminate last half of book Go to (2) Is name larger Eliminate first half Go to (2) Copyright © 2005 -2011 Curt Hill

Example Revisited • Does this conform to the definition? – Prescribed, well defined, finite? • What are the assumptions? – Sorted order of names – Bounded size – Does this example conform to the definition? • Is this the best algorithm? – No Copyright © 2005 -2011 Curt Hill

Stepwise refinement • General engineering technique to solve problems – Frequently used in a variety of disciplines not just Computer Science • Also known as Divide and Conquer • Here is an example from another discipline Copyright © 2005 -2011 Curt Hill

Architecture Example • A large project will never be done by one person • A lead architect will cast the vision • This person will subdivide the project into pieces – – Foundation Exterior HVAC Floor layout • Each is more manageable than whole Copyright © 2005 -2011 Curt Hill

Course Design • A teacher may not design a course or write a text book in one session • Instead they ponder what the outcomes of the student should be • Then they divide the course/book into sections that accomplish this • Finally they design the sections/chapters/lessons Copyright © 2005 -2011 Curt Hill

Program Design • Four steps with four keywords: – Understand – Code – Test – Refine • The four keywords need a little more substance • What is supposed to happen during each step? Copyright © 2005 -2011 Curt Hill

Understand • Most important step • No way to solve the problem that is not understood • If we do not understand the problem we solve the problem we think exists not the one that really exists • In programming we must understand the three pieces: input, processing, output Copyright © 2005 -2011 Curt Hill

Understanding the pieces • Input – Either from console or edit boxes – May also be from a file • Output – Display to user – Store in file • Do processing by hand – If you cannot do it manually you cannot write the program – PI example Copyright © 2005 -2011 Curt Hill

Code • Series of 3 to 12 steps • Steps start as English (or natural language) statements • Refined into programming language • Create variables as you need them • Defer types as long as possible • When you do things out of order, that’s when mistakes are made Copyright © 2005 -2011 Curt Hill

Why? • Why 3 -12 steps? • Fewer does not really sub-divide the problem • More is more than we can juggle without dropping something • Complexity is what causes us to make errors • The magic number is 7 ± 2 Copyright © 2005 -2011 Curt Hill

Test • Walk through by hand (tracing exercise) • Hand testing will give you understanding about refinement • Also show errors • The earlier an error is discovered the easier to fix Copyright © 2005 -2011 Curt Hill

Refine • If the coding of a statement is obvious – True: code it – False: This is a new problem • Start at the understand step • This step is the new problem • As you refine language shifts from English to the programming language desired Copyright © 2005 -2011 Curt Hill

The Wisdom of Maggie • This story occurred when Maggie was 5 • She asked her uncle why he did not bring a swim suit to the motel • He said he did not know the motel had a pool • She said: You saw it when you came into the motel. Why didn’t you pack your suit? • This kind of sequence error is very common in 5 year olds, but sometimes we adults to exactly the same thing • This is part of the ordering our solutions Copyright © 2005 -2011 Curt Hill

Direction • The trip through English must include a goal of eventual conversion to programming language • As we refine we are aware of the fundamentals of the target language: – Methods/functions – Decision statements – Loop statements Copyright © 2005 -2011 Curt Hill

Coding of a program • Prepare for failure • Make each run count • Enter debug couts or memo displays with identified variables • Enter IFs that test your assumptions • Precautionary procedure: – #define debug true (C/C++) – boolean debug = true; – if (debug) display variables Copyright © 2005 -2011 Curt Hill

Other Hints • Many steps that started out as an English statement end up being a method/function • Keep methods short – Magic number is 7 ± 2 • A method should do one thing • Generally should fit on one screen • Many small methods are better than one long one Copyright © 2005 -2011 Curt Hill

Documentation • Comment at front of program: – Name of author – Purpose of program – How purpose is accomplished – Input data – Output data • A revision history is also a good idea Copyright © 2005 -2011 Curt Hill

More documentation • In declarations – What an identifier does • Name should give clue – Comment should be more detailed • In code – The basic skeleton from stepwise refinement – Explanation of anything not obvious • Method/function purpose Copyright © 2005 -2011 Curt Hill