378 lines
15 KiB
Prolog
378 lines
15 KiB
Prolog
|
||
ÛßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßÛ
|
||
Û HOW TO PROGRAM Û
|
||
Û Û
|
||
ÛÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÛ
|
||
|
||
|
||
INTRODUCTION
|
||
|
||
|
||
Writing small programs is pretty easy stuff. True, there were some details
|
||
that had to be learned, as well as new concepts. But, the basic mechanics
|
||
were simple.
|
||
|
||
Writing large programs is quite another matter. There are several reasons
|
||
why long programs are more difficult to write. One is that short programs
|
||
are often used just once, and then discarded. Long programs, on the other
|
||
hand, are often designed for use by others. Consequently, they have to be
|
||
written more carefully, to anticipate all forms of misuse. They must also
|
||
be provided with elaborate documentation and manuals.
|
||
|
||
|
||
|
||
|
||
|
||
Another reason, many believe, is the limitation of a human being's short
|
||
term memory. Most persons can understand or grasp a short 10-line program
|
||
in a few seconds. And they can keep it in mind while they contemplate
|
||
changes. With large programs, the programmer must have all useful inform-
|
||
ation written down so it can be referred to when attempting to understand
|
||
or change the program.
|
||
|
||
Still another reason is the limit of what can appear on single screen or
|
||
page. Short programs that in their entirety occupy but one page, or one
|
||
screenful, are easier to understand than longer programs, which require
|
||
page-turning or screen-scrolling.
|
||
|
||
Whatever the reasons, writing large programs is not easy. Even profes-
|
||
sional programmers have trouble. One hears about rockets crashing because
|
||
of programming errors. And one hears that large programs may have hun-
|
||
dreds, or even thousands, of errors many months after they were allegedly
|
||
completed.
|
||
It is almost impossible to write a program that has no errors. If for no
|
||
other reason, we often do not know exactly what the program is supposed to
|
||
do, to the last detail, until after we have built it. But there is much
|
||
when can do to bring us closer to that error-free goal. The first step is
|
||
to understand the stages in developing a large program. These stages are
|
||
often referred to as the Software Development Life Cycle.
|
||
|
||
|
||
|
||
|
||
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
||
³ ³
|
||
³ 1. SPECIFICATION ³
|
||
³ 2. PROGRAM DESIGN ³
|
||
³ 3. CODE DESIGN ³
|
||
³ 4. CONSTRUCTION AND DESIGN ³
|
||
³ ³
|
||
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
|
||
|
||
|
||
|
||
If, despite all our efforts with these four stages, errors still exist in
|
||
our program, then we will have to consider techniques to isolate errors.
|
||
This process is often call DEBUGGING, and is usually considered to be part
|
||
of STEP 4.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
|
||
º SPECIFICATION º
|
||
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
|
||
|
||
|
||
|
||
It is important to know what the program is supposed to do before starting
|
||
to build it. This is especially true if the program is being built for
|
||
someone else.
|
||
Matters to be determined during this stage include the user interface,
|
||
algorithms, data structures, generality, and robustness.
|
||
|
||
USER INTERFACE
|
||
What should the user have to do to interact with the program? Should there
|
||
be commands to be typed in? Should one use menus? How much freedom should
|
||
be allowed the user, with respect to, say, spelling errors? What should the
|
||
output displays look like?
|
||
|
||
It is at this stage that you should decide how best to PROMPT the user for
|
||
proper input, and how best to label the output. This is not always as easy
|
||
as it sounds.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
ALGORITHMS
|
||
If the program requires extensive computation, what methods should be used?
|
||
For example, if a list of names needs sorting, which sorting ALGORITHM
|
||
should be used. ALGORITHM is merely the name given to a computational method
|
||
that (a) might require input, (b) always produces some output, (c) completes
|
||
its work in a fnite amount of time, and (d) does what it is supposed to do.
|
||
|
||
DATA STRUCTURES
|
||
How should the data of a problem be organized? Should one use lists or
|
||
tables? Should the data itself be sorted, or should use be made of an
|
||
indexed sort? Which, if any, data should be stored in files? One should
|
||
spend as much time answering questions like these as questions of what
|
||
algorithms to use. For, the efficiency of a well-written sorting algorithm
|
||
will be lost if the data are stored clumsily.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
GENERALITY
|
||
Should a program be a special purpose program limited for use in a small
|
||
number of situations? Or should the program be general purpose, of use in
|
||
a wider variety of circumstances? There are arguments to be made in each
|
||
choice. A special purpose program is almost always easier to use. Fewer
|
||
commands have to be given, and fewer choices have to be made, to get it
|
||
to do its job. More general programs, besides being much longer, require
|
||
the user to make more choices and issue more commands to get it work.
|
||
And, the user may have to study a much larger manual before using the
|
||
program.
|
||
|
||
On the other hand, a general purpose program will do more things for the
|
||
user. And perhaps, only one general purpose program might be needed for
|
||
a series of tasks, whereas several special purpose programs would be
|
||
needed.
|
||
|
||
ROBUSTNESS
|
||
Robustness is the degree to which a program responds "gracefully" to being
|
||
fed bad data or bad commands. For example, does it give the user a second
|
||
chance if the user misspells the filename? These are but a few of the kinds
|
||
of questions that must be during the specification or planning stages of
|
||
building a large program.
|
||
|
||
|
||
|
||
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
|
||
º PROGRAM DESIGN º
|
||
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
|
||
|
||
|
||
|
||
Program design is the most difficult part of building a large program.
|
||
For the most part, it involves deciding how a large program should be
|
||
divided into subroutines. A design is often represented by a structure
|
||
chart, which is simply a chart that shows which subroutines call which
|
||
other subroutines.
|
||
|
||
For example, a top-level subroutine, which is actually the main program,
|
||
calls three other subroutines. Thats all there is, as the three other
|
||
subroutines do not call other subroutines.
|
||
|
||
Structure charts shows the names of the data that are used and produced
|
||
by each subroutine. If the data are passed to and from the subroutine as
|
||
parameters, their names appear next to small arrows close to the line
|
||
connecting the subroutines. If the data are not passed, we use arrows
|
||
that originate and terminate inside the rectangles that represent the
|
||
subroutines.
|
||
|
||
|
||
|
||
Given a particular design (a particular structure chart), there are
|
||
two important questions that need to be raised. First, how does one
|
||
evaluate the design? And second, how does one develop a design in the
|
||
first place? Although there are design methodologies whose purpose is
|
||
to come up with a design, suffice to say, they require a careful and
|
||
thorough understanding of the underlying problem, and take sometime to
|
||
explain and understand.
|
||
|
||
|
||
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
||
³ ³
|
||
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ SALES4 ÃÄÄÄÄÄÄÄÄÄ¿
|
||
³ ³ ³ ³
|
||
³ ÀÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÙ ³
|
||
ITEMS ³ ITEMS o ³ ITEMS o ¿ ³
|
||
PERSONS³ PERSONS ³ ³ PERSONS ³
|
||
PRICE() ³ PRICE() ³ PRICE() ³
|
||
SALES(,) ³ SALES(,) ³ SALES(,) ³
|
||
ÚÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÁÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÁÄÄÄÄ¿
|
||
ÀÄÄÃÄo ³ ³ PERSONRESULT ³ ³ITEMRESULT ³
|
||
³ READDATA ³ ³ ³ ³ ³
|
||
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÙ
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
The following are a few ideas that can be used to evaluate a design,
|
||
once one has been made. These ideas are heuristic because following
|
||
them usually, but not necessarily, leads to a good design.
|
||
|
||
|
||
KEEP SUBROUTINES SHORT
|
||
|
||
It is better to keep subroutines shorter than one page, or one screenful,
|
||
in length. If that is not possible, then so be it. But it is much harder
|
||
understand a subroutine if you must constantly shift pages or screens
|
||
back and forth.
|
||
One exception to this principle occurs when a subroutine consist of,
|
||
say an IF structure with a large number of ELSEIF parts. Here, the cure
|
||
(having several short subroutines) is worse than the illness (having one
|
||
long subroutine.)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
KEEP SUB-ROUTINES SINGLE-PURPOSE
|
||
|
||
A subroutine that does one single task is almost always easier to write
|
||
and test than a subroutine that does several tasks. A single task may,
|
||
however, be quite complicated. For example, a subroutine that solves
|
||
a linear programming problem is necessarily quite complicated, and may
|
||
indeed call other subroutines. But it still has its purpose, a single
|
||
task.
|
||
|
||
Software engineers use the term (cohesion) to describe the degree to which
|
||
subroutines can range from being single-purpose (functional Cohesion) to
|
||
being a disjointed collection of unrelated tasks (coincidental cohesion).
|
||
|
||
KEEP CALLING SEQUENCES SHORT
|
||
|
||
If a subroutine needs four data elements to do its work, then the calling
|
||
sequence must contain four parameters. For example, the subroutine person-
|
||
result needs four parameters (the number of persons, the number of items
|
||
the price list, and the sales table). Four is not too many, but if a
|
||
calling sequence contains ten or more parameters, perhaps it is time to
|
||
reconsider the design.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
COMMUNICATE DATA THROUGH CALLING SEQUENCES
|
||
|
||
As much as it is possible, one should supply the data needed by subroutines
|
||
through their calling sequences. The reason is that it is then clearer what
|
||
data are needed by the subroutine and therefore less likely that errors will
|
||
occur. This goal seems like the antithesis of our third goal. If we commun-
|
||
icate the data through calling sequences, then the calling sequences will be
|
||
longer. One recommendation is the use of internal subroutines without para-
|
||
meters to subdivide a large program into smaller pieces. This is still a
|
||
good idea. But if all the data needed by a subroutine is provided through
|
||
its calling sequence, then the subroutine can be made external. External
|
||
subroutines are much less likely to contribute to errors than internal sub-
|
||
routines that share data. Furthermore, an internal subroutine that has no
|
||
parameters, but that uses ten or Ffteen chunks of data, is likely to be
|
||
quite complicated.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Software engineers use the term "coupling" to measure the degree to which
|
||
two subroutines are interrelated. Subroutines are (loosely coupled) if they
|
||
share only a few data elements, and then only as parameters in their calling
|
||
sequences. Subroutines that have long calling sequences or share data with
|
||
other subroutines outside the calling sequences are said to be "tightly -
|
||
coupled". Loose coupling is generally better inasmuch as changes made to
|
||
one subroutine are then less likely to require changes to other subroutines.
|
||
As with cohesion, coupling is an important matter in rating a particular
|
||
design, but a more detailed discussion is beyond the scope of this text.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
LIMIT USE OF FLAGS
|
||
|
||
FLAGS are signals that one subroutine sends to another. The first subroutine
|
||
decides something or other. It then sets a flag so that a different sub-
|
||
routine can know what the first subroutine decided. In BASIC flags are
|
||
usually variables that are set to either O or 1. For example, setting the
|
||
variable ERROR to O may mean that no errors have occurred, whereas setting
|
||
error to 1 may mean that one or more errors have occurred.
|
||
|
||
Programs that contain many flags are extremely difficult to write and to
|
||
test. And it is very difficult to make sure they are free from error.
|
||
Sometimes it is hard to avoid the use of FLAGS. Examples are subroutines
|
||
that test for errors. If these subroutines occur at a lower level, they
|
||
must communicate their results (errors versus no errors) back to the higher
|
||
level through a FLAG. Another occurs when a lower-level subroutine is
|
||
assigned the job of reading information from a file. When the end of the
|
||
file is reached, this subroutine must use a flag (or its equivalent) to
|
||
inform the higher-level routines.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
MAKE DESIGN HIERACHICAL
|
||
|
||
The structure chart of a large program should usually look like an upside
|
||
down tree. That is, there is one box at the top (the main program) that
|
||
calls several subroutines at the second level. The second-level subroutines
|
||
often call more subroutines at the third level, and so on.
|
||
A good design idea is to have the high-level subroutines deal in high-
|
||
level concepts, like the top executives in a company. The often messy
|
||
details should be left to the lower-level subroutines. In this way it is
|
||
more likely that you will be able to separate the "forest from the trees",
|
||
to separate the general concepts from the specific details.
|
||
|
||
|
||
|
||
TO BE CONTINUED
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
|
||
|
||
Another file downloaded from: NIRVANAnet(tm)
|
||
|
||
& the Temple of the Screaming Electron Jeff Hunter 510-935-5845
|
||
Rat Head Ratsnatcher 510-524-3649
|
||
Burn This Flag Zardoz 408-363-9766
|
||
realitycheck Poindexter Fortran 415-567-7043
|
||
Lies Unlimited Mick Freen 415-583-4102
|
||
|
||
Specializing in conversations, obscure information, high explosives,
|
||
arcane knowledge, political extremism, diversive sexuality,
|
||
insane speculation, and wild rumours. ALL-TEXT BBS SYSTEMS.
|
||
|
||
Full access for first-time callers. We don't want to know who you are,
|
||
where you live, or what your phone number is. We are not Big Brother.
|
||
|
||
"Raw Data for Raw Nerves"
|
||
|
||
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
|