Subject: Re: Top Down - Bottom Up - Inside Out
From: rpw3@rpw3.org (Rob Warnock)
Date: Fri, 11 Oct 2002 04:35:16 CDT
Newsgroups: comp.lang.lisp
Message-ID: <w32dnVUxNL3JBjugXTWcoA@News.GigaNews.Com>
c hore <carhore@yahoo.com> wrote:
+---------------
| Overheard...
| Q: Should the system be designed top down or bottom up?
| A: No, inside out.
| 
| What is "inside out" design, or what could it mean?
+---------------

Just what it sounds like: You start architecting/designing in the
*middle* layers first, and then grow the design both up to the end
requirement(s) and down to the available platform(s). Inside-out
design is often useful when you know initially that you're going
to be building a family of similar products to run on a variety
of platforms, but don't yet know the full set of requirements
(so you can't do pure top-down design) nor the full set of targets
(so you can't do pure bottom-up design). With inside-out design
you start by picking a hopefully-small set of (thought-to-be) useful
middle-layer abstractions (based on experience & "style", mainly),
and then implement those on the various target platforms while you
implement the emerging end application requirement in terms of those
middle abstractions. That is, inside-out design is appropriate where
building a common "infrastructure" first is needed.

When one has a set of "R" requirement and "P" platforms, inside-out
design can -- if one is skillful (and lucky, q.v.  previous discussion
of "luck") -- often *decrease* the total complexity to significantly
less than the "obvious" R*P complexity of coding every requirement
independently for each platform. The mark of a well-done inside-out
design is a *small* set "M" of middleware such that M << R and M << P,
so that the total complexity is at most (R*M + M*P) << R*P.

Graphs of completed inside-out designs tend to be "hourglass"- or
"butterfly"-shaped: bushy at both top and bottom and "narrow-waisted"
in the middle layers.

The IPv4 protocol stack is a good example of this: There is a
middle layer with only *one* format[1] -- the IP datagram -- and
*one* function -- IP routing -- and everything above that (TCP,
UDP, ICMP, XTP, VMTP, etc.) is implemented in terms of IP packets
and everything below that (Ethernet, packet radio, FDDI, ATM/CLIP,
HIPPI, etc.) only has to know how to carry IP packets to the next
IP routing layer.


-Rob

[1] O.k., so I'm oversimplifying just a little. In practice using
the IP family also requires ARP & BOOTP (and maybe even RARP),
which have their own packet formats.

-----
Rob Warnock, PP-ASEL-IA		<rpw3@rpw3.org>
627 26th Avenue			<URL:http://www.rpw3.org/>
San Mateo, CA 94403		(650)572-2607