On the criteria to be used in decomposing systems into modules

• Authors: D. L. Parnas
• Venue: Classics in software engineering
• Year: 1979

D.L. Parnas has had an enormous impact on program design - - or "structured design," as most people now call it --- but his published work has been read by a surprisingly small number of EDP professionals. The following paper, which appeared in the December 1972 issue of Communications of the A CM, is included in this collection of structured programming classics because it is the source of many now-familiar concepts and phrases. It is the source for the phrase "information hiding," and is probably Parnas' best-known, if little-read, work. In this paper, Parnas attacked the whole mystique of modularization, asking questions that, for the most part, had been entirely ignored by the EDP profession: What is a module? What distinguishes a good module from a bad one? How do we go about modularizing a program? And he posed his argument at a time when "modular programming" still was very much a buzzword. Most of his argument is based on one example: the KWlC index system. Two different modularizations are presented in this paper, and it becomes apparent that one of them is substantially superior to the other --- superior, that is, if one defines superiority in terms of ease of maintenance. If you're like me, you probably will become puzzled halfway through the presentation of his example. "Where did these two modularizations come from?" you'll find yourself asking. "What would make the average programmer stupid enough to come up with the first kind of modularization, and how would he be clever enough to invent the second, demonstrably superior, one?" If these questions occur to you, be patient" Parnas does provide the answers later on in the paper. As he points out, the first modularization probably was derived from flowcharting the problem --- an approach still used by many people today. And the second modularization came from a careful consideration of the design decisions that were likely to change. One of the most useful contributions made by Parnas in this paper is the list of practical suggestions --- specifically, a list of the typical kinds of design decisions that should be hidden within a single module. For those who find information hiding a vague topic, the examples help considerably. For a long time, Parnas' work seemed to be unrelated to many of the other developments in the structured field, despite the effort Parnas makes in this paper to relate his ideas to the hierarchical design concepts that Dijkstra was publishing at about the same time. More recently, though, it has become evident that his ideas fit neatly into the realm of structured design, and that they are quite compatible with, say, the ideas presented by Stevens, Myers, and Constantine in "Structured Design" [Paper 18]. The typical consequence of not hiding information is excessive coupling between modules, to use the term first introduced by Constantine; and one also could argue that information hiding is a design heuristic, much like the "span of control" heuristic presented by Stevens, Myers, and Constantine.