TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:"Top down" vs. "Bottom up" a la design? From:Jack Shaw <jsh -at- SOFTWARE-AG -dot- DE> Date:Wed, 6 Apr 1994 15:11:42 MEZ
Ken d'Albenas' question about the top-down bottom-up concept
struck me as a query in the traditional EDP sense (since I
have no idea of any of the other neat ones you others
If it was/is, then I would say it is a design concept out
of the era when higher-level languages -- particularly ones
designed for simulation -- made it possible to "create" a
function (say, a statement analyser, or "parser" module)
without REALLY creating it in detail.
For example, let's assume I have the assignment to build
(gotta stop that -- write the program for, forget "build")
a statement parser for a new thingie that makes silk purses
out of sow's ears or whatever. I can literally write neat
statements like "get next" to fetch the next command from
the hyporthetical user program the Silk Purse Generator
will process, but without really writing detailed code.
Maybe something like:
if command <command> then go to
command_table plus <command>
else set goofcode=6,378,954-3/8
That dumb example is written in a phoney simulator
language that simply gets the next command and then
plugs it into the <command> locations of the second
"if..." statement. The second statement then just says,
"if <command> is anything found in the command table
(we've already decided what commands we can accept,
and made a simple table with the name "command_table"
listing them), find the command in the table and do
the instruction (this is implicit, since we haven't
built that much smarts into the thing yet...) at that
offset in the command table.
But if the command is a goof, it doesn't match the
table stuff and so the "else.." step sets a return
code of some horrendous size (but you can use 3 if
you want--most Senior Associate Staph Programmer
Analysts and above do...) and then goes back to
That's (obviously) high-level, or "top"-level
code. Someday, if we ever get enough funding to
build the Silk Purse Generator, we'll flesh it
out. But for now, we can take that dumb little
program, plug it into an equally high-level
(read, "equally dumb") bridge code that ties the
parser I've taken four months to create in its
present form with, oh, the Silk Purse Algorithm
Calling Routine and of course the indespensable
to make a "top" level function that really runs.
Really. It does. That is, it takes the horrendous
goofcode from my routine and really does something
with it. Not much, but something. And, you can't
make silk purses with this thing yet. But we can
actually simulate the top level. And someday, if
we get funded, boy/girl, we're a house afire with
lower-level coders writing low-level grunge code
and testing and revising and saying things like,
"who the heck came up with this idiotic concept
in the first place...!"
But no one will have to answer, because us super-
staph programmer types have all moved on to
Oh, and by the way: when the whole project falls
apart, it also does it from the top, down...