Open AccessBook
Structured design
W. P. Stevens,G. J. Myers,L. L. Constantine +2 more
- 01 Jan 1979
pp 205-232
1.2K
TL;DR: The paper does a good job of introducing the concepts of coupling, cohesion, design heuristics, and the graphic notations of structure charts, but its overly sketchy description of a design methodology variously referred to as "transform analysis," "source-transform-sink analysis," and "dataflow analysis."
read more
Abstract: 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.
read more
Chat with Paper
AI Agents for this Paper
Find similar papers on Google Scholar, PubMed and Arxiv
Write a critical review of this paper
Analyze citations of this paper to find unaddressed research gaps
Citations
•Book
Contextual Design: Defining Customer-Centered Systems
Hugh Beyer,Karen Holtzblatt +1 more
- 01 Jul 1997
TL;DR: This book introduces a customer-centered approach to business by showing how data gathered from people while they work can drive the definition of a product or process while supporting the needs of teams and their organizations.
3.5K
Program slicing
Keith Gallagher,David Binkley +1 more
- 01 Sep 2008
TL;DR: Applications of program slicing are surveyed, ranging from its first use as a debugging technique to current applications in property verification using finite state models, and a summary of research challenges for the slicing community is discussed.
2.8K
•Book
The social shaping of technology
Robin Williams,David Edge +1 more
- 01 Jan 1988
TL;DR: The social shaping of technology (SST) as mentioned in this paper is a growing body of research that explores how the design and implementation of technology are patterned by a range of "social" and "economic" factors as well as narrowly "technical" considerations.
2.5K
•Book
Introduction to Software Testing
Paul Ammann,Jeff Offutt +1 more
- 01 Jan 2009
TL;DR: In this paper, the authors define testing as the process of applying a few well-defined, general-purpose test criteria to a structure or model of the software, and present an innovative approach to explaining the process.
Object-oriented development
TL;DR: The author examines the process of object-oriented development as well as the influences upon this approach from advances in abstraction mechanisms, programming languages, and hardware.
References
A case for end system multicast
TL;DR: Narada as discussed by the authors is an alternative architecture for end-to-end multicast, where end systems implement all multicast related functionality including membership management and packet replication, and self-organize into an overlay structure using a fully distributed protocol.
Control of sequence and parallelism in modular programs
Larry Constantine
- 30 Apr 1968
TL;DR: A variety of schemes for the specification and operation of parallel computation have been described recently, but they are not at a truly procedure- or problem-oriented language level but represent transliterations of machine or process-oriented operations.
12
Chief programmer team management of production programming
TL;DR: As is evident from some of the other material reprinted in this book, much of the early discussion about structured programming and the related techniques was conducted by academic people and was published in scholarly journals, thus escaping the attention of the average software professional.
Related Papers (5)
Tom DeMarco
- 01 Jan 1978
Michael Jackson
- 01 Jan 1975
Shyam R. Chidamber,Chris F. Kemerer +1 more
- 02 Sep 2011
Roger S. Pressman
- 01 Jan 1982