Designing Programs
The preceding sections show that the development of a program requires many steps.
We need to determine what's relevant in the problem statement and what we can ignore.
We need to understand what the program consumes, what it produces, and how it relates inputs to outputs. We must know, or find out, whether Scheme provides certain basic operations for the data that our program is to process. If not, we might have to develop auxiliary programs that implement these operations. Finally, once we have a program, we must check whether it actually performs the intended computation. This might reveal syntax errors, run-time problems, or even logical errors.
To bring some order to this apparent chaos, it is best to set up and to follow a DESIGN RECIPE, that is, a step-by-step prescription of what we should do and the order9 in which we should do things. Based on what we have experienced thus far, the development of a program requires at least the following four activities:
;; Contract: area-of-ring : number number -> number
;; Purpose: to compute the area of a ring whose radius is
;; outer and whose hole has a radius of inner
;; Example: (area-of-ring 5 3) should produce 50.24
;; Definition: [refines the header]
(define (area-of-ring outer inner) (- (area-of-disk outer)
(area-of-disk inner))) ;; Tests:
(area-of-ring 5 3)
;; expected value
50.24
Figure 3: The design recipe: A complete example Understanding the Program's Purpose:
The goal of designing a program is to create a mechanism that consumes and produces data. We therefore start every program development by giving the program a meaningful name and by stating what kind of information it consumes and produces. We call this a CONTRACT.
Here is how we write down a contract for area-of-ring, one of our first programs:10
;; area-of-ring : number number -> number
The semicolons indicate that this line is a COMMENT. The contract consists of two parts. The first, to the left of the colon, states the program's name. The second, to the right of the colon, specifies what kind of data the program consumes and what it produces; the inputs are separated from the output by an arrow.
Once we have a contract, we can add the HEADER. It restates the program's name and gives each input a distinct name. These names are (algebraic) variables and are referred to as the program's PARAMETERS.11
Let's take a look at the contract and header for area-of-ring:
;; area-of-ring : number number -> number (define (area-of-ring outer inner) ...)
It says that we will refer to the first input as outer and the second one as inner.
Finally, using the contract and the parameters, we should formulate a short
PURPOSESTATEMENT for the program, that is, a brief comment of what the program is to compute. For most of our programs, one or two lines will suffice;
as we develop larger and larger programs, we may need to add more information to explain a program's purpose.
Here is the complete starting-point for our running example:
;; area-of-ring : number number -> number
;; to compute the area of a ring whose radius is
;; outer and whose hole has a radius of inner (define (area-of-ring outer inner) ...)
Hints: If the problem statement provides a mathematical formula, the number of distinct variables in the formula suggests how many inputs the program
consumes.
For other word problems, we must inspect the problem to separate the given facts from what is to be computed. If a given is a fixed number, it shows up in the program. If it is an unknown number that is to be fixed by someone else later, it is an input. The question (or the imperative) in the problem statement suggests a name for the program.
Program Examples:
To gain a better understanding of what the program should compute, we make up examples of inputs and determine what the output should be. For example,
area-of-ring should produce 50.24 for the inputs 5 and 3, because it is the difference between the area of the outer disk and the area of the inner disk.
We add examples to the purpose statement:
;; area-of-ring : number number -> number ;; to compute the area of a ring whose radius is ;; outer and whose hole has a radius of inner
;; example: (area-of-ring 5 3) should produce 50.24 (define (area-of-ring outer inner) ...)
Making up examples -- before we write down the program's body -- helps in many ways. First, it is the only sure way to discover logical errors with testing. If we use the finished program to make up examples, we are tempted to trust the program because it is so much easier to run the program than to predict what it does. Second, examples force us to think through the computational process, which, for the complicated cases we will encounter later, is critical to the
development of the function body. Finally, examples illustrate the informal prose of a purpose statement. Future readers of the program, such as teachers,
colleagues, or buyers, greatly appreciate illustrations of abstract concepts.
The Body:
Finally, we must formulate the program's body. That is, we must replace the
``...'' in our header with an expression. The expression computes the answer from the parameters, using Scheme's basic operations and Scheme programs that we already defined or intend to define.
We can only formulate the program's body if we understand how the program computes the output from the given inputs. If the input-output relationship is given as a mathematical formula, we just translate mathematics into Scheme. If, instead, we are given a word problem, we must craft the expression carefully. To
this end, it is helpful to revisit the examples from the second step and to understand how we computed the outputs for specific inputs.
In our running example, the computational task was given via an informally stated formula that reused area-of-disk, a previously defined program. Here is the translation into Scheme:
(define (area-of-ring outer inner) (- (area-of-disk outer)
(area-of-disk inner)))
Testing:
After we have completed the program definition, we must still test the program.
At a minimum, we should ensure that the program computes the expected outputs for the program examples. To facilitate testing, we may wish to add the examples to the bottom of the Definitions window as if they were equations.
Then, when we click the Execute button, they are evaluated, and we see whether the program works properly on them.
Testing cannot show that a program produces the correct outputs for all possible inputs -- because there are typically an infinite number of possible inputs. But testing can reveal syntax errors, run-time problems, and logical mistakes.
For faulty outputs, we must pay special attention to our program examples. It is possible that the examples are wrong; that the program contains a logical
mistake; or that both the examples and the program are wrong. In either case, we may have to step through the entire program development again.
Figure 3 shows what we get after we have developed the program according to our recipe. Figure 4 summarizes the recipe in tabular form. It should be consulted whenever we design a program.
Phase Goal
choose a name that fits the problem study the problem for clues on how many unknown ``givens'' the function consumes pick one variable per input; if possible, use names that are mentioned for the
``givens'' in the problem statement describe what the function should produce using the chosen variables names formulate the contract and header:
;; name : number ...--> number
search the problem statement for examples work through the examples validate the results, if possible
make up examples
Body
to define the
function formulate how the function computes its results develop a Scheme expression that uses Scheme's primitive operations, other functions, and the variables translate the mathematical expressions in the problem statement, when available
Test to discover mistakes (``typos'' and logic)
apply the function to the inputs of the examples check that the outputs are as predicted
Figure 4: The design recipe at a glance
The design recipe is not a magic bullet for the problems we encounter during the design of a program. It provides some guidance for a process that can often appear to be overwhelming. The most creative and most difficult step in our recipe concerns the design of the program's body. At this point, it relies heavily on our ability to read and understand written material, on our ability to extract mathematical relationships, and on our knowledge of basic facts. None of these skills is specific to the development of computer programs; the knowledge we exploit is specific to the application domain in which we are working. The remainder of the book will show what and how much computing can contribute to this most complicated step.
Domain Knowledge: Formulating the body of a program often requires knowledge about the area, also known as domain, from which the problem is drawn. This form of knowledge is called DOMAINKNOWLEDGE. It may have to be drawn from simple mathematics, such as arithmetic, from complex mathematics, such as differential
equations, or from non-mathematical disciplines: music, biology, civil engineering, art, and so on.
Because programmers cannot know all of the application domains of computing, they must be prepared to understand the language of a variety of application areas so that they can discuss problems with domain experts. The language is often that of
mathematics, but in some cases, the programmers must invent a language, especially a data language for the application area. For that reason, it is imperative that programmers have a solid understanding of the full possibilities of computer languages.
4 Another advantage of Scheme's notation is that we always know where to place an operator or where to find it: to the immediate right of the opening parenthesis. This is important in computing because we need many more operators than just the few numerical operators that we use in arithmetic and algebra.
5 It is common to speak of the area of a circle, but mathematically speaking, the circle is only the disk's outer edge.
6 An arrow is keyed in as - followed by >.
7 This statement is true for any other programming language as well, for example, spreadsheet languages, C, word processor macro. Scheme is simpler than most of these and easy to understand for computers. Unfortunately, to human beings who grow up on infix expressions such as 5 + 4, Scheme prefix expressions such as (+ 5 4) initially appear to be complicated. A bit of practice will quickly eliminate this misconception.
8 We will find out in section 8 why such errors are called syntax errors.
9 As we will see later, the order is not completely fixed. It is possible, and for a number of reasons, desirable to switch the order of some steps in some cases.
10 An arrow is keyed in as - followed by >.
11 Others also call them FORMALARGUMENTS or INPUTVARIABLES.