Re: Good Design Strategies <Was comments on comments>

[rjh@cs.purdue.EDU (Bob Hathaway)]

In article <2344@goofy.megatest.UUCP>, djones@megatest.UUCP (Dave Jones) writes:
>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.

We agree the components are desirable but a modular design should get you 
there quickly too.   By breaking the system into smaller pieces with each
piece providing some well defined and more manageable part of the system,
the components should emerge.  Not only for the objects, but for the software
tools as well.  

>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

Yes I have too.  I've taken a parser out of a 100,000 line compiler
and it wasn't pleasant.  I couldn't just take out the parser because
it was inextricable tied to the scanner and some semantics (typechecking)
was performed there too.  This undoubtable was due to efficiency reasons
and not top-down design.  If on the other hand the design had taken 
reusable software tools into account the parser, scanner, and type system
would be separate entities with each providing a well defined interface.
It would be infeasible to reuse or add another scanner and much effort went
into taking the pieces out to the point where they were reusable.  They
finally did provide reusable components, the parser (and type-system)
generated an idl file representing the parsed functions and was used
immediately by two applications.  Someone recently asked to use the
parser/type-system and since yyparse (the parser) was modified to return
an object representing all the parsed declarations before passing them
to idl routines for output, he had exactly what he wanted in no time.
With just a little foresight on the part of the compiler designers and
with a greater priority given to software reuse the front-end of the
compiler would have provided the "software ecstasy" sought.  Of course,
Adts would have added greater potential for reuse of the data structures
involved but the tools were important too.

>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.

For projects which are not large, I think design will correspond
to recognizing the objects and major software components of the system,
and probably informal coding.  This isn't a major effort and can force
recognizing all issues involved very early.  For large projects, design and
implementation should be separate.

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

Aren't prototypes usually top-down and provide a skeletal framework to show
users so they can decide if the software is what they want, with each
function possibly stubbed out to provide simple or no service?   Or maybe
just a fast implementation to show the bottom level is even possible, but
I don't see what prototypability has to do with top-down design, to verify
the designs correctness?  I think prototyping can show the validity of a 
"correct design", in other words top-down design with the benefit of 
prototyping.

>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?

Good design will keep the low-level routines from knowing too much,
top-down or otherwise.  Just keep this in mind and you're SIL:-)

>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.  
>

But with a modular design (top-down within modules) the tools are
functionally separate and they should not know they are a compiler, just
what their well defined function is to provide and an interface to meet.
I think keeping separate functionality separate is something thats really
important regardless of whether the encapsulation comes through packages,
processes, or whatever.  The same applies to objects, even when designed
top-down the lower level implementation of the Adt should be based on
components which are as generic as possible, I don't see how providing the
implementation calls for non-generic units since the recursive application
of good design will call for modular and generic components which are used
to implement the object.  I can see that if a designer throws away all
design principles after identifying the top level object he could end up
with an unstructured, data-structure oriented, special purpose implementation
but that should be easy to avoid.

Bob Hathaway
rjh@purdue.edu