David Parnas - Information Distribution Aspects of Design Methodology PDF
David Parnas - Information Distribution Aspects of Design Methodology PDF
David Parnas - Information Distribution Aspects of Design Methodology PDF
The copyright law of the United States (title 17, U.S. Code) governs the making
of photocopies or other reproductions of copyrighted material. Any copying of this
document without permission of its author may be prohibited by law.
INFORMATION DISTRIBUTION ASPECTS OF
DESIGN METHODOLOGY
by
D. L. Parnas
February, 1971
ACKNOWLEDGEMENT
remote study. Although the problems discussed in this paper are apparently
the situation have provided me with valuable insight. Thanks are due to
D. L. Parnas
Department of Computer Science
Carnegie-Mellon University
Pittsburgh, Pennsylvania
ABSTRACT
information "broadcasting 11
is harmful, that it is helpful if most system
IFIP CLASSIFICATION: 3
publication elsewhere.
INFORMATION DISTRIBUTION ASPECTS OF DESIGN METHODOLOGY
D. L. Parnas
Department of Computer Science
Carnegie-MelIon University
Pittsburgh, Pennsylvania
INTRODUCTION
system design affect strongly the quality of the final product; and (2)
can be distinguished:
in information about the system which can be used in making later decisions.
those working on the system and to deal with its organization in documenta-
tion. To prepare for this discussion we deal first with (1) the concept
of system structure, (2) constraints on the order of decisions, and (3) some
STRUCTURE DEFINED
some connections between the modules. Any given systesm admits many such
' W d u l e " does not allow a precise definition parallel to that of "sub-
system dependent but also dependent upon the particular description under
discussion.
and shared data for software, wires or other physical connections for hard-
other. In most systems we find that these connections are much more ex-
tensive than the calling sequences and control block formats usually shown
the things we expect a module to accomplish from the things which we assume
other modules will guarantee. Those statements are the connections between
the module being examined and the rest of the system. The proof process
tion of the connected modules. In the extreme case, where one module's
"What changes can be made to one module without involving change to other
modules?" We may make only those changes which do not violate the assump-
tions made by other modules about the module being changed. In other
still "fit." Here, too, we have a strong argument for making the connec-
have been eliminated can be part of the rationale for subsequent decisions.
If the information is used, the order of decision making (in time) affects
1. Obtaining 'good 1
external characteristics.
All systems have characteristics which are not pleasing to the users.
Usually they were not determined by explicit deliberations; they were the
To consistently avoid such errors we can make the decisions about external
2. Reducing the time interval between initiation and completion of the projec
project significantly only after the project has been divided into sub-
projects in such a way that separate groups can work with little interaction
-5-
make the split early and get on with it" encourages a splitting along
f,
Time pressures encourage groups to make the split before the externals
of the product. Haste also makes poor internal structure more likely.
are related to the assumptions which each of the modules makes about its
the previous decisions will hold, the most difficult decisions to change
are usually the earliest. The last piece of code inserted may be changed
easily, but a piece of code inserted several months earlier may have
"wormed 11
itself into the program and become difficult to extract. These
considerations suggest that the early decisions should be those which are
The remaining facts must be used eventually, but the possibility of change
commands are very frequently changed, the "outside-in" approach may make
made early on this basis are not usually those which allow the project
which do not use all the available information about a system (i.e., the
DOCUMENTATION SYSTEMS
For any complex system there must be documentation about the system
for use by the human beings who must complete it. Programs and wiring
diagrams do completely define the algorithm which they will execute, but
quently there are always papers which attempt to answer the questions most
complete (i.e., equivalent to the code) for software, thus certain questions
by persons not closely involved with the module being documented. Because
set of concepts and terms, the documents which they write are difficult for
outsiders to read.
-7-
resulting system?
assumptions are violated, the document organization fits poorly and the
In most operating systems there exists a module which handles all job
control statements from the time they are read in until the job is completed.
the T.H.E. system in which there is no such module because most of the
processing is handled in modules which are also used for other purposes.
system,
paper:
l!
A good programmer makes use of the usable information given him. 11
The good programmer will try to use his machine well. He is actually
programming for a "virtual machine" defined by the hardware and his knowledge
of the other software on the machine. His training and his nature lead
Sometimes the uses are obvious. The programmer makes use of a sub-
for some other piece of code. Sometimes these uses are so marginal as to
Sometimes the uses are less obvious. For example, a programmer may
that because of an error in the sine routine the erroneous value will
of fellow who writes terribly clever programs which cause trouble later on.
both situations the programmer has little opportunity to make use of in-
While a few refrain from using information because they know it will
cause trouble, most refrain because they are not clever enough to notice
to use facts which should be used. Poor programs result. Since even a
two bytes in a control block can be simultaneously set with one instruction
because they are adjacent and in the same word) we still have no control
of the structure.
we should allow the designers, those who specify the structure, to control
on the assumption that information would be used shortly after the cor-
from each group. For example, we have noted a conflict between the desire
system for which the external interface is easily changed. We can avoid
on the remaining work, but hiding the details that we think likely to
Reflection will show that such a policy expects a great deal from
EXAMPLES
sharply restricted.
areas of storage called control blocks. These are used for passing informa-
tion between modules and are considered to be the interfaces. For this
reason formats are usually specified early in the project and distributed
to all who are working on the project. The formats are changed many times
during the project. Few programmers on any project need to know such
formats. They need a means for referring to a specific item, but not more.
They need not even know which information is grouped into one control block.
-12-
2. Memory Maps
(1) describing the main modules and (2) showing how the core storage is
divided among those main modules. Soon there is a complete map of the
designers show the borders of allocated areas as symbolic rather than ab-
frightening if someone developed code that would not work if the map were
changed. Such maps are almost invariably changed because something which
was fixed becomes variable or vice versa. The information is only needed
into the system, the distinction between resident and non-resident items
tihe allocation of modules and data among those storage types should not
3. Calling Sequences
ized, made more efficient, etc. Each time we face a decision. Either
modules all over the system are altered or the new sequence is added to
tool which allows him to postpone decisions about register allocation for
4. JCL Formats
the so called Job Control Language, the means by which the user describes
a JCL implies assumptions about the way that the system will be used which
which JCL format information has been used so much that reasonable changes
are beyond the scope of the usual organization. Often changes require
knowledge about the JCL. The only people who need to know the format
are those who are writing the syntax analyzer for the language.
-14-
into code but stored in tables associated with each job. However, it is
usual that all programmers are given knowledge sufficient to allow them
to find and use the table. For example, many modules will send messages
and reinterpret or suppress them for a special class of users, the job is
6. Character Codes
characters and integers was so widely used that a second version of the
the new character code to the old one and back again*
the knowledge can be closely restricted if: the designers pay attention
to the problem. Certainly the decision to use or not to use the informa-
CONCLUSION
designers who are able to define or specify modules in a way which provides
exactly the information that they want the programmers to use. Until we
can completely staff a project with men who have the intellectual capacity
and training to make that decision for themselves, some must make the
APPENDIX
INTRODUCTION
Algorithm machine. Assume further that the decision has been made that
spite of the fact that almost all actions done by the system will involve
module which should be available to its users. They are intended to provide
all the information necessary to use the module, i.e., to manipulate the
their initial values if they are functions, to specify the type of their
to the effect of a call on the procedures on the values of the other func-
tions in the package. This is done by indicating the new value of any
shown unquoted. The actions which take place in the event of errors
call occur, (1) no values will have been changed, and (2) upon a return
from the procedure called, the attempt to perform the routine specified
DEFINITIONS
if k = 1+1, J
if k > 1+1, GETCHA(K-l)
1 1
PROCEDURE: ALTER(I, J)
possible values: none
parameters: I, J must be integers
effect:
if I < 0 V I > 'LENGTH' V J < 0 V J > 255 then a subroutine call
to a user written routine ALTERERR is performed.
GETCHA(K) = if K / I then 'GETCHA(K)'
if K = I then J
-19-
DISCUSSION
showing that a value is defined for each function for every possible
calls of error routines exists, but this would be an error in usage not
in definition.
the definitions by showing first its sufficiency for use (i.e., complete-
The usual form of documentation would be (1) much more wordy, (2) more
The definitions are obscure now to a reader unfamiliar with the reg-
official status.
-20-
References
10. Wulf, jet aL, "BLISS Users Manual," publication of the Carnegie-Mellon
University, Pittsburgh, Pa., USA.
11. Waite, V. M., "The Mobile Programming System: STAGE 2," CACM 13,7
(July, 1970), pp. 411-421.
12. Parnas, David L., "On the Use of Transition Diagrams in the Design
of A User Interface for an Interactive Computer System^" Proc. 1969
National ACM Conference, pp. 379-386.
14. Balzer, Robert M., "Studies Concerning Minimal Time Solutions to the
Firing Squad Synchronization Problem" PH.D. thesis, Carnegie Institute
of Technology, 1966.
Scientific Interim
5 AUTHOR(S) (First name, middle initial, last name)'
D. L. Parnas
16 R E P O R T D A T E
7a. TOTAL NO. OF PAGES 7b. NO. OF REFS
February 1971
I ««• C O N T R A C T O R G R A N T N O .
24 17
9a. ORIGINATOR'S REPORT NUMBER(S)
F44620-70-C-0107
b. P R O J E C T NO .
A0827-5
61101D
» . M
D I S T R I B U T I O N S T A T E M E N T
This document has been approved for public release and sale-
its distribution is unlimited.
II S U P P L E M E N T A R Y N O T E S
12. SPONSORING MILITARY ACTIVITY ~~ "
DD 1
FORM
N O V F.* 1473
Security Classification
Security Classification