on the criteria to be used in decomposing systems into modules.mht

十篇国外的重要资料

routine itself are part of the same module. </I>This rule was not =
relevant in=20
the Fortran systems used for experimentation but it becomes essential =
for=20
systems constructed in an assembly language. There are no perfect =
general=20
calling sequences for real machines and consequently they tend to vary =
as we=20
continue our search for the ideal sequence. By assigning responsibility =
for=20
generating the call to the person responsible for the routine we make =
such=20
improvements easier and also make it more feasible to have several =
distinct=20
sequences in the same software structure.</P>
<P>3. The <I>formats of control blocks </I>used in queues in operating =
systems=20
and similar programs <I>must be hidden </I>within a "control block =
module." It=20
is conventional to make such formats the interfaces between various =
modules.=20
Because design evolution forces frequent changes on control block =
formats such a=20
decision often proves extremely costly.</P>
<P>4. <I>Character codes, alphabetic orderings and similar data should =
be hidden=20
</I>in a module for greatest flexibility. 5. The sequence in which =
certain items=20
<TT>will </TT>be processed should (as far as practical) be hidden within =
a=20
single module. Various changes ranging from equipment additions to=20
unavailability of certain resources in an operating system make =
sequencing=20
extremely variable.=20
<H3>Efficiency and Implementation</H3>
<P>If we are not careful the second decomposition will prove to be much =
less=20
efficient than the first. If each of the functions is actually =
implemented as a=20
procedure with an elaborate calling sequence there will be a great deal =
of such=20
calling due to the repeated switching between modules. The first =
decomposition=20
will not suffer from this problem because there is relatively infrequent =

transfer of control between modules.</P>
<P>To save the procedure call overhead, yet gain the advantages that we =
have=20
seen above, we must implement these modules in an unusual way. In many =
cases the=20
routines will be best inserted into the code by an assembler; in other =
cases,=20
highly specialized and efficient transfers would be inserted. To =
successfully=20
and efficiently make use of the second type of decomposition will =
require a tool=20
by means of which programs may be written as if the functions were =
subroutines,=20
but assembled by whatever implementation is appropriate. If such a =
technique is=20
used, the separation between modules may not be clear in the final code. =
For=20
that reason additional program modification features would also be =
useful. In=20
other words, the several representations of the program (which were =
mentioned=20
earlier) must be maintained in the machine together with a program =
performing=20
mapping between them.</P>
<H3>A Decomposition Common to a Compiler and Interpretor for the Same=20
Language</H3>
<P>In an earlier attempt to apply these decomposition rules to a design =
project=20
we constructed a translator for a Markov algorithm expressed in the =
notation=20
described in [6]. Although it was not our intention to investigate the =
relation=20
between compiling and interpretive translators of a language, we =
discovered that=20
our decomposition was valid for a pure compiler and several varieties of =

interpreters for the language. Although there would be deep and =
substantial=20
differences in the final running representations of each type of =
compiler, we=20
found that the decisions implicit in the early decomposition held for =
all.</P>
<P>This would not have been true if we had divided responsibilities =
along the=20
classical lines for either a compiler or interpretor (e.g. syntax =
recognizer,=20
code generator, run time routines for a compiler). Instead the =
decomposition was=20
based upon the hiding of various decisions as in the example above. Thus =

register representation, search algorithm, rule interpretation etc. were =
modules=20
and these problems existed in both compiling and interpretive =
translators. Not=20
only was the decomposition valid in all cases, but many of the routines =
could be=20
used with only slight changes in any sort of translator.</P>
<P>This example provides additional support for the statement that the =
order in=20
time in which processing is expected to take place should not be used in =
making=20
the decomposition into modules. It further provides evidence that a =
careful job=20
of decomposition can result in considerable carryover of work from one =
project=20
to another.</P>
<P>A more detailed discussion of this example was contained in [8].</P>
<H3>Hierarchical Structure</H3>
<P>We can find a program hierarchy in the sense illustrated by Dijkstra =
[5] in=20
the system defined according to decomposition 2. If a symbol table =
exists, it=20
functions without any of the other modules, hence it is on level 1. Line =
storage=20
is on level I if no symbol table is used or it is on level 2 otherwise. =
Input=20
and Circular Shifter require line storage for their functioning. Output =
and=20
Alphabetizer will require Circular Shifter, but since Circular Shifter =
and line=20
holder are in some sense compatible, it would be easy to build a =
parameterized=20
version of those routines which could be used to alphabetize or print =
out either=20
the original lines or the circular shifts. In the first usage they would =
not=20
require Circular Shifter; in the second they would. In other words, our =
design=20
has allowed us to have a single representation for programs which may =
run at=20
either of two levels in the hierarchy.</P>
<P>In discussions of system structure it is easy to confuse the benefits =
of a=20
good decomposition with those of a hierarchical structure. We have a=20
hierarchical structure if a certain relation may be defined between the =
modules=20
or programs and that relation is a partial ordering. The relation we are =

concerned with is "uses" or "depends upon." It is better to use a =
relation=20
between programs since in many cases one module depends upon only part =
of=20
another module (e.g. Circular Shifter depends only on the output parts =
of the=20
line holder and not on the correct working of <I>SKI WORD). </I>It is=20
conceivable that we could obtain the benefits that we have been =
discussing=20
without such a partial ordering, e.g. if all the modules were on the =
same level.=20
The partial ordering gives us two additional benefits. First, parts of =
the=20
system are benefited (simplified) because they use the services of lower =
levels.=20
Second, we are able to cut off the upper levels and still have a usable =
and=20
useful product. For example, the symbol table can be used in other =
applications;=20
the line holder could be the basis of a question answering system. The =
existence=20
of the hierarchical structure assures us that we can "prune" off the =
upper=20
levels of the tree and start a new tree on the old trunk. If we had =
designed a=20
system in which the "low level" modules made some use of the "high =
level"=20
modules, we would not have the hierarchy, we would find it much harder =
to remove=20
portions of the system, and "level" would not have much meaning in the=20
system.</P>
<P>Since it is conceivable that we could have a system with the type of=20
decomposition shown in version I (important design decisions in the =
interfaces)=20
but retaining a hierarchical structure, we must conclude that =
hierarchical=20
structure and "clean" decomposition are two desirable but <I>independent =

</I>properties of a system structure.</P>
<H3>Conclusion</H3>
<P>We have tried to demonstrate by these examples that it is almost =
always=20
incorrect to begin the decomposition of a system into modules on the =
basis of a=20
flowchart. We propose instead that one begins with a list of difficult =
design=20
decisions or design decisions which are likely to change. Each module is =
then=20
designed to hide such a decision from the others. Since, in most cases, =
design=20
decisions transcend time of execution, modules will not correspond to =
steps in=20
the processing. To achieve an efficient implementation we must abandon =
the=20
assumption that a module is one or more subroutines, and instead allow=20
subroutines and programs to be assembled collections of code from =
various=20
modules.</P>
<P>Received August 1971; revised November 1971<BR>
<H3>References</H3>
<P>I. Gauthier, Richard, and Pont, Stephen. <I>Designing Systems =
Programs, (C),=20
</I>Prentice-Hall, Englewood Cliffs, N.J., 1970.</P>
<P>2. Hoare, C. A. R. Proof of a program, FIND. <I>Comm. ACM 14 </I>1 =
(Jan.=20
1971), 39-45.</P>
<P>3. Parnas, D. L. A technique for software module specification with =
examples.=20
<I>Comm. ACM 15, </I>5 (May, 1972), 330-336.</P>
<P>4. Parnas, D. L. Information distribution aspects of design =
methodology.=20
Tech. Rept., Depart. Computer Science, Carnegie Mellon U., Pittsburgh, =
Pa.,=20
1971. Also presented at the IFIP</P>Congress 1971, Ljubljana, =
Yugoslavia.
<P></P>
<P>5. Dijkstra, E. W. The structure of "THE"-multiprogramming system. =
<I>Comm.=20
ACM 11, </I>5 (May 1968), 341-346.</P>
<P>6. Galler, B., and Perlis, A. J. <I>A View of </I>Programming =
<I>Languages,=20
</I>Addison-Wesley, Reading, Mass., 1970.</P>
<P>7. Parnas, D. L. A course on software engineering. Proc. SIGCSE =
Technical=20
Symposium, Mar. 1972.</P>
<P>8. Parnas, D. L. On the criteria to be used in decomposing systems =
into=20
modules. Tech. Rept., Depart.. Computer Science, Carnegie-Mellon U., =
Pittsburgh,=20
Pa., 1971.</P>
<P>9. Balzer, R. M. Dataless programming. Proc. AFIPS 1967 FJCC, Vol. =
31, AFIPS=20
Press, Montvale, N.J., pp. 535-544.</P>
<P>10. Mealy, G. H. Another look at data. Proc. AFIPS 1967 FJCC Vol. 31, =
AFIPS=20
Press, Montvale, N.J., pp. 525-534.</P>
<P>11. Wulf, W. A., Russell, D. B., and Habermann, A. N. BLISS A =
language for=20
systems programming <I>Comm. ACM 14, </I>12 (Dec. 1971), 780-790.</P>
<HR>
<EM><A href=3D"http://sunnyday.mit.edu/~clore/">MAC</A></EM> / =
1996-May-4=20
</BODY></HTML>