Re: Good Design Strategies <Was comments on comments>

[djones@megatest.UUCP (Dave Jones)]

From article <6100@medusa.cs.purdue.edu>, by rjh@cs.purdue.EDU (Bob Hathaway):
> 
> The standard argument for top-down design is that design errors are caught
> early.  A top level change could make all the work done at the bottom level
> unnecessary and major rewriting or complete scrapping could occur.  That
> is the advantage of top-down design with bottom-up implementation, the
> overall design should be close to correct and the implementation is direct
> and fast because the objects and procedures don't depend on anything not
> yet implemented.  I think the advantage of "building blocks" should be
> evident in any design since code which is designed to be easy to modify
> will consist of reusable and parameterized components which correspond
> to a loosly coupled and highly cohesive modular design.
> 

If you end up with "reusable and parameterized components ... loosely
coupled... modular", then it doesn't matter how you got there.
My argument is that in most cases, you are more likely to end up
in such a software ecstacy if you use bottom-up design techniques,
and you'll get there quicker.

The argument for top-down design is based on some assumptions that are 
seldom met.  If the project has these properties, top-down design
can be the best order of business.

   1. Design and implementation are distinct and separate activities.

      If they are not, you can't do one from one direction, and the
      other from the other direction.

   2. A "correct design" can be identified without benefit of prototyping,
      and it will inevitably be error free.


You say, "A top level change could make all the work done at the bottom level
unnecessary and major rewriting or complete scrapping could occur."

HATE IT when that happens!  

That is one reason why I design the low-level objects first.  If they are 
designed without knowledge of the specifics of the higher levels, high 
level changes cannot effect them.  The disaster happens when somebody 
"finishes" the high level design and then designs the bottom level around 
that, and then Ooops! -- it turns out that the high level design had a flaw
in it. Then you discover that the change propogates right down through
all the levels.

Or maybe somebody thinks up an entirely different kind of top-end that 
deals with the same kinds of objects.  Either way, you are likely SOL 
because those low level routines knew too much for their own good.  Now 
if the design at the low level is good, all is well.  Like I said, if you
get there, it doesn't much matter how you got there. But which technique
is less error-prone?

I gave a case history of using the parts of a Pascal compiler in
a mouse-clicky kind of editor. I'll reply to one comment.
You said, "It sounds like the bottom-up implementation provided them 
with the working software early."

I say, The bottom-up design provided them with software that didn't
"know it was in a compiler".  Recall, I did not even know about that
project when I started the compiler. 

And I meant it literally when I said, "Try doing that with a Pascal
compiler that was designed top-down to be a Pascal compiler."

Actually try it.  

I have tried to use the parts of other production compilers
to do things other than pre-runtime compilation. Not as an academic
exercise, but to produce real commercial products.  That's why I'm
writing this one!  I would rather buy the source for one off the self.
Better yet, what I would really like is what I am writing: a library of
low and mid level Pascal object Adt's. Then I wouldn't even need the 
source, except to fix bugs and port it to new platforms. But try to
find such a thing: an open architecture compiler.  So far as I know, I 
am writing the first one.