Re: Good Design Strategies <Was comments on comments>

[shf@well.UUCP (Stuart H. Ferguson)]

+-- rjh@cs.purdue.EDU (Bob Hathaway) writes:
| In article <>, djones@megatest.UUCP (Dave Jones) writes:
| >...My assertion -- must I repeat it again? --
| >is that good modules are more likely to come from a bottom-up approach.
| Ok, I'll admit you've made a good point although I still think starting at
| the top is the natural way to design systems (and algorithms).
 [ ... ]
| Ok, how about a quick example starting at top level.  When designing
| a "Classical" compiler/interpreter front-end, I know the structure will
| consist of a scanner to read input and a parser to read the grammar.  
 [ ... ]

Bob goes on to develop a design for a compiler front end in a very
rational and structured top-down type way.

The problem with this example is that it already a solved problem.
Parsing computer languages is such a well solved problem in fact that
there are tools to generate these programs automatically from terse
formal descriptions.

The real test of a design methodology is to try it on a not-so-well
solved problem.  How would you go about designing a WYSIWYG text
processing program, or a hyper-text environment, or a graphical
user interface toolkit?  (If you've done these before, substitute
something you have no IDEA about how to design.)

The pure "top-down" approach starts with some black box called "the
system" which you then break into smaller units and those into even
smaller units until you have something you can implement in a page
or two of code.  The difficulty is that the first decision you have
to make (i.e. breaking "the system" into a first level of components)
is the most far-reaching and nearly impossible to make without knowing
the whole design first.

Also, you know that users are going to demand things you can't imagine
now, so how do you go about designing your systems now so they are
expandable enough to meet the needs of the future?

Reference:  David Parnas, Paul Clements "A Rational Design Process:
		How and Why to Fake It."  IEEE trans soft-eng Feb 1986

The first part of the article is priceless.
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC