The software world of 1972 was struggling with growing pains. The f...
This textbook, "Designing Systems Programs”, focused on methods for...
Here is a flowchart representation of this modularization: 
![](htt...
### KWIC (Key Word In Context) A KWIC ("Key Word In Context") in...
Just listing out modules isn’t enough to start developing the syste...
Here is a flowchart representation of this modularization: 
![](htt...
Hoare's FIND algorithm is a selection algorithm that finds the kth ...
Parnas describes how the circular shift module in the second modula...
Balzer [9], Mealy [10], and Wulf et al. [11] represent significant ...
Imagine you need to call a function in assembly language. Unlike mo...
Programming R. Morris
Techniques Editor
On the Criteria To Be
Used in Decomposing
Systems into Modules
D.L. Parnas
Carnegie-Mellon University
This paper discusses modularization as a mechanism
for improving the flexibility and comprehensibility of a
system while allowing the shortening of its development
time. The effectiveness of a "modularization" is
dependent upon the criteria used in dividing the system
into modules. A system design problem is presented and
both a conventional and unconventional decomposition
are described. It is shown that the unconventional
decompositions have distinct advantages for the goals
outlined. The criteria used in arriving at the decom-
positions are discussed. The unconventional decomposi-
tion, if implemented with the conventional assumption
that a module consists of one or more subroutines, will
be less efficient in most cases. An alternative approach
to implementation which does not have this effect is
sketched.
Key Words and Phrases: software, modules,
modularity, software engineering, KWIC index,
software design
CR Categories: 4.0
Introduction
A lucid statement of the philosophy of modular
programming can be found in a 1970 textbook on the
design of system programs by Gouthier and Pont [1,
¶I0.23], which we quote below: 1
A well-defined segmentation of the project effort ensures
system modularity. Each task forms a separate, distinct program
module. At implementation time each module and its inputs and
outputs are well-defined, there is no confusion in the intended
interface with other system modules. At checkout time the in-
tegrity of the module is tested independently; there are few sche-
duling problems in synchronizing the completion of several tasks
before checkout can begin. Finally, the system is maintained in
modular fashion; system errors and deficiencies can be traced to
specific system modules, thus limiting the scope of detailed error
searching.
Usually nothing is said about the criteria to be used
in dividing the system into modules. This paper will
discuss that issue and, by means of examples, suggest
some criteria which can be used in decomposing a
system into modules.
Copyright @ 1972, Association for Computing Machinery, Inc.
General permission to republish, but not for profit, all or part
of this material is granted, provided that reference is made to this
publication, to its date of issue, and to the fact that reprinting
privileges were granted by permission of the Association for Com-
puting Machinery.
Author's address: Department of Computer Science, Carnegie-
Mellon University, Pittsburgh, PA 15213.
1053
A Brief Status Report
The major advancement in the area of modular
programming has been the development of coding
techniques and assemblers which (l) allow one module
to be written with little knowledge of the code in
another module, and (2) allow modules to be reas-
sembled and replaced without reassembly of the whole
system. This facility is extremely valuable for the
production of large pieces of code, but the systems most
often used as examples of problem systems are highly-
modularized programs and make use of the techniques
mentioned above.
1 Reprinted by permission of Prentice-Hall, Englewood
Cliffs, N.J.
Communications December 1972
of Volume 15
the ACM Number 12
Expected Benefits of Modular Programming
The benefits expected of modular programming are:
(1) managerial--development time should be shortened
because separate groups would work on each module
with little need for communication: (2) product flexi-
bility-it should be possible to make drastic changes to
one module without a need to change others; (3) com-
prehensibility-it should be possible to study the
system one module at a time. The whole system can
therefore be better designed because it is better under-
stood.
What Is Modularization?
Below are several partial system descriptions called
modularizations. In this context "module" is considered
to be a responsibility assignment rather than a sub-
program. The modularizations include the design deci-
sions which must be made before the work on inde-
pendent modules can begin. Quite different decisions
are included for each alternative, but in all cases the
intention is to describe all "system level" decisions (i.e.
decisions which affect more than one module).
Example System 1: A KWIC Index Production System
The following description of a KWIC index will
suffice for this paper. The KWIC index system accepts an
ordered set of lines, each line is an ordered set 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 the end of the line. The
KWXC index system outputs a listing of all circular shifts
of all lines in alphabetical order.
This is a small system. Except under extreme cir-
cumstances (huge data base, no supporting software),
such a system could be produced by a good programmer
within a week or two. Consequently, none of the
difficulties motivating modular programming are im-
portant for this system. Because it is impractical to
treat a large system thoroughly, we must go through
the exercise of treating this problem as if it were a large
project. We give one modularization which typifies
current approaches, and another which has been used
successfully in undergraduate class projects.
Modularlzation 1
We see the following modules:
Module 1: Input. This module reads the data lines
from the input medium and stores them in core for
processing by the remaining modules. The characters
are packed four to a word, and an otherwise unused
character is used to indicate the end of a word. An index
is kept to show the starting address of each line.
Module 2: Circular Shift. This module is called after
the input module has completed its work. It prepares an
index which gives the address of the first character of
each circular shift, and the original index of the line in
the array made up by module 1. It leaves its output in
core with words in pairs (original line number, starting
address).
Module 3: Alphabetizing. This module takes as
input the arrays produced by modules 1 and 2. It
produces an array in the same format as that produced
by module 2. In this case, however, the circular shifts
are listed in another order (alphabetically).
Module 4: Output. Using the arrays produced by
module 3 and module 1, this module produces a nicely
formatted output listing all of the circular shifts. In a
sophisticated system the actual start of each line will
be marked, pointers to further information may be
inserted, and the start of the circular shift may actually
not be the first word in the line, etc.
Module 5: Master Control. This module does little
more than control the sequencing among the other four
modules. It may also handle error messages, space
allocation, etc.
It should be clear that the above does not constitute
a definitive document. Much more information would
have to be supplied before work could start. The defin-
ing documents would include a number of pictures
showing core formats, pointer conventions, calling
conventions, etc. All of the interfaces between the four
modules must be specified before work could begin.
This is a modularization in the sense meant by all
proponents of modular programming. The system is
divided into a number of modules with well-defined
interfaces; each one is small enough and simple enough
to be thoroughly understood and well programmed.
Experiments on a small scale indicate that this is
approximately the decomposition which would be
proposed by most programmers for the task specified.
Modularization 2
We see the following modules:
Module 1: Line Storage. This module consists of a
number of functions or subroutines which provide the
means by which the user of the module may call on it.
The function call CHAR(r,w,c) will have as value an
integer representing the cth character in the rth line,
wth word. A call such as SETCHAR(r,w,c,d) will cause
the cth character in the wth word of the rth line to be
the character represented by d (i.e. CHAR(r,w,c) = d).
WORDS(r) returns as value the number of words in
1054
Communications December 1972
of Volume 15
the ACM Number 12