eberard@ajpo.sei.cmu.edu (Edward Berard) (10/25/89)
Lately, there have been a number of questions along the lines of:
- What methods (methodologies) are being used for
object-oriented development efforts?
- Are approaches to object-oriented software engineering
substantially different from the more traditional (e.g.,
functional decomposition) approaches?
- How do you define "your method/methodology of choice?"
I have spent the last twelve years researching, teaching, consulting
on, and using software engineering methodologies. For more than the
last seven years, my main interest has been in the area of
object-oriented software engineering. For some reason, I feel
compelled to address the questions which have been appearing of late
on comp.object (;-)).
GENERAL OBSERVATIONS
Although the success or failure of many engineering efforts may be
attributed to "luck," "fate," or "destiny," engineering, by and large,
is not based on these items. Probably the most important idea behind
engineering is that one can _systematically_ and _predictably_ arrive
at pragmatic, cost-effective, and timely solutions to real world
problems. Luck may indeed play a role in most engineering efforts, but
most engineers would like to think that they have a significant amount
of control over the outcome of an engineering effort.
The most worthwhile engineering techniques are those which:
- can be described quantitatively, as well as qualitatively,
- can be used repeatedly, each time achieving similar results,
- can be taught to others within a reasonable timeframe,
- can be applied by others with a reasonable level of success,
- achieve significantly, and consistently, better results than
either other techniques, or an ad hoc approach, and
- are applicable in a relatively large percentage of cases.
True engineers are not magicians. If a good engineer discovers what is
apparently a better way of doing things, he or she attempts to tell
others about his or her method. Magicians must, by the very nature of
their business, keep their techniques shrouded in mystery. A good
engineer is _not_ a "guru," a "wizard," or a "shaman." A good engineer
may be "talented," "gifted," or "intuitive," but in any case, a good
engineer can simply and effectively communicate to others the
techniques he or she uses to achieve a high rate of success.
Engineering differs from science. Engineering uses science,
mathematics, engineering disciplines (e.g., error analysis,
configuration management, risk assessment, and reusability), and
excellent communication skills to develop pragmatic, cost-effective,
and timely solutions for real world problems. A scientist is often not
an engineer, however, an engineer must have a firm grounding in
science.
THE BEGINNINGS OF SOFTWARE ENGINEERING METHODOLOGIES
In 1962, Edsger Dijkstra made the observation that a piece of source
code was a series of essentially mathematical statements. Therefore, he
supposed, one should be able to take an arbitrary program and "prove
it be mathematically correct, or incorrect." His attempts at this,
however, did not meet with much success. By 1965, Dijkstra, and
others, were aware of one of the major obstacles, i.e., the now
infamous "goto" statement (more specifically, an unconditional jump).
(See [Dijkstra, 1965], [Knuth, 1974], and [Yourdon, 1975].)
By 1968, Dijkstra was so convinced that the unconditional jump was the
problem, that he published his oft quoted (and satirized) "Go To
Statement Considered Harmful" article ([Dijkstra, 1968a]). Dijkstra's
concerns, however, were not limited to "goto" statements. Later in
1968, he published the results of his (successful) efforts at
developing an operating system ([Dijkstra, 1968b]). This paper is
"must reading," and describes a "layers of abstraction" approach which
is so commonly used today, that we seldom think of it as ever not
being around.
In "Structured Programming" ([Dijkstra, 1969]), Dijkstra not only
coined the term "structured programming," but also emphasized the
importance of error prevention, as opposed to error cure. In this
article, he posed the question:
"The leading question was if it was conceivable to increase
our programming ability by an order of magnitude and what
techniques (mental, organizational, or mechanical) could be
applied in the process of program composition to produce this
increase."
This question still concerns us today, e.g., see [Brooks, 1987].
By 1966, Bohm (with umlauts over the 'o') and Jacopini had their
article translated into English and published in the Communications of
the ACM ([Bohm and Jacopini, 1966]). In 1967, the term "software
engineering" was selected for a (now famous) 1968 NATO conference,
whose purpose was, among other things, to help determine just what
"software engineering" was and what it entailed.
1971 saw Niklaus Wirth's "Program Development by Stepwise Refinement"
([Wirth, 1971]). Stepwise refinement systematized the earlier work of
Dijkstra and Bohm and Jacopini. David L. Parnas published his article
on "information hiding" ([Parnas, 1972]) the next year. The December
1973 issue of Datamation was devoted to the topic of structured
programming, and contained a number of examples of the successful
application of the technique.
It was also during the late 1960s that people realized that structured
programming (to a large extent, "structured coding"), was not
sufficient. Halan D. Mills focused his efforts on "optimizing the
programmer" in the classic "superprogrammer project." The results of
this work were fed into the often cited "New York Times" project
([Baker and Mills, 1973]). It is important to realize that these large
projects, and others (e.g., the Skylab effort), demonstrated not only
structured programming, but also such concepts as the "chief
programmer team" and early versions of "structured design."
Larry Constantine (an IBM employee during the 1960s and 1970s)
wondered if there were some dependable mechanisms for both avoiding
bad designs from the start, and recognizing potential problem areas
before the software got to the production stage. With Wayne Stevens and
Glen Myers, he developed "composite design," which was later renamed
to "structured design." (See [Stevens et al, 1974].)
THE 1970s -- METHODOLOGIES EVERYWHERE
By the mid-to-late 1970s the number of software engineering
methodologies in general, and the number of software development
methodologies in particular, exploded. Some examples include:
- Functional Decomposition approaches, e.g., Structured
Design and Structured Analysis ([DeMarco, 1978])
- Data-Driven/Data-Structured approaches, e.g., [Warnier,
1974] and [Jackson, 1975]
- Formal (mathematical) approaches, e.g., Vienna Development
Method (VDM). See [Jones, 1980].
Probably the most commonly mentioned (_not_ the same thing as "used")
software methodologies were the so-called structured approaches. Tom
McCabe even introduced what he called "structured testing."
THE 1980s -- TAKING A CLOSER LOOK
By the beginning of the 1980s there were so many methodologies
available that just tracking them was a full-time effort. There have
been quite a number of "methodology surveys" published, including:
- [Birrell and Ould, 1985]
- [Blank et al, 1983]
- [DoI, 1981]
- [Freeman and Wasserman, 1982]
The U.S. Department of Defense's "Methodman" effort attempted to
investigate 48 different methodologies, and, in the end, reported
briefly on 24 of them.
The 1980s also was the decade that saw the increased importance of:
- Prototyping approaches. See, for example, [Boehm, 1986].
- Real-time issues. See, e.g., [Ward and Mellor, 1985].
- Computer Aided Software Engineering (CASE), to automate all
these "wonderful" ideas.
OBJECT-ORIENTED METHODOLOGIES
Even if you ignore the most ancient roots of object-oriented software
engineering (i.e., the early work in Artificial Intelligence (AI)),
you can still say that object-oriented techniques have existed since
the late 1960s (most people cite the work of Nygaard and Dahl in
Simula). However, until the mid-1980s, much of the work in
object-oriented arena focused on "object-oriented _programming_."
While, on one hand, a good deal of "object-oriented programming" is
really "object-oriented coding," we have to be honest and point out
the following:
- Methodologies are very important if you have many "small"
steps to accomplish, and many "small" items with which to
deal. Objects (and classes) are typically at higher levels
of abstraction than are "mere data and functions."
Therefore, (semi-)rigorous methodologies are not as
necessary in "small", non-critical, object-oriented
applications as they would be in similar applications
developed using more traditional tools and approaches.
- Even though the focus of many object-oriented discussions
and papers tends to be highly programming language specific,
many of the concepts discussed (e.g., inheritance, data
abstraction, delegation, reusability, and reflection) have
implications which go far beyond low levels of abstraction,
and simple programs.
- Until the fairly recent (within the 1980s) explosive
interest in things object-oriented, object-oriented
approaches were seldom used for large or critical
applications. (Notice that I did _not_ say "were _never_
used.") Thus, the need/demand for well-formulated
object-oriented methodologies was very low -- until very
recently.
Things are different now. The demand for object-oriented approaches is
staggering. The "promises" of object-oriented technology are being
heard in places where methodologies are the norm. Further, it is
perfectly normal for someone to say: "I want to do object-oriented
software engineering. How do I do it, and _more_ _importantly_ how do
I know that I have done it well?"
APPROACHING OBJECT-ORIENTED METHODOLOGIES
Imagine a "playing field" with well-defined object-oriented software
engineering in the middle. We see two teams approaching the middle,
from two different directions:
- One team is the "object-oriented programming crowd," i.e.,
users of programming languages/systems such as Smalltalk,
C++, Eiffel, CLOS, and Self. The players on this team,
despite their internal disagreements, have very few problems
identifying objects and classes. However, when asked about
well-defined approaches to things like "object-oriented
design," they tend either say things like "I know how to do
it, but I am not sure I can tell you," or "huh?"
- The other team very much resembles Hannibal crossing the
Alps. They bring a great deal of useless "baggage" with
them. You guessed it, they are the "structured crowd," and
their "useless baggage" consists of things like data-flow
diagrams, structure charts, entity-relationship diagrams,
and relational databases. When asked why they want to use
these items for object-oriented software engineering, they
respond with answers like: "We know how to use these, and we
don't know how to solve problems without them." or "Hey,
man! We just sunk a lot of money into CASE tools which
support these things, and we gotta use 'em."
It should be obvious to a casual observer, that what these two teams
need to do is cooperate. Unfortunately, there is very little of that
going on.
OBJECT-ORIENTED METHODOLOGIES -- WHAT'S AVAILABLE?
From where I sit, those who are looking for well-defined, "proven"
object-oriented methodologies have three choices:
1. The beginnings of object-oriented methodologies within the
object-oriented programming community. (See, for example,
some of the papers presented during the "software
engineering" sessions at the most recent OOPSLA.) These
come across more like "helpful suggestions" than they do
methodologies. They appear to be heavy on object coupling,
and rather wimpy when it comes to either "real time" or
"object-oriented development in the large" (OODIL).
2. The offerings from the "newly-converted structured crowd."
You may get the distinct impression that these people use
object-oriented terminology in a very strange, and
sometimes inappropriate way. This may, in turn, make you
question the appropriateness of the material.
3. The last option is to seek out people who have been working
with object-oriented methodologies for a number of years,
e.g., people like Grady Booch. These people meet two
criteria. First, they have been working with
object-oriented technology for a number of years. Second,
they have been approaching it from a methodology
standpoint, not a programming standpoint.
In any event, proven object-oriented methodologies do exist.
Unfortunately, they are few and far between.
This message is already tooooo long. It's 3:30 in the morning. I'm
beat. If you want me to present a short discussion on object-oriented
design or object-oriented requirements analysis, let me know. Thanks
for listening.
-- Edward V. Berard
Berard Software Engineering, Inc.
18620 Mateney Road
Germantown, Maryland 20874
E-Mail: eberard@ajpo.sei.cmu.edu
Phone: (301) 353-9652
FAX: (301) 353-9272
BIBLIOGRAPHY
[Abbott, 1983]. R. J. Abbott, "Program Design by Informal English
Descriptions," Communications of the ACM, Vol. 26, No. 11, November
1983, pp. 882 - 894.
[Baker and Mills, 1973]. F.T. Baker and H.D. Mills, "Chief Programmer
Teams," Datamation, Vol. 19, No. 12, December 1973, pp. 58 - 61.
[Birrell and Ould, 1985]. N. D. Birrell and M. A. Ould, A Practical
Handbook for Software Development, Cambridge University Press, New
York, New York, 1985.
[Blank et al, 1983]. J. Blank, M. M. H. Drummen, H. Gersteling, T. G.
M. Janssen, M. J. Krijger and W. D. Pelger, Software Engineering:
Methods and Techniques, John Wiley & Sons, New York, New York, 1983.
[Bohm and Jacopini, 1966]. C. Bohm and G. Jacopini, "Flow Diagrams,
Turing Machines and Languages with Only Two Formation Rules,"
Communications of the ACM, Vol. 9, No. 5, May 1966, pp. 366 - 371.
[Boehm, 1986]. B. W. Boehm, "A Spiral Model of Development and
Enhancement," Software Engineering Notes, Vol. 11, No. 4, August,
1986.
[Booch, 1982a]. G. Booch, "Object-Oriented Design," Ada Letters, Vol.
I, No. 3, March/April 1982, pp. 64 - 76.
[Booch, 1986a]. G. Booch, "Object-Oriented Development," IEEE
Transactions on Software Engineering, Vol. SE-12, No. 2, February
1986, pp. 211 - 221.
[Brooks, 1987]. F. P. Brooks, Jr., "No Silver Bullet: Essence and
Accidents of Software Engineering," IEEE Computer, Vol. 20, No. 4,
April 1987, pp. 10 - 19.
[Campos and Estrin, 1977]. I. M. Campos and G. Estrin, "Concurrent
Software System Design Supported by SARA at the Age of One,"
Proceedings of the Third International Conference on Software
Engineering, 1977, pp. 230 - 242.
[Dahl et al, 1972]. O-J. Dahl, E.W. Dijkstra, C.A.R. Hoare, Structured
Programming, Academic Press, New York, New York, 1972.
[De Marco, 1978]. T. De Marco, Structured Analysis and System
Specification, Yourdon Press, New York, New York, 1978.
[Dijkstra, 1965]. E.W. Dijkstra, "Programming Considered as a Human
Activity," Proceedings of the 1965 IFIP Congress (Amsterdam, The
Netherlands), North Holland Publishing Company, 1965, pp. 213 - 217,
reprinted, among other places, in [Yourdon, 1979].
[Dijkstra, 1968a]. E.W. Dijkstra, "Go To Statement Considered Harmful,"
Communications of the ACM, Vol. 11, No. 3, March 1968, pp. 147 - 148.
[Dijkstra, 1968b]. E.W. Dijkstra, "Structure of the
'THE'-Multiprogramming System," Communications of the ACM, Vol. 11,
No. 5, May 1968, pp. 341 - 346.
[Dijkstra, 1969]. E.W. Dijkstra, "Structured Programming," originally
in a report on a conference sponsored by the NATO Science Committee,
Rome, Italy, October 1969, reprinted in, among other places [Yourdon,
1979].
[DoI, 1981]. Report on the Study of an Ada-based System Development
Methodology, Volume 1, Department of Industry, London, England, 1981.
[Freeman and Wasserman, 1982]. P. Freeman and A. I. Wasserman,
Software Development Methodologies and Ada (Methodman), Department of
Defense Ada Joint Program Office, Arlington, Virginia, 1982.
[Hansen, 1983]. K. Hansen, Data Structured Program Design, Ken Orr &
Associates, Inc., Topeka, Kansas, 1983.
[Jackson, 1975]. M. A. Jackson, Principles of Program Design,
Academic Press, New York, New York, 1975.
[Jackson, 1983]. M. A. Jackson, System Development, Prentice-Hall,
Englewood Cliffs, New Jersey, 1983.
[Jones, 1980]. C. B. Jones, Software Development A Rigorous Approach,
Prentice-Hall, Englewood Cliffs, New Jersey, 1980.
[Jones, 1986]. C. B. Jones, Systematic Software Development Using VDM,
Prentice-Hall, Englewood Cliffs, New Jersey, 1986.
[Knuth, 1974]. D.E. Knuth, "Structured Programming With GOTO Statements,"
reprinted in, among other places, [Yourdon, 1979].
[Linger et al, 1979]. R.C. Linger, H.D. Mills, and B.I. Witt,
Structured Programming, Theory and Practice, Addison-Wesley, Reading,
Massachusetts, 1979.
[Parnas, 1972]. D. L. Parnas, "On the Criteria to be Used in
Decomposing Systems into Modules," Communications of the ACM, Vol. 15,
No. 12, December 1972, pp. 1053 - 1058.
[Stevens et al, 1974]. W.P. Stevens, G.J. Myers, and L.L. Constantine,
"Structured Design," IBM Systems Journal, Vol. 13, No. 2, May 1974,
pp. 115 - 139.
[Ward and Mellor, 1985]. P. T. Ward and S. J. Mellor, Structured
Development for Real-Time Systems, Volumes 1, 2 and 3, Yourdon Press,
New York, New York, 1985.
[Warnier, 1974]. J.-D. Warnier, Logical Construction of Programs, Van
Nostrand Reinhold Company, New York, New York, 1974.
[Wirth, 1971]. N. Wirth, "Program Development by Stepwise
Refinement," Communications of the ACM, Vol. 14, No. 4, April 1971,
pp. 221 - 227.
[Yourdon, 1975]. E. Yourdon, Techniques of Program Structure and
Design, Prentice-Hall, Englewood Cliffs, New Jersey, 1975.
[Yourdon, 1979]. E. N. Yourdon, Editor, Classics in Software
Engineering, Yourdon Press, New York, New York, 1979.
[Yourdon, 1982]. E. Yourdon, Editor, Writings of the Revolution,
Yourdon Press, New York, New York, 1982.