CS 106, Winter 2009 Class 2, Section 4

1. CS 106, Winter 2009Class 2, Section 4 Slides by: Dr. Cynthia A. Brown, cbrown@cs.pdx.edu Instructor section 4: Dr. Herbert G. Mayer, herb@cs.pdx.edu 1

2. The Problem-Solving Process IMAGINE SHOW LOOK SEE

3. Six Frameworks for Showing • Who/what: qualitative representation: portrait • How much: quantitative representation: chart • Where: position in space: map • When: position in time: timeline • How: cause and effect: flowchart • Why: deduction and prediction: multi-variable chart • Combination Frameworks • Time series chart (how much and when) • Value chain (timeline/flowchart: when/how)

4. SQVID Each framework can take multiple forms based on the situation. • S: simple vs. elaborate • Q: quality vs. quantity • V: vision vs. execution • I: individual vs. comparison • D: change vs. as-is (see the “codex” on BN pg. 141)

5. Example Using Timelines • We want to make a master plan showing team leaders when each step of a complex process they are directing and coordinating will take place • When -> timeline • Since we need to convey a large amount of precise information, the timeline will be elaborate, quantitative, and execution-oriented (Gantt Chart)

6. Gantt Chart Example

7. GANTT with Dependencies

8. Baseline GANTT(shows comparison, change)

9. How Many/How Much • Bar charts are often used • Pie charts are another option (controversial) • There are plenty of interesting and clever variations… such as the word usage chart (next slide)

10. Variation on Bar ChartWord Usage in McCain Speech

11. Where: Maps Can Be Conceptual • A map is an obvious choice for looking at geographic distribution or position • But we can also use conceptual maps to show the relationships among ideas or concepts

12. CS Curriculum Map

13. Our Goal: Defining a Process • We will specify a “what”: a process we want to define. • Then we will describe “how” to complete the process for the desired result. • Let’s start by looking at some everyday descriptions of processes. • Writing a clear and complete description is not as easy as it might seem.

14. Example: Recipe What we need (partial list) How to proceed

15. Observations • The recipe assumes we have equipment like an oven and a muffin pan, grease for the pan, bowls and beaters, etc. • It assumes a lot of knowledge: What does “alternately” mean? What do you do if the butter is hard? And so on.

16. What you need This set of instructions is crying for a picture! It also make a lot of assumptions. What does “edgeband” mean? How do you attach things?

17. Defining a Process Clearly • Start with what we want to have happen: inputs, outputs, interface (picture) • Write use cases to make sure we have covered all the possibilities • Define tests to determine if our process works properly, once it is defined • Figure out and specify howit should work using a flowchart

18. Example: Candy Machine • We’re going to define the process of getting candy from a candy machine. • We start with WHAT: what is supposed to happen, precisely? What items/people are involved? • We’ll use a picture to help us out.

19. BREAK 10 min

20. Too simple…

21. More like it...

22. Initial Picture (What) candy for sale selection buttons A B C A money input slot B $$¢¢ coin return button C customer money money return bin candy pickup bin

23. Use Cases • A use case is a scenario that runs through the process • It helps us visualize the process and refine our understanding • Usually there is at least one “normal” version of the process. We start with that and then bring in unusual or exceptional versions.

24. Normal Use Case • Customer puts money in money input slot • Customer presses a selection button • Candy from that selection goes into the candy pickup bin • Customer takes the candy • This makes a lot of assumptions and is missing some things

25. Problems • What if the customer put in too little money, or too much? • Where did the money go after the customer paid? • What if all the candy is gone? • We can do some additional use cases for these, but first let’s clean up this one

26. Normal Use Case, Take 2 • Customer puts exactly the right amount of money in the money input slot. • How does the machine know how much money was put in? It needs a money counter. • Customer presses the selection button • How does the machine know it’s the right amount of money? It needs a price list. • Candy from that selection goes into the candy pickup bin • Customer takes the candy

27. Picture, Take 2 Price list Money counter candy for sale selection buttons A B C A money input slot B $$¢¢ coin return button C customer money money return bin candy pickup bin

28. Normal Use Case, Take 3 • Customer puts money in the money input slot • Customer pushes a selection button • The money put in is exactly the right amount for that selection • Candy from the selection goes into the candy pickup bin • The customer takes the candy

29. Principles • The use case covers exactly one scenario. • So normally there are no conditionals (ifs) • The use case is testable.

30. Testing the normal use case • How do you test this case? Follow the script: • Put in money • Push a selection that costs the amount you put in • See if you got the candy • Can you think of a possible problem?

31. Problem • What if the machine is out of candy for that selection? What should happen? We need to add to the normal use case description, that the machine has enough candy. Out of candy is another case, not the normal one.

32. Second use case • The customer puts money in the money input slot • The customer pushes a selection button • The amount of money put in is bigger than the price of the selection • The machine has the kind of candy selected • Candy from the selection goes into the candy pickup bin • Change goes into the coin return bin

33. Questions on second use case • Where does the machine get the change? • What if it does not have enough money, or the right coins, to give exact change? What should happen? (This would be another use case) • How does the machine know how much change to give? (Looks like it needs another component)

34. Picture, Take 3 Money counter/change computer Price list candy for sale selection buttons A B C A money input slot B $$¢¢ coin return button C customer money money return bin Money bin candy pickup bin

35. Second use case, Take 2 • The customer puts money in the money input slot • The customer pushes a selection button • The amount of money put in is bigger than the price of the selection • The machine has the kind of candy selected • Candy from the selection goes into the candy pickup bin • The machine has enough of the right kind of money to make change • Change goes into the coin return bin

36. Test for the second use case • Put money in the machine • Choose a selection that costs less than the amount you put in • Make sure the machine has the right kind of money to make change (may not be possible…) • You should get the candy and the correct change

37. Third case • The customer puts money in the machine • The customer pushes a selection button • The selection costs more than what the customer put in • What should happen? How would you test it?

38. Fourth Case • The customer puts in money • The customer pushes a selection button • The selection costs less than what the customer put in • The machine does not have enough change or the right kind of change • What should happen? How would you test this? (You might need to make the machine run out of money.)

39. What other cases can you think of? • For each one, you need to specify a script • You also need to determine a test to make sure the machine does what it is supposed to in that situation

40. What, not How • Notice that the use cases say what should happen, not how the machine decides what to do • Each separate scenario has its own case • Each case has one or more tests that verify the behavior of the machine

41. Your Assignment • Develop a set of use cases for an automated parking meter like the ones the city uses • Describe all the elements of the parking meter (picture is optional) • Do as many use cases as you can think of; try to cover all the possibilities • Include a test for each use case • Upload the final document (pdf file) to Blackboard