Topdown design

Topdown design

[petcher]

> Something that neither one of you guys addressed, and that I think is
> crucial to the whole "Top-Down Design" issue, is reusability.
> Top-down design implies leaves that are custom made for the program
> at hand.  Reusability implies molding the problem definition around
> leaf (and maybe not-so-leaf) modules that are already available.
> After all, for a hardware design, you wouldn't design your own ICs,
> would you?
 
Top-down design need not be incompatible with re-usability.  The key is to do 
only the design in a top-down fasion, followed by bottom-up implementation.

Malcolm Petcher

Re: Topdown design

[Bob Hathaway]

In article <8902281333.AA26629@ti.com> petcher@skvax2.csc.ti.com writes:
>> Something that neither one of you guys addressed, and that I think is
>> crucial to the whole "Top-Down Design" issue, is reusability.
>> Top-down design implies leaves that are custom made for the program
>> at hand.  Reusability implies molding the problem definition around
>> leaf (and maybe not-so-leaf) modules that are already available.
>> After all, for a hardware design, you wouldn't design your own ICs,
>> would you?
> 
>Top-down design need not be incompatible with re-usability.  The key is to do 
>only the design in a top-down fasion, followed by bottom-up implementation.
>
>Malcolm Petcher

I agree, keeping reusability in mind while designing any software
will result in reusable parts.  The only reason to "custom make"
software is for efficiency so the tradeoff is clear.  With inline
pragmas the benefit of procedural abstraction can be realized without
cost but since violations of abstraction boundaries is not permisable
to the programmer, some optimizations cannot occur.  But I think the
benefits of well designed software outweigh their cost.  Profiling
software looking for bottlenecks can point out good optimization points,
if any.

Bob Hathaway
rjh@purdue.edu