The craft of software engineering has gone through several eras. One way we can identify them is by the books published that promoted the main ideas of each particular era. In each era, the basic concepts were applied to the various phases of the software-development life cycle.
The following is a representative list of the popular books published during the era of structured development:
Techniques of Program Structure and Design—Yourdon, 1975
The Elements of Programming Style—Kernighan and Plauger, 1974
Top-Down Structured Programming Techniques—McGowan and Kelly, 1975
Structured Systems Development—Orr, 1977
Structured Design—Constantine and Yourdon, 1979
Composite/Structured Design—Myers, 1978
Structured Systems Analysis—Gane and Sarson, 1979
Structured Analysis and System Specification—DeMarco, 1979
Structured Requirements Definition—Orr, 1981
Software Testing Techniques—Beizer, 1982
A Structured Approach to Systems Testing—Perry, 1983
While there is some overlap, from this data we can identify the phases of the structured era as follows.
Structured programming, 1974–1975
Structured programming produces source code. It has two distinguishing characteristics:
Modules are decomposed hierarchically.
Modules are composed using only flow-of-control constructs that have a single entry and a single exit.
Structured design, 1977–1978
Structured design produces a functional design. It has three distinguishing characteristics:
Graphic tools display the hierarchy and communication between modules of a system.
Evaluation criteria distinguish between good and bad designs at the modular level.
Implementation strategies determine the order in which to code and implement modules.
Structured analysis, 1979–1981
Structured analysis produces a functional specification of a software system. It has three distinguishing characteristics:
Structured testing, 1982–1983
Structured testing produces a test design. It has three distinguishing characteristics:
Behavioral tests are generated from requirements.
Structural tests are generated from implementation of the software.
Both behavioral and structural tests can be created. The appropriate aspect of the software is represented as a graph, and the inputs that will traverse the arcs of the graph are identified.
Structured documentation, 1985
Structured documentation produces user documentation. It has three distinguishing characteristics:
Documents are hierarchically decomposed into two-page modules, one of which is text and the other is graphics.
Forward and backward references (goto statements) between modules are eliminated.
Module text is written in easy-to-read language.
The basic concepts of the structured development era were top-down decomposition and the use of a small set of simple and safe control-flow constructs. These concepts were successfully applied to everything from coding to documentation. A book that discusses structured debugging, whatever that might be, is notably lacking.
The various structured disciplines were concerned with organizing computation with respect to actions. In contrast, the object-oriented disciplines are concerned with organizing computation with respect to data. Actions aren’t things that stand on their own; they’re attributes of information that corresponds to an entity in the real world.
The following is a representative list of the popular books published during the era of object-oriented development:
Object-Oriented Software Construction—Meyer, 1988
The C++ Programming Language, 2nd ed.—Stroustrup, 1991
Object-Oriented Design with Applications—Booch, 1991
Object-Oriented Modeling and Design—Rumbaugh et al., 1991
Design Patterns—Gamma et al., 1995
Object-Oriented Analysis and Design with Applications—Booch, 1994
Object-Oriented Systems Analysis—Shlaer and Mellor, 1989
Object Oriented Software Testing—Siegel, 1996
Testing Object-Oriented Systems—Binder, 2000
While there is some overlap, from this data we can identify the phases of the object-oriented era as follows.
Object-oriented programming, 1985–1991
Object-oriented programming produces source code. Booch [Bo94] defines it as follows:
Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships.
Object-oriented design, 1991–1995
Object-oriented design produces a functional design. Booch defines it as follows:
Object-oriented design is a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design.
Object-oriented analysis, 1994
Object-oriented analysis produces a functional specification of a software system. Booch defines it as follows:
Object-oriented analysis examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain.
Object-oriented testing, 1996–2000
Object-oriented testing produces a test design. It deals with the numerous issues raised by object-oriented programming that weren’t previously issues: inheritance, polymorphism, and so forth.
Once again, a book addressing object-oriented debugging, whatever that might be, is notably lacking.