Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ames!ncar!tank!uxc!uxc.cso.uiuc.edu!a.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.lang.smalltalk
Subject: Re: Object-Oriented Analysis
Message-ID: <80500042@p.cs.uiuc.edu>
Date: 3 Oct 88 17:50:00 GMT
References: <125@ghp.UUCP>
Lines: 134
Nf-ID: #R:ghp.UUCP:125:p.cs.uiuc.edu:80500042:000:7589
Nf-From: p.cs.uiuc.edu!johnson    Oct  3 12:50:00 1988


>This is a request for techniques or methodologies for analysing
>complex engineering systems.  There is much said about object-oriented
>programming, a tiny bit on object-oriented design (a few rules of
>thumb), but there is a paucity of material on object-oriented
>analysis.

>Tom Huras, Gellman.Hayward & Partners Ltd.

Tom's signature file was amazing.  It gave the answer to his question!
I am definitely going to put it in a paper or two.  The relevant
fragment of the signature was:

	"Wisdom is supreme;          
	  therefore get wisdom.      
	Though it costs all you have,
	  get understanding."        
	               Proverbs 4:7  

One of the things about o-o programming that is not well understood
is that there is little difference between o-o programming, o-o design,
and o-o analysis.  Smalltalk programmers use rapid-prototyping to
figure out the problem and to develop a clean design.  The reason for
this is that the only people who really know how to design something
are those who have done it before.  Rapid prototyping is the solution
to the question, "If hind-sight is so valuable, how do I get it?"
If you understand what I am saying then you will immediately object
that the whole point of emphasising analysis and design is to reduce
the bugs that always crop up after slash-and-burn programming.  I'll
get to that later.

One of the things that I like about object-oriented programming is that it
lets the design of a program shine through the code.  Object-oriented
programming provides new ways to structure a program, such as class and
instance hierarchies.  Protocol specifications (i.e. interface descriptions)
become much more important than in other languages, primarily because there
are many classes that implement the same protocol.  The result is that I
can quickly figure out the design of a well structured object-oriented 
program.  ("Quickly" being relative, of course.)

Systems written in C tend to have little structure.  The original design
is virtually impossible to figure out unless there is good documentation.
However, documentation is rarely modified when the code is modified,
documentation often gets lost, and it is frequently never written.
It is much better to ensure that the design of the system is included
along with the code for the system so that later generations of
programmers can figure out what is going on.

This is not to say that o-o systems can't be improved.  There are many
kinds of design information that are not included with the program.
Performance choices are an important catagory.  Also, descriptions of
the overall "framework" (the word has a technical meaning) are also
hard to get out of the code unless you know what you are looking for.
This is a great area for research.

The fact that the code for an o-o system contains a great deal of the
design information means that programmers are doing design.  Alternatively,
once the design is done, coding is virtually complete.  Thus, it is rare
to see the distinction between system analysts and programmers in places
that do o-o programming.  Instead, there is a distinction between
tool-kit builders and tool-kit users, or between framework developers
and application programmers (same thing in different words).  However,
both are programmers/designers.

Quit a few people at OOPSLA last week made this point.  I think the
reason why we make this point so emphatically is that we are finding
the people don't believe us. Lots of people think that this way of
building a system is unreliable, inefficient, immoral, and fattening.
On the other hand, object-oriented systems have a reputation for being
reliable and very productive of programmer time.  One would think that
people would believe those who build object-oriented systems when they
explain how the systems were built, and recognize that there is a relationship
between how a system is built and what it looks like at the end.

The object-oriented life-cycle is, without any doubt, cyclic.  In fact,
it makes one wonder how the waterfall model can be called a life-cycle.
A particular application group starts with a set of classes, extends them,
modifies them, and comes up with a prototype of the application.  They
then find out from the customers what was really needed and revise the
system.  This happens several times.  In the middle, the application
classes may be reorganized as an antidote to entropy.  Some of the classes
may be considered general-purpose enough to be added to the standard
class libraries, but most are not.

In between applications, framework designers spot similarities between
applications and try to develop classes that will help solve similar
problems in the future.  Often the third or fourth application of a
particular type will cause the designers to try to develop some general
purpose components instead of building special purpose ones again.  They
may look back at the older components and generalize from them or they
may come up with a solution that is a more radical departure but that
solves the same problems.  In any case, general solutions always come
out of several concrete solutions.

The main reason that o-o programming is so popular is code reuse.
Reusable code is harder to write than other code because, in addition
to being correct, it must be reusable.  The only way to see whether or
not code is reusable is to reuse it.  If some classes will work in
three previous projects then they are more likely to be reusable than
classes that have only been used in one project, which is one of the
reasons why reusable code is usually a result of generalizing from
earlier projects.  I believe it is code reuse that makes the iterative
life-cycle model so important to object-oriented programming.

Design by rapid-prototyping is different from the slash-and-burn style
of programming because the purpose is different.  Slash-and-burn
programmers just want to get a working system.  Rapid-prototypers
want to understand what they are supposed to do.  The hardest part of
building a system is understanding its requirements.  "Understanding"
is the goal of the object-oriented programmer, and the price of obtaining
it is no greater than the priced of successfully building the system.
Thus, "though it costs all you have, get understanding".  Once you
understand the problem and how to solve it, implementing the solution
is easy.  It is the understanding that is the bottleneck.

One of the differences between object-oriented programmers and others
who prototype is that we rarely throw a complete system away.  Instead,
we "grow" the system by modifying or throwing away parts of it but
keeping most of the system at each stage.  Of course, after a while
there is little trace of the original system, but each step along the
way consists of a working program.  One of the reasons why this works is
that object-oriented system are extremely modular, so replacing one
module with another is relatively painless.  Late-binding of procedures
makes this especially easy.

Last week I talked to the Analyst people at Xerox and someone building
oscilliscopes for Tektronix.  I heard people talk from Apple and Mentor
Graphics. They all gave the same story.  Their experiences are the same
as my own building compilers and operating systems.  Object-oriented
analysis and design is little different from object-oriented programming.
Certainly we need better ways of describing our systems, but those ways 
will help programmers just as much as they help analysts and designers.

Ralph Johnson -- University of Illinois at Urbana-Champaign