1 CS 106, Winter 2009 Class 2, Section 4 Slides by: Dr. Cynthia A. Brown, Instructor section 4: Dr. Herbert G. Mayer,

2 The Problem-Solving Process SHOW IMAGINE LOOKSEE

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 Chart Word 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 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? What you needWhat you need

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) $$¢¢ A B C A B C customermoney candy for sale selection buttons money input slot coin return button 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 $$¢¢ A B C A B C customermoney candy for sale selection buttons money input slot coin return button money return bin candy pickup bin Money counter Price list

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 $$¢¢ A B C A B C customermoney candy for sale selection buttons money input slot coin return button money return bin candy pickup bin Money counter/chan ge computer Price list Money 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