1

CS 106, Winter 2009Class 3, Section 4

Slides by: Dr. Cynthia A. Brown, cbrown@cs.pdx.eduInstructor section 4: Dr. Herbert G. Mayer, herb@cs.pdx.edu

2

The Problem-Solving Process

SHOW

IMAGINE

LOOK SEE

3

Requirements

• 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

4

Principles

• Each use case covers exactly one scenario.• So normally there are no conditionals (ifs)• A use case is testable. We define the test at

the same time we define the use case.• The set of use cases covers all the possible

scenarios (unless there are too many…in which case it covers the most important ones, trying for a representative sample)

5

Look and See -> Imagine

• The requirements gathering process (developing the interface, use cases, and tests) corresponds to the look and see phase of problem solving.

• Once we know what we want to do, we have to design a process for how to accomplish it. This is the imagine phase.

6

Tests are Critical

• The tests we came up with in our analysis of the “what” part will tell us whether we have done the “how” part correctly

• Otherwise the how determines the what, the bug becomes the “feature”: a bad situation!

7

A Tool for How (Process Design): Flowcharts

• Flowcharts are a tool for specifying a process• They can be as high level or as detailed as we

need them to be• They use symbols and arrows to represent

steps and choices

8

Flowchart Symbols

Flowline: Connects symbols and indicates the flow of logic.

Input/Output: Data to be read or displayed are described inside.

Terminal: Represents the beginning or end of a task.

Processing: The process description is includedinside the symbol.

Decision: Used for logic/comparison operations. Hasone entry and two exits.

9

One more…

Continuation

10

Simple Processes

• A simple process has no decisions in it; you always do it the same way

• As a result, its flowchart is just a straight line

• Example: most recipes, instruction sheets with assemble-it-yourself furniture, simple calculations

11

Simple Process: Compound Interest

• Goal: Given a number N of years, an amount P of money, and an annual interest rate R, calculate the amount of money T you will have after P is invested for N years at rate R, using interest which is compounded annually. T = P(1+R)N

• Test 1: P = 100, N = 1, R = 5% (.05): 105• Test 2: P = 100, N = 7, R = .05: 140• Test 3: P = 0, N = 7, R = .05: 0• Test 4: P = 100, N = 7, R = 0: 100• Test 5: P = 100, N = 0, R = .05: 100

12

Just for interest

• P = 100, N = 20, R = .05 gives 265• P = 100, N = 30, R = .05 gives 432

• By contrast, simple interest gives $5 per year, so after 20 years you have a total of $200; after 30 you have $250.

• If R is, say, 8%, the difference is even more striking.

13

Variables• We’ll use variables to keep track of internal state in

a process: things the process needs to remember• A variable is a name used to refer to a quantity

whose value can change• You can think of a variable as the name of a

container that holds a value– VB variable declared via DIM

• A constant is a name for a quantity whose value does not change– VB constant declared via CONST

14

Compound Interest Calculatorstart

R <- annual rateN <- number of years

P <- principal

T <- P*(1+R)^N

Output T

end

We used variables R, N, P, and T. The <- symbol denotes assigning a value to a variable.

15

Algorithm• The interest rate calculator is an example of a simple

algorithm: a type of effective method in which a list of well-defined instructions for completing a task will, when given an initial state, proceed through a well-defined series of steps, eventually terminating in an end-state

• Named for Al-Khwārizmī, Persian astronomer and mathematician

• Def: Algorithm is a finite, unambiguous sequence of instructions to start and conduct an action.

16

Procedural Thinking

• This algorithm is procedural: it follows the steps that a human would follow to compute the result

• Initially, computer programs were based on large, complex procedural algorithms

• A problem would be broken down into major steps, then each step would be refined until eventually it could be translated into code

17

Our Approach

• Our approach is object-oriented and event-driven

• This approach results in clearer programs with fewer errors, and allows easier reuse of code written for one program in another program

• But it means that the structure of the code will not follow the structure of the use cases, which are basically procedural

18

Flowchart process

• Start with a list of objects and their events, along with the internal state you need to keep track of. Be flexible… you may discover the need for more events or state variables as you design the process

• Make a flowchart for each event• Using the flowcharts, walk through the use

case tests and make sure everything works properly

19

Candy machine example

• Recall the candy machine. The interface consists of a number of objects, such as a money input slot, selection buttons, etc .

• In designing our program, we will design how each object responds to the events that can occur with it: putting money in the input slot, pushing a selection button, etc.

• Besides the interface objects, we will need to keep some internal state of the machine: how much money has been inserted, how much change it has available, and so on

20

Candy Machine, 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

21

Objects the User Interacts With

• Money input slot• Money return bin• Selection buttons• Candy pickup bin• Coin return button

22

Events for Objects

• Money input slot– User inserts a coin

• Money return bin– Machine sends money to bin

• Selection buttons– User presses a button

• Candy pickup bin– Machine sends candy to bin

• Coin return button– User presses button

23

Flowcharts for events

• For each event, we can make a flowchart to say what should happen when the event occurs

• We also need to keep track of internal state. We’ll do that using variables.

• We need to define the initial state of the machine. Then each event can change that state if need be.

24

Internal State

• Internal state persists between events• For example, if the user inserts a coin in the

money input slot, the machine needs to add the amount of money to the total that has been inserted in prior events

• If a piece of candy is dispensed, the machine needs to adjust the inventory. Alternatively, it needs to check that selection is not empty

25

Internal State We Need

• Candy inventory, or empty sensor for candy storage bins. We’ll use the sensor.

• Coin inventory• Amount of money entered• Price list for candy• VB Variables can hold state

26

Initial Internal State

• Candy bin sensors– AHasCandy <- True– BHasCandy <- True– CHasCandy <- True

• Coin inventory– NumberNickles <- 100– NumberDimes <- 100– NumberQuarters <- 100

• Amount of money entered– MoneyEntered <- 0

We’ve created some variables to keep track of the internal state, and assigned them some values that represent the initial state. We’re assuming there is candy in every bin, and 100 of each type of coin pre-loaded. No money has been entered yet.

27

More Initial State

• Candy price list– APrice <- 2.00– BPrice <- 1.40– CPrice <- .95

28

Entering a coin

• Let’s consider a simple event: the user feeds a coin into the coin slot

• What should happen?

29

Money Input Slot: Version 1

User Inserts Coin

MoneyEntered <-MoneyEntered + Value of Coin

endWe used the variable called MoneyEntered to keep track of how much money has been entered. Recall that its initial value was 0.

30

We could go into more detail…

• How much detail we put in the flow chart is up to the designer. You don’t need a box for each line of code, but you do want to use the tool to make sure you solved all the issues.

• The next slide shows a more elaborate version

31

Money Input Slot: Version 2 User Inserts Coin

end

Nickel?

MoneyEntered <- MoneyEntered + .05 Dime?

MoneyEntered <- MoneyEntered + .10 Quarter?

MoneyEntered <- MoneyEntered + .25

yes no

yes

end

no

yes

end

no

Return coin

end

This example assumes the machine only accepts nickles, dimes, and quarters.

32

A More Complex Event

• Let’s take a look at a more complex event, pushing a selection button.

• What should happen?– If the user has inserted enough money, and – the machine has change if needed, and – the machine has some candy of that kind, – then it should send the candy to the candy pickup

bin

33

So we need to check..

• How much money has been inserted• Whether the machine has the coins to make

change, if change is needed• Whether the machine has enough candy of the

selected type• Note: the variable name MoneyEntered is

changed to MonEnt to save space on the slide

34

Selection Button AEvent Flowchart

35

Something to Notice

• Keeping the value of MonEnt consistent with what is happening takes some care and thought

• After dispensing candy, and making any necessary change, or after returning coins, the value of MonEnt should go back to zero to be ready for the start of the next transaction

• Our tests need to follow each path to make sure this is true• If the tester does not have access to the internal state of

the machine, we have to do several transactions in a row to make sure each one leaves the machine in a proper state for the next one

36

Controls

• Controls are what VB calls the objects that can appear in the user interface

• Chapter 2.2 of the VB book has a nice tutorial on the most common controls– Text box– Button– Label– List box

• We’ll walk through an intro to these after the break

BREAK

10 min

DEMONSTRATION

Common Visual Basic Controls

Questions on Assignment 1?