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:1120 comp.lang.ada:2036 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!rjh From: rjh@cs.purdue.EDU (Bob Hathaway) Newsgroups: comp.software-eng,comp.lang.ada Subject: Good Design Strategies Message-ID: <6100@medusa.cs.purdue.edu> Date: 23 Feb 89 22:50:07 GMT References: <6093@medusa.cs.purdue.edu> <2325@goofy.megatest.UUCP> Sender: news@cs.purdue.EDU Organization: Department of Computer Science, Purdue University List-Id: In article <2325@goofy.megatest.UUCP>, djones@megatest.UUCP (Dave Jones) writes: > In an article by rjh@cs.purdue.EDU, Bob Hathaway says that he usually > uses ADT's to do top-down design and implementation... Umm, the method presented was better categorized as a modular design strategy with abstract data types. The implementation strategy was Adt/object oriented because coding began by implementing the Adts. In top-down/bottom-up terminology this corresponds to top-down design with bottom-up implementation. This strategy can be applied recursively to Adts with the top level object as the starting point in design and the bottom level sub-objects as the starting points in implementation. We know that we need an intermediate code Adt, which may require a generic tree Adt, which may require a generic list Adt, and so on. It seems natural to first identify the intermediate code Adt as necessary in the overall system design but to begin its implementation at the bottom level by using generic components. Since the following is long, I'll ask here. It would be interesting to see some discussion on design strategies; any interesting opinions or experiences? > I too have been designing all my programs around "abstract data-types" ... > But I don't usually do top-down. I do bottom-up. Design, implementation, > test, everything. It actually shocks some people when I say that. In the > seventies "bottom-up" became a dirty word. Never mind that top-down > methods resulted in some of the most inflexible code every put to disk. > Top-down good. Bottom-up bad. Unnngghh. :-) What you describe sounds like an Adt/object oriented implementation, I'm not sure if the bottom-up arguments apply. > I'll freely admit, there are times when top-down is the way to go. But > it's not the way I do most of the programs I write by myself. > > I start out with a "bottom" that consists of lots of -- okay, I'll go > along with the name -- ADT's which are likely to be of use in just > about any kind of program: lists, queues, hash-tables, avl-trees, > flexible buffers, priority queues and so on. Next I use these to form > ADT's which are specific to the low-level objects under consideration, > etc. And so it goes from bottom to top. The payoff comes when you want > to change something. All you have to do is reshuffle these building blocks, > which are still quite useful. But if you go from the top to the bottom, > a change at the top is likely to invalidate the whole blasted thing. 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. > I sometimes carry it to unlikely extremes. My group is writing a Pascal > compiler. If ever there seemed to be a top-down kind of task, that seemed to be > it. I mean, Pascal is already done, for Pete's sake. There are standards > documents which tell you what a Pascal compiler absolutely *has* to do. But.. > I started out with my bag of standard ADT's anyway, and then defined some > more: Pascal blocks, types, parms, variable-accesses... just about > every kind of Pascal-object you can think of. One by one we implemented > them as we worked our way up to type-definitions, expression-trees, statements. > The methods for these ADT's went into a library. > This sounds like a bottom-up implementation, but since the upper levels (objects) were already known in advance, a top-down design (loosly speaking). >It was only a matter of a few weeks, long before the compiler's high level >was anywhere near finished, that it paid off. Another group was doing >a mouse-driven frontend for the interactive embedded compile/load/go >feature that we have. They needed to be able to capture all of the >type-information, formal parameters and so forth about the program being >run, then fish around in it finding all the variables of this type, >building all the short expressions that are assignment compatible to the >second formal parm of procedure foo, etc.. >... > >Try doing that with a Pascal compiler that was designed top-down to >be a Pascal compiler. It sounds like the bottom-up implementation provided them with the working software early. A good design will provide reusable components which are easy to modify regardless of the implementation. Bob Hathaway rjh@purdue.edu