From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=BAYES_05,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.software-eng:1258 comp.lang.ada:2176 Path: utzoo!attcan!uunet!husc6!bbn!apple!well!shf From: shf@well.UUCP (Stuart H. Ferguson) Newsgroups: comp.software-eng,comp.lang.ada Subject: Re: Good Design Strategies Summary: Rational design Message-ID: <10946@well.UUCP> Date: 11 Mar 89 11:15:09 GMT References: <6126@medusa.cs.purdue.edu> <2542@goofy.megatest.UUCP> <6156@medusa.cs.purdue.edu> Reply-To: shf@well.UUCP (Stuart H. Ferguson) Organization: The Blue Planet List-Id: +-- 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