Structured design

• Authors: W. Stevens;G. Myers;L. Constantine
• Venue: Classics in software engineering
• Year: 1979

A number of papers were published throughout the 1960s and early 1970s on program design, most commonly with titles incorporating the phrase "modular design," or "modular programming." But Stevens, Myers, and Constantine were the first to use the term "structured design." Their paper, published in 1974, became the precursor of a number of books on the subject. The "Structured Design" paper does a good job of introducing the concepts of coupling, cohesion, design heuristics (span of control, scope of effect/scope of control, among others), and the graphic notations of structure charts. At the basic conceptual level, the ideas first presented in this paper have not changed in the ensuing publication of textbooks. Indeed, the primary justification for massive textbooks on structured design seems to be the need for examples and case studies. Even though the following paper is twenty-five pages long, it has few examples to illustrate concepts that, when first presented, are often completely alien to the average data processing professional. The basic concepts and terms set forth in the paper remain valid although some changes or refinements have evolved since the paper's publication in IBM Systems Journal. t Myers adds such terms as "classical" cohesiveness, and "informational" cohesiveness; and Yourdon/Constantine add "procedural" cohesiveness to the original list of six that are presented in the paper. On a practical level, it has become evident that the test for functional cohesiveness proposed in this paper (and later repeated in the various textbooks) is fraught with danger: It is altogether too easy for a designer to describe one of his modules in such a way that a bad module sounds good, or a good module sounds bad. By using the concepts of cohesiveness and coupling together, this difficulty usually can be overcome. The designer uses cohesiveness as a guiding principle when creating modules in the first place, and he uses the guidelines proposed in this paper to evaluate the cohesiveness of his modules - up to the point where the issue becomes clouded by semantics. Then he switches to an evaluation of his design based on coupling: If the design shows evidence of strong coupling, then the cohesiveness of the modules was probably low, regardless of the eloquent module description the designer may have used to convince himself (and others) that it was functionally cohesive. Unfortunately, that important relationship between cohesion and coupling is virtually ignored in this paper. The other major weakness in the paper is its overly sketchy description of a design methodology variously referred to as "transform analysis," "source-transform-sink analysis," and "dataflow analysis." The paper introduces the concept of dataflow diagrams, but does not elaborate upon them, or give the designer any guidelines for drawing good ones. And the example used to show the transformation of a dataflow diagram into a hierarchy of modules (expressed as a HIPO diagram or a structure chart) is so trivial as to be meaningless to the average reader. It was not until a year after this paper was published that textbooks began providing sufficient detail to fill in some of these gaps; and it was not until two years later that the emerging technology of structured analysis added a crucial element to the dataflow analysis concept --- namely, that the dataflow diagram could be developed by the user and the systems analyst as part of the requirements definition phase of a project. Yet even with these shortcomings, "Structured Design" remains an important paper --- given further credibility by its publication in IBM Systems Journal If you've never been exposed to structured design, hopefully the paper will whet your appetite; or if you've read some of the more recent texts, you should find it interesting to see the kind of progress that has been made since 1974.