CS 106, Winter 2009 Class 3, Section 4

1. CS 106, Winter 2009Class 3, 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. 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 included inside the symbol. Decision: Used for logic/comparison operations. Has one 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 Calculator start R <- annual rate N <- number of years P <- principal We used variables R, N, P, and T. The <- symbol denotes assigning a value to a variable. T <- P*(1+R)^N Output T end

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 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

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 end We 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 This example assumes the machine only accepts nickles, dimes, and quarters. yes no Nickel? MoneyEntered <- MoneyEntered + .05 yes no Dime? MoneyEntered <- MoneyEntered + .10 yes Quarter? no end MoneyEntered <- MoneyEntered + .25 Return coin end end end

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 A Event 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

37. BREAK 10 min

38. DEMONSTRATION Common Visual Basic Controls

39. Questions on Assignment 1?