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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.software-eng:1169 comp.lang.ada:2073 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!ucbvax!decwrl!purdue!rjh From: rjh@cs.purdue.EDU (Bob Hathaway) Newsgroups: comp.software-eng,comp.lang.ada Subject: Re: Good Design Strategies Message-ID: <6126@medusa.cs.purdue.edu> Date: 28 Feb 89 00:53:50 GMT References: <6100@medusa.cs.purdue.edu> <2344@goofy.megatest.UUCP> Sender: news@cs.purdue.EDU Organization: Department of Computer Science, Purdue University List-Id: 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