CS 106, Winter 2009 Class 2, Section 4

1

CS 106, Winter 2009Class 2, Section 4

Slides by: Dr. Cynthia A. Brown, [email protected] section 4: Dr. Herbert G. Mayer, [email protected]

2

The Problem-Solving Process

SHOW

IMAGINE

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

This set of instructionsis crying for a picture!

It also make a lot ofassumptions. What does “edgeband” mean? How do you attach things?

What 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

customer money

candy for saleselection buttonsmoney 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

customer money

candy for saleselection buttonsmoney 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

customer money

candy for saleselection buttonsmoney input slot

coin return button

money return bin

candy pickup bin

Money counter/change 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