Subject: Object-Oriented Methodologies 
Keywords: methodologies 
From: eberard@ajpo.sei.cmu.edu (Edward Berard) 
Path: pt.cs.cmu.edu!sei!ajpo!eberard 
Newsgroups: comp.object 
Date: 25 Oct 89 07:42:06 GMT 
 
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. 
 
