|
Table of Contents
Learning C++:
An Index of Entry Points
2. The A reference document on the basic elements of C++.
3. The Patterns
|
A.The Four Tasks in Program
Development There are four phases or tasks in developing a program:
We have talked a bit already about coding, compiling, debugging, and
testing and will talk much more about them in the rest of this text. This
chapter focuses on analysis and some of the simplest aspects of design.
These two steps, analysis and design, are so important that many texts
don't discuss any code at all until after exploring them in detail.
Hopefully, you have a small sense of their importance from your struggles
both to understand the code you have read and to write your own programs.
Before proceeding to a detailed discussion of analysis there are three
general points to note:
B. The Analysis Phase
Questions like this constitute the first phase of programming, the
Analysis Phase. The second or design phase builds on this
first phase. The analysis and design phases of a programming task can often blur.
For us, at this point in this course, the analysis phase will consist of
describing the problem to be programmed and stating the requirements of
the problem. Specifically, the analysis phase seeks to discover:
-any screens introducing or describing the program to the user;
-the form the inputs will take including:
-the form the outputs will take
It needs to be stressed that at this point we are NOT concerned at all
with HOW the program will do what ever it is supposed to do. Our goal is
to develop a clear, precise understanding of what the program is to do. It
obviously does not make a lot of sense to start writing code or even
designing a program before one is clear on what the program is to do. C. The Steps to Analysis The second step is to use the narrative to determine more precisely
the interface of the program. As noted above the interface
includes introductory and descriptive screens, title
and welcoming screens, as well as the inputs to the program and
outputs from the program. The notion of an input implies that some value
is entered into the program from the 'outside' while an output implies
that some value is sent out of the program. We therefore need to determine
where the input values will come from and where the output values will go.
These sources and destinations could include files, keyboards, mice,
monitors, printers as well as any number of less common devices.
The values, whether seen as inputs, outputs, or both, have to somehow
be stored inside the computer. For this we use the 'variables' that we
discussed in chapter two. In that chapter we said that variables have a
form or type and therefore any description of inputs and outputs should
state their type - whether they are characters, strings, integers, doubles
or some other type. If an input is coming from the keyboard, there should
also be a description of how it will be requested - what prompt(s) or
message(s) will appear on the monitor to tell the user what information is
expected and when to enter it. If the input is to come from a file, the
format or organization of the file should be defined.
Outputs have similar descriptive needs. If an output is to go to a
monitor, there should be a description of the message to be included with
the value being output. If the output is to go to a file, the format or
organization of the file should be defined.
At this point you may be scrambling to find out HOW to write the code
to handle strings as input or how to get input from a mouse or how to
write to a file. Remember, however, that we are not concerned here with
HOW. Problem analysis can be done by people who are not programmers. Try
your best to avoid 'how questions' at this point. Just assume that
whatever wonderful design you come up with, you or someone else will be
able to, sooner or later, implement it as code. The third step in the analysis process is relatively simple - use the
narrative again to determine if there are any constants in the problem.
These should simply be listed along with their purpose. Remember, a
constant is a value that remains the same throughout a program. It is not
that constants NEVER change. A tax rate might be an example of a constant.
Tax rates change in the course of the political process but one does not
change a tax rate in the middle of the run of a program. When you go into
a store you do not expect that the first five items you buy are taxed at
6% and the rest at 6.5%. D. An Example of Problem Analysis Before proceeding, one more word of caution: Simple problems such as
this employee program often require a simple analysis. The results hardly
seem worth all the formal effort expended. Don't let the simplicity of the
analysis here lead you to believe that the analysis phase is not
important. In real world problems the analysis phase can take six months,
a year, or even longer and be much too complex for anyone to maintain in
their head. Ultimately, you will not need to go through the analysis
process for the types of problems presented in these early chapters but by
practicing on 'easy' problems you will hopefully be prepared for more
complex systems analysis. So, here is a possible narrative for the employee problem.
This is a good start - it certainly seems to provide a good amount of
detail for such a simple problem. Still, it is not quite detailed enough.
The analysis phase can be simple or complex depending both on the
complexity of the problem and on how clearly the programming task is
understood and described by those requesting the program. Often the users
(requesters) of a program do not have a good sense of what they want in a
program. At other times they may have a good sense of this but be unable
to express it. In either case, it is the task of the programmer analyst to
develop a precise description of the program and its specifications. The problem narrative just written provides an example of this in that
it has no description of the required interface. There is no information
upon which to base the second step of the analysis phase - the designing
of the interface. If you were given this problem narrative and asked to
design an interface, you would be wise to ask a few questions of potential
users, come up with your own ideas, and then show them to those who want
this program - before you write any code. In any real world programming
task a smart analyst will create an interface specification and show it to
whomever is requesting the program before going to the design or coding
stage. This will guarantee that what the programmers are working on is
really what the 'requester' wants. In this example (and still working backwards) we will start with the
relatively simple interface shown in the code for program ch2prg7. We have, however, improved somewhat
on that initial interface. For example, as implemented in chapter two,
this program has no introductory screen. One is added here because most
real programs have one or many opening/introductory screens. Read carefully through the interface analysis below. Be sure you
understand it before proceeding. Words enclosed in angle brackets
(<...>) represent possible program variables. At this point, the
exact names of the variables as used in the analysis are not important.
When you are finished, read over and run the code (ch3prg1a.cpp) that corresponds to this analysis Interface:
An Exit Screen: Inputs: 1. Prompt : "Please enter your rate of pay." 2. Prompt: Please enter the hours you worked this week"
1. "This employee's salary is: < salary>"
double Having completed the interface analysis, it is time to proceed to step
three - to look for and record any constants. A program narrative may not
explicitly list any constants and you may have to ask yourself just what
information is needed to make any calculations mentioned in the narrative.
(Note that we are not saying that you need to determine exactly HOW the
calculations are made but rather, what information is needed.) In this
example, the program narrative is more helpful. Note that it mentions two
numbers that do not seem to change as the employee information changes -
the numbers of hours that determine when overtime begins (40) and the
factor to multiply by to get the overtime pay rate (1.5). These are, of
course, the numbers declared as constants in the actual program - and they
better be because the analysis and the code should match! The next part of
the formal analysis is written this way: Constants: Below we put the whole thing together and make a few comments: /*
Program Specifications: Narrative Description:
This program is to compute the salaries of ten employees who are
paid by the hour with the possibility of earning overtime pay. Each
employee will have a rate of pay and the hours worked during the pay
period. An employee's salary is calculated by multiplying the rate of pay
by the hours worked. If the hours worked is greater than 40, the salary is
calculated by multiplying the first 40 hours by the rate of pay and the
number of hours greater than 40 by 1.5 times the rate of pay. After being
calculated, the salary of each employee will be immediately output to the
screen. Interface:
An Exit Screen: Inputs: 1. Prompt : "Please enter your rate of pay." 2. Prompt: Please enter the hours you worked this week"
1."This employee's salary is: < salary>"
double
Constants: First, observe the use of the characters '/*' to open this material and
'*/' to end it. This material is meant to go at the very top of your
program file, just after the line that states the name of the file
containing this code. We have already seen that two slashes (//) indicates
that the following code is to be ignored by the compiler as it does its
translation. When you have a multi-line comment you can use '//' at the
beginning of each line or you can begin the long comment with '/*' and end
it with '*/'. This second approach was used above. Since the analysis
phase for our relatively simple programs usually results only in a page or
so of text, we shall include the analysis in our code. For real world
problems the analysis may full 100's of pages and is kept separate from
the program, although a summary may be included with the code. Second, note that the words inside the angle brackets (<....>)
represent sets of characters that could be turned into C++ style variables
but, as written, they are not variables - there are spaces between words.
At this point you are writing an analysis of a problem. When it becomes
time to turn this into code, one could use any appropriate language.
(Technically, the comment marks discussed above are not part of the
analysis. They are only included here to show you how to include the
analysis in the programs we will be writing.)
That ends our discussion of the analysis phase. To repeat one more
time: the specifications for this program are quite simple. Having seen
such a simple example, you will be tempted to skip the specifications
writing step or do it as fast as possible. Try to avoid that temptation.
Trust in the experience of past programmers. These steps can truly save
you time later on. It is true that for a simple task, these steps will
appear to be a waste of time but you need to practice these steps on easy
tasks so that you can easily apply them to complex tasks. |
Top of Section