Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!elroy!devvax!jplpro!des
From: des@jplpro.JPL.NASA.GOV (David Smyth)
Newsgroups: comp.lang.c++
Subject: Re: Object Design Tools
Message-ID: <1501@devvax.JPL.NASA.GOV>
Date: 7 Mar 88 17:09:27 GMT
References: <97@cui.UUCP> <36300003@pyr1.cs.ucl.ac.uk> <1442@devvax.JPL.NASA.GOV> <1988Mar2.180453.3257@jarvis.csri.toronto.edu>
Sender: news@devvax.JPL.NASA.GOV
Reply-To: des@jplpro.JPL.NASA.GOV (David Smyth)
Organization: Jet Propulsion Laboratory, Pasadena CA.
Lines: 40

hogg@db.toronto.edu (John Hogg) writes:
>des@jplpro.JPL.NASA.GOV (David Smyth) writes:
>>OOD Methodology ...
>>1)	Understand the problem any way you want to. ...
>>2)	Write an informal description of the problem.  This is just prose.
>>3)	Identify the "objects" ...
>>4)	Identify the attributes of the objects ...
>
>While the one true OOD methodology is something we should strive for,
>it regrettably remains a tough problem.  As a matter of fact, ``Booch,
>Cox, and many others'' participated in the OOPSLA Workshop on
>Specification and Design for Object Oriented Programming last October,
>and the consensus was that we still don't know what we're doing.

Yes, it is true that everybody has various little details that they
interject, but I think that this is a good summary of the common
ground.  If you go thru all those proceedings, articles, and books,
and do a one page summary (I've never seen a book that needed more than
a one page summary!), you will end up with a close approximation of the
above list.

>...  In step 1), getting the *right* understanding of the
>problem is both highly important and non-trivial.  
>
> ... selecting the right objects, as in step 3),
>can be difficult outside of the academic environment ...
>
>Alternatively, ... objects are not too hard to choose, but distributing
>behaviours among objects is difficult.  This is step 4)...

I suppose this caveat should always be applied to any design effort,
regardless of methodology and medium:

	ALWAYS GET THE VERY BEST DESIGNERS YOU CAN.  THEY CAN
	NEVER COST TOO MUCH.

Yourdon tried to emphasise that alot of effort is needed, and lots of
consistency in the documentation.  This is simply not so.  All that is
needed is a CORRECT design.  A correct design is probably impossible
for most people to generate, regardless of methodology.  So, I should
have added a "Zeroth" step: 0) Get the best people available.