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

十篇国外的重要资料

<P><STRONG>Module 3: Circular Shifter. </STRONG>The principal functions =
provided=20
by this module are analogs of functions provided in module 1. The module =
creates=20
the impression that we have created a line holder containing not all of =
the=20
lines but all of the circular shifts of the lines. Thus the function =
call=20
<I>CSCHAR(I,w,c)</I> provides the value representing the cth character =
in the=20
wth word of the Ith circular shift. It is specified that (1) if =
<EM>i</EM> &lt;=20
<EM>j</EM> then the shifts of line <EM>i</EM> precede the shifts of line =

<EM>j</EM>, and (2) for each line the first shift is the original line, =
the=20
second shift is obtained by making a one-word rotation to the first =
shift, etc.=20
A function <I>CSSETUP</I> is provided which must be called before the =
other=20
functions have their specified values. For a more precise specification =
of such=20
a module see [8].</P>
<P><STRONG>Module 4: Alphabetizer.</STRONG> This module consists =
principally of=20
two functions. One, <I>ALPH, </I>must be called before the other will =
have a=20
defined value. The second, <I>ITH, </I>will serve as an index. <I>ITH(i) =

</I>will give the index of the circular shift which comes ith in the=20
alphabetical ordering. Formal definitions of these functions are given =
[8].</P>
<P><STRONG>Module 5: Output. </STRONG>This module will give the desired =
printing=20
of set of lines or circular shifts.</P>
<P><STRONG>Module 6: Master Control.</STRONG> Similar in function to the =

modularization above.</P>
<H4>Comparison of the Two Modularizations</H4>
<P><STRONG>General.</STRONG> Both schemes will work. The first is quite=20
conventional; the second has been used successfully in a class project =
[7]. Both=20
will reduce the programming to the relatively independent programming of =
a=20
number of small, manageable, programs.</P>
<P>Note first that the two decompositions may share all data =
representations and=20
access methods. Our discussion is about two different ways of cutting up =
what=20
<I>may </I>be the same object. A system built according to decomposition =
I could=20
conceivably be identical <I>after assembly </I>to one built according to =

decomposition 2. The differences between the two alternatives are in the =
way=20
that they are divided into the work assignments, and the interfaces =
between=20
modules. The algorithms used in both cases <I>might </I>be identical. =
The=20
systems are substantially different even if identical in the runnable=20
representation. This is possible because the runnable representation =
need only=20
be used for running; other representations are used for changing, =
documenting,=20
understanding, etc. The two systems will not be identical in those other =

representations.</P>
<P><STRONG>Changeability. </STRONG>There are a number of design =
decisions which=20
are questionable and likely to change under many circumstances. This is =
a=20
partial list.</P>
<P>1. Input format.</P>
<P>2. The decision to have all lines stored in core. For large jobs it =
may prove=20
inconvenient or impractical to keep all of the lines in core at any one=20
time.</P>
<P>3. The decision to pack the characters four to a word. In cases where =
we are=20
working with small amounts of data it may prove undesirable to pack the=20
characters; time will be saved by a character per word layout. In other =
cases we=20
may pack, but in different formats.</P>
<P>4. The decision to make an index for the circular shifts rather that =
actually=20
store them as such. Again, for a small index or a large core, writing =
them out=20
may be the preferable approach. Alternatively, we may choose to prepare =
nothing=20
during <I>CSSETUP </I>All computation could be done during the calls on =
the=20
other functions such as <I>CSCHAR.</I></P>
<P>5. The decision to alphabetize the list once, rather than either (a) =
search=20
for each item when needed, or (b) partially alphabetize as is done in =
Hoare's=20
FIND [2]. In a number of circumstances it would be advantageous to =
distribute=20
the computation involved in alphabetization over the time required to =
produce=20
the index.</P>
<P>By looking at these changes we can see the differences between the =
two=20
modularizations. The first change is confined to one module in both=20
decompositions. For the first decomposition the second change would =
result in=20
changes in every module! The same is true of the third change. In the =
first=20
decomposition the format of the line storage in core must be used by all =
of the=20
programs. In the second decomposition the story is entirely different. =
Knowledge=20
of the exact way that the lines are stored is entirely hidden from all =
but=20
module 1. Any change in the manner of storage can be confined to that=20
module!</P>
<P>In some versions of this system there was an additional module in the =

decomposition. A symbol table module (as specified in [3]) was used =
within the=20
line storage module. This fact was completely invisible to the rest of =
the=20
system.</P>
<P>The fourth change is confined to the circular shift module in the =
second=20
decomposition, but in the first decomposition the alphabetizer and the =
output=20
routines will also know of the change.</P>
<P>The fifth change will also prove difficult in the first =
decomposition. The=20
output module will expect the index to have been completed before it =
began. The=20
alphabetizer module in the second decomposition was designed so that a =
user=20
could not detect when the alphabetization was actually done. No other =
module=20
need be changed.=20
<P><B>Independent Development. </B>In the first modularization the =
interfaces=20
between the modules are the fairly complex formats and table =
organizations=20
described above. These represent design decisions which cannot be taken =
lightly.=20
The table structure and organization are essential to the efficiency of =
the=20
various modules and must be designed carefully. The development of those =
formats=20
will be a major part of the module development and that part must be a =
joint=20
effort among the several development groups. In the second =
modularization the=20
interfaces are more abstract; they consist primarily in the function =
names and=20
the numbers and types of the parameters. These are relatively simple =
decisions=20
and the independent development of modules should begin much =
earlier.</P>
<P><B>Comprehensibility. </B>To understand the output module in the =
first=20
modularization, it will be necessary to understand something of the=20
alphabetizer, the circular shifter, and the input module. There will be =
aspects=20
of the tables used by output which will only make sense because of the =
way that=20
the other modules work. There will be constraints on the structure of =
the tables=20
due to the algorithms used in the other modules. The system will only be =

comprehensible as a whole. It is my subjective judgment that this is not =
true in=20
the second modularization.</P>
<H3>The Criteria</H3>
<P>Many readers will now see what criteria were used in each =
decomposition. In=20
the first decomposition the criterion used was to make each major step =
in the=20
processing a module. One might say that to get the first decomposition =
one makes=20
a flowchart. This is the most common approach to decomposition or=20
modularization. It is an outgrowth of all programmer training which =
teaches us=20
that we should begin with a rough flowchart and move from there to a =
detailed=20
implementation. The flowchart was a useful abstraction for systems with =
on the=20
order of 5,000-10,000 instructions, but as we move beyond that it does =
not=20
appear to be sufficient; something additional is needed.</P>
<P>The second decomposition was made using "information hiding" [41 as a =

criterion. The modules no longer correspond to steps in the processing. =
The line=20
storage module, for example, is used in almost every action by the =
system.=20
Alphabetization may or may not correspond to a phase in the processing =
according=20
to the method used. Similarly, circular shift might, in some =
circumstances, not=20
make any table at all but calculate each character as demanded. Every =
module in=20
the second decomposition is characterized by its knowledge of a design =
decision=20
which it hides from all others. Its interface or definition was chosen =
to reveal=20
as little as possible about its inner workings.=20
<H3>Improvement in Circular Shift Module</H3>
<P>To illustrate the impact of such a criterion let us take a closer =
look at the=20
design of the circular shift module from the second decomposition. =
Hindsight now=20
suggests that this definition reveals more information than necessary. =
While we=20
carefully hid the method of storing or calculating the list of circular =
shifts,=20
we specified an order to that list. Programs could be effectively =
written if we=20
specified only ( I ) that the lines indicated in circular shift's =
current=20
definition will all exist in the table, (2) that no one of them would be =

included twice, and (3) that an additional function existed which would =
allow us=20
to identify the original line given the shift. By prescribing the order =
for the=20
shifts we have given more information than necessary and so =
unnecessarily=20
restricted the class of systems that we can build without changing the=20
definitions. For example, we have not allowed for a system in which the =
circular=20
shifts were produced in alphabetical order, <I>ALPH is </I>empty, and =
<I>ITH=20
</I>simply returns its argument as a value. Our failure to do this in=20
constructing the systems with the second decomposition must clearly be=20
classified as a design error.</P>
<P>In addition to the general criteria that each module hides some =
design=20
decision from the rest of the system, we can mention some specific =
examples of=20
decompositions which seem advisable.</P>
<P>1. A <I>data structure, </I>its internal linkings, <I>accessing =
procedures=20
and modifying procedures </I>are part of a single module. They are not =
shared by=20
many modules as is conventionally done. This notion is perhaps just an=20
elaboration of the assumptions behind the papers of Balzer [9] and Mealy =
[10].=20
Design with this in mind is clearly behind the design of BLISS [11].</P>
<P>2. <I>The sequence of instructions necessary to call a given routine =
and the=20