1. Problem Solving and Algorithm Design

2. 2 Problem Solving Problem solving The act of finding a solution to a perplexing, distressing, vexing, or unsettled question.

3. 3 Problem Solving G. Polya wrote How to Solve It: A New Aspect of Mathematical Method His “How to Solve It” list is quite general.  It’s written in the context of solving mathematical problems.  With simple wording changes the list becomes applicable to all types of problems.

4. 4 Ask Questions... …to understand the problem:  What do I know about the problem?  What is the information that I have to process in order the find the solution?  What does the solution look like?  What sort of special cases exist?  How will I recognize that I have found the solution?

5. 5 Look for Familiar Things You should never “reinvent the wheel”. In computing, you see certain problems again and again in different guises. A good programmer sees a task, or perhaps part of a task (a subtask), that has been solved before and plugs in the solution.

6. 6 Divide and Conquer Break up a large problem into smaller units that can be handled more easily.  Abstraction plays an important role.  The divide-and-conquer approach can be applied over and over again until each subtask is manageable.

7. 7 5 Abstraction - A mental model that removes complex details. This is a key concept. Abstraction will reappear throughout the course – be sure you understand it! Abstraction

8. 8 Algorithms Algorithm: A set of instructions for solving a problem or subproblem in a finite amount of time using a finite amount of data. The instructions must be unambiguous.

9. 9 Example of an Algorithm Preparing a Hollandaise sauce:

10. 10 Pseudocode … uses a mixture of English and formatting to make the steps in the solution explicit.

11. 11 Developing an Algorithm Since implementing the algorithm involves making it computer-readable, the plan must be in a suitable form. The methodology (set of working methods) used to make the plan must begin with a problem statement and conclude with a plan that can be easily coded.

12. 12 Developing an Algorithm Two methodologies are currently used, both based on the divide-and-conquer strategy:  Top-Down Design (functional decomposition)  Object-Oriented Design (OOD)

13. 13 Top-Down Design … consists of breaking the problem into a set of subproblems called modules. It creates a hierarchical structure of problems and subproblems (modules). This process continues for as many levels as it takes to expand every task to the smallest details. A step that needs to be expanded is an abstract step. A step that needs no more expansion is a concrete step.

14. 14 Top-Down Design Figure 6.5 An example of top-down design

15. 15 Object-Oriented Design Object-orientedObject-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. An object is an exemplar of a class. A class defines the abstract characteristics of a thing (object), including the thing's properties and the things it can do, or methods. One might say that a class is a blueprint that describes the nature of something.

16. 16 Object-Oriented Design An example: The class of Dog defines all possible dogs by listing the characteristics and behaviours they can have; the object Lassie is one particular dog, with particular versions of the characteristics. A Dog has fur; Lassie has brown-and-white fur.

17. 17 Object-Oriented Design Programming techniques may include features such as: information hiding, information hiding data abstraction, data abstraction encapsulation, encapsulation modularity, modularity polymorphism, polymorphism and inheritance.inheritance

18. 18 Testing the Algorithm Regardless of the design methodology, the algorithm itself must be tested. Testing at the algorithm development phase involves looking at each part of the design.

19. 19 Testing the Algorithm Desk checking: Working through a design at a desk with a pencil and paper. Walk-through: Manual simulation of the design by the team members, taking sample data values and simulating the design using the sample data. Inspection: One person (not the designer) reads the design (handed out in advance) line by line while the others point out errors.