Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!daily-planet.concordia.ca!victor
From: victor@concour.cs.concordia.ca (KRAWCZUK victor)
Newsgroups: comp.lang.c++
Subject: Re: Analysis/Design Methods for OOP
Message-ID: <542@daily-planet.concordia.ca>
Date: 20 Jun 91 23:53:22 GMT
References: <44056@fmsrl7.UUCP>
Sender: usenet@daily-planet.concordia.ca
Organization: Concordia University, Montreal, Quebec
Lines: 43

In article <44056@fmsrl7.UUCP> hugh@slee01.srl.ford.com (Hugh Fader) writes:
>It seems as though every reference I read encourages a bottom-up (or
>maybe more appropriately middle-down, middle-up) type of design
>approach for object oriented programming -- i.e. do your program
>design by developing objects, then use the objects to develop the
>system.
>
>This approach may be OK for small one or two programmer projects but
>seems inadequate for larger ones.

I totally agree with the above two paragraphs.  I've read numerous "OO
Design" books (eg. Object Oriented Design by Booch, Designing
Object-Oriented Software by Wirfs-Brock et al, OO Analysis by Yourdon,
Intro to OO Programming by Budd, etc...) and what I've found clearly
lacking in all books is a tested and proven (to a reasonable extent
:-) ) OO/SE methodology for large OO projects involving more than 3
people (possibly dozens), including design, analysis, programming, the
complete shbang!

It seems the main problem is in the design phase, due to the fact that
design starts in the "middle" and goes middle-up and middle-down.  If
the project is "small", the obvious solution is to have one or at most
two people tackle this area (design), in order to cut down on
"communication" overhead, and then assign the implementation of
various classes to various programmers.

But if the project is of any significant size, the design phase can
become too much of a task for one or two people.  Adding more people
without a war plan (like top-down design teams for non-OO programming)
to the design team is obviously fruitless.  Has anyone had any
experience good in this realm?  Or, can anyone recommend a good book
or article on how the design phase of an OO project can be managed
when the design must be done in a hurry, and the task is too involved
for 1 or 2 people who can tap each other on the shoulder, since the
boss expects quality work but can't wait until the 21st century?

The solution doesn't seem to be as obvious as the traditional non-OO
case. 
--
-----------------------------------------------------------------------
|     Victor Krawczuk   (e-mail : victor@concour.cs.concordia.ca )    |
|     Concordia University, Dept. of Computer Science  (H-961)        | 
|     1455 De Maisonneuve Blvd. W., Montreal, Quebec, Canada, H3G 1M8 |