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

The Problem-Solving Process SHOW IMAGINE LOOKSEE 2

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 3

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

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

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

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 7

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

One more… Continuation 9

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 10

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:

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

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 13

Compound Interest Calculator start R <- annual rate N <- number of years P <- principal R <- annual rate N <- number of years P <- principal T <- P*(1+R)^N Output T end 14 We used variables R, N, P, and T. The <- symbol denotes assigning a value to a variable.

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

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 16

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 17

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 18

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 19

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

Objects the User Interacts With Money input slot Money return bin Selection buttons Candy pickup bin Coin return button 21

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 22

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

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 24

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 25

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

More Initial State Candy price list – APrice < – BPrice < – CPrice <

Entering a coin Let’s consider a simple event: the user feeds a coin into the coin slot What should happen? 28

Money Input Slot: Version 1 User Inserts Coin MoneyEntered <-MoneyEntered + Value of Coin end 29 We used the variable called MoneyEntered to keep track of how much money has been entered. Recall that its initial value was 0.

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 30

Money Input Slot: Version 2 User Inserts Coin end Nickel? MoneyEntered <- MoneyEntered +.05 Dime? MoneyEntered <- MoneyEntered +.10 Quarter? MoneyEntered <- MoneyEntered +.25 yesno yes end no yes end no Return coin end 31 This example assumes the machine only accepts nickles, dimes, and quarters.

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 32

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 33

Selection Button A Event Flowchart 34

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 35

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 36

BREAK 10 min

DEMONSTRATION Common Visual Basic Controls

Questions on Assignment 1?