📄 on the criteria to be used in decomposing systems into modules.mht
字号:
From: <由 Microsoft Internet Explorer 5 保存>
Subject: On the Criteria To Be Used in Decomposing Systems into Modules
Date: Thu, 12 Mar 2009 14:09:35 +0800
MIME-Version: 1.0
Content-Type: text/html;
charset="gb2312"
Content-Transfer-Encoding: quoted-printable
Content-Location: http://sunnyday.mit.edu/16.355/parnas-criteria.html
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>On the Criteria To Be Used in Decomposing Systems =
into Modules</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<H1><IMG height=3D40 alt=3D"May 1996" src=3D"" width=3D480><BR><A=20
href=3D"http://sunnyday.mit.edu/turing/cgi-bin/htimage/classics/banner.ma=
p"><IMG=20
height=3D110 alt=3D"ACM, Classic of the Month" isMap src=3D"" =
width=3D480> </A></H1>
<H2>On the Criteria To Be Used in Decomposing Systems into =
Modules<BR><EM>D.L.=20
Parnas<BR>Carnegie-Mellon University</EM></H2>Reprinted from=20
<CITE>Communications of the ACM</CITE>, Vol. 15, No. 12, December 1972 =
pp. 1053=20
- 1058 Copyright © 1972, Association for Computing Machinery Inc.=20
<P>This is a digitized copy derived from an ACM copyrighted work. It is =
not=20
guaranteed to be an accurate copy of the author's original work.=20
<HR>
<STRONG>
<P>This paper discusses modularization as a mechanism for improving the=20
flexibility and comprehensibility of a system while allowing the =
shortening of=20
its development time. The effectiveness of a "modularization" is =
dependent upon=20
the criteria used in dividing the system into modules. A system design =
problem=20
is presented and both a conventional and unconventional decomposition =
are=20
described. It is shown that the unconventional decompositions have =
distinct=20
advantages for the goals outlined. The criteria used in arriving at the=20
decompositions are discussed. The unconventional decomposition, if =
implemented=20
with the conventional assumption that a module consists of one or more=20
subroutines, will be less efficient in most cases. An alternative =
approach to=20
implementation which does not have this effect is sketched.=20
<P>Key Words and Phrases: software, modules, modularity, software =
engineering,=20
KWIC index, software design=20
<P>CR Categories: 4.0 </STRONG>
<HR>
<H3>Introduction</H3>
<P>A lucid statement of the philosophy of modular programming can be =
found in a=20
1970 textbook on the design of system programs by Gouthier and Pont =
[1,10.23],=20
which we quote below:=20
<BLOCKQUOTE>A well-defined segmentation of the project effort ensures =
system=20
modularity. Each task forms a separate, distinct program module. At=20
implementation time each module and its inputs and outputs are =
well-defined,=20
there is no confusion in the intended interface with other system =
modules. At=20
checkout time the integrity of the module is tested independently; =
there are=20
few scheduling problems in synchronizing the completion of several =
tasks=20
before checkout can begin. Finally, the system is maintained in =
modular=20
fashion, system errors and deficiencies can be traced to specific =
system=20
modules, thus limiting the scope of detailed error searching. =
</BLOCKQUOTE>
<P></P>
<P>Usually nothing is said about the criteria to be used in dividing the =
system=20
into modules. This paper will discuss that issue and, by means of =
examples,=20
suggest some criteria which can be used in decomposing a system into =
modules.=20
</P>
<H3>A Brief Status Report</H3>
<P>The major advancement in the area of modular programming has been the =
development of coding techniques and assemblers which (1) allow one =
module to be=20
written with little knowledge of the code in another module, and (2) =
allow=20
modules to be reassembled and replaced without reassembly of the whole =
system.=20
This facility is extremely valuable for the production of large pieces =
of code,=20
but the systems most often used as examples of problem systems are =
highly=20
modularized programs and make use of the techniques mentioned above. =
</P>
<H3>Expected Benefits of Modular Programming</H3>
<P>The benefits expected of modular programming are: (1) =
managerial_development=20
time should be shortened because separate groups would work on each =
module with=20
little need for communication: (2) product flexibility_it should be =
possible to=20
make drastic changes to one module without a need to change others; (3)=20
comprehensibility_it should be possible to study the system one module =
at a=20
time. The whole system can therefore be better designed because it is =
better=20
understood.</P>
<H3>What Is Modularization?</H3>
<P>Below are several partial system descriptions called =
<I>modularizations.</I>=20
In this context "module" is considered to be a responsibility assignment =
rather=20
than a subprogram. The <I>modularizations</I> include the design =
decisions which=20
must be made <I>before </I>the work on independent modules can begin. =
Quite=20
different decisions are included for each alternative, but in all cases =
the=20
intention is to describe all "system level" decisions (i.e. decisions =
which=20
affect more than one module).</P>
<H3>Example System 1: A KWIC Index Production System</H3>
<P>The following description of a KWIC index will suffice for this =
paper. The=20
KWIC index system accepts an ordered set of lines, each line is an =
ordered set=20
of words, and each word is an ordered set of characters. Any line may be =
"circularly shifted" by repeatedly removing the first word and appending =
it at=20
the end of the line. The KWIC index system outputs a listing of all =
circular=20
shifts of all lines in alphabetical order.</P>
<P>This is a small system. Except under extreme circumstances (huge data =
base,=20
no supporting software), such a system could be produced by a good =
programmer=20
within a week or two. Consequently, none of the difficulties motivating =
modular=20
programming are important for this system. Because it is impractical to =
treat a=20
large system thoroughly, we must go through the exercise of treating =
this=20
problem as if it were a large project. We give one modularization which =
typifies=20
current approaches, and another which has been used successfully in=20
undergraduate class projects.</P>
<H4>Modularization 1</H4>
<P>We see the following modules:</P>
<P><B>Module 1: Input. </B>This module reads the data lines from the =
input=20
medium and stores them in core for processing by the remaining modules. =
The=20
characters are packed four to a word, and an otherwise unused character =
is used=20
to indicate the end of a word. An index is kept to show the starting =
address of=20
each line.</P>
<P><STRONG>Module 2: Circular Shift.</STRONG> This module is called =
after the=20
input module has completed its work. It prepares an index which gives =
the=20
address of the first character of each circular shift, and the original =
index of=20
the line in the array made up by module 1. It leaves its output in core =
with=20
words in pairs (original line number, starting address).</P>
<P><STRONG>Module 3: Alphabetizing.</STRONG> This module takes as input =
the=20
arrays produced by modules I and 2. It produces an array in the same =
format as=20
that produced by module 2. In this case, however, the circular shifts =
are listed=20
in another order (alphabetically).</P>
<P><STRONG>Module 4: Output.</STRONG> Using the arrays produced by =
module 3 and=20
module 1, this module produces a nicely formatted output listing all of =
the=20
circular shifts. In a sophisticated system the actual start of each line =
will be=20
marked, pointers to further information may be inserted, and the start =
of the=20
circular shift may actually not be the first word in the line, etc.</P>
<P><STRONG>Module 5: Master Control. </STRONG>This module does little =
more than=20
control the sequencing among the other four modules. It may also handle =
error=20
messages, space allocation, etc.</P>
<P>It should be clear that the above does not constitute a definitive =
document.=20
Much more information would have to be supplied before work could start. =
The=20
defining documents would include a number of pictures showing core =
formats,=20
pointer conventions, calling conventions, etc. All of the interfaces =
between the=20
four modules must be specified before work could begin.</P>
<P>This is a modularization in the sense meant by all proponents of =
modular=20
programming. The system is divided into a number of modules with =
well-defined=20
interfaces; each one is small enough and simple enough to be thoroughly=20
understood and well programmed. Experiments on a small scale indicate =
that this=20
is approximately the decomposition which would be proposed by most =
programmers=20
for the task specified.</P>
<H4>Modularization 2</H4>
<P>We see the following modules:</P>
<P><STRONG>Module 1: Line Storage. </STRONG>This module consists of a =
number of=20
functions or subroutines which provide the means by which the user of =
the module=20
may call on it. The function call <I>CHAR(r,w,c)</I> will have as value =
an=20
integer representing the cth character in the rth line, wth word. A call =
such as=20
<I>SETCHAR(rpv,c,d)</I> will cause the cth character in the wth word of =
the rth=20
line to be the character represented by d (i.e. <I>CHAR(r,w,c) =3D d).=20
WORDS(r)</I> returns as value the number of words in line <EM>r</EM>. =
There are=20
certain restrictions in the way that these routines may be called; if =
these=20
restrictions are violated the routines "trap" to an error-handling =
subroutine=20
which is to be provided by the users of the routine. Additional routines =
are=20
available which reveal to the caller the number of words in any line, =
the number=20
of lines currently stored, and the number of characters in any word. =
Functions=20
<I>DELINE</I> and <I>DELWRD</I> are provided to delete portions of lines =
which=20
have already been stored. A precise specification of a similar module =
has been=20
given in [3] and [8] and we will not repeat it here.=20
<P><STRONG>Module 2: INPUT.</STRONG> This module reads the original =
lines from=20
the input media and calls the line storage module to have them stored=20
internally.</P>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -