Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.lang
Subject: Re: Analysis and Design
Message-ID: <1925@umcp-cs.UUCP>
Date: Sat, 7-Jun-86 01:22:43 EDT
Article-I.D.: umcp-cs.1925
Posted: Sat Jun  7 01:22:43 1986
Date-Received: Sun, 8-Jun-86 06:08:31 EDT
References: <993@brl-smoke.ARPA> <441@ccird1.UUCP>
Reply-To: chris@maryland.UUCP (Chris Torek)
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 63

[I have moved the discussion from net.lang.c to net.lang, as it
no longer concerns C specifically---nor for that matter does it
concern any particular language, but there is no net.coding or
net.programming.]

In article <441@ccird1.UUCP> rb@ccird1.UUCP (Rex Ballard) writes:
>In my own experience, I have ended up pouring [sic] over 500 page specs

I hate to sound pedantic (well, perhaps I love to sound pedantic;
yet this is still the wrong place for this), but the word is
`poring'.  (Spelling does not normally bother me, but I have seen
this particular error many times recently, and like the `here,
here' messages, it just reached the irritant level.  Enough.)

>and discovered that there were flaws, errors, and "critical windows"
>that meant the design could not be implemented.  In addition, only
>top-level DFDs and S-charts were provided and top-level tasks were
>assigned to different people with no "bottom level unification
>effort".  The result, 20 different flavors of "convert structure
>A to structure B".

This is certainly a problem.  Of course, that designs are often
flawed does not necessarily mean designs per se are bad (as you
pointed out immediately below); and it is also true that providing
only `top-level' information suffices for a small enough project
(the limiting case being that with a single programmer).

>One of the "Open Issues" of the Yourdon system is whether it is better
>to implement "Bottom Up" or "Top Down".

One morning not too long ago---or more likely one afternoon or
evening---I got up and took my usual shower, and as I finished I
realised that here is another way computer science interacts with
the `real world': some people dry themselves off `top down', and
some `bottom up'.  :-)  Seriously, I doubt that there is any
particular advantage either way.  If the tasks implemented by the
various routines were properly forseen in the design, it hardly
matters when they are written.

>... let's look at what can be done. ...  Monitoring, in the form
>of debug, profiling, metering, etc. should be part of the design,
>rather than "Ad-Hoc" tools that get "stripped to the front panal". [sic]

Personally, I find that more than a minimum of instrumentation just
gets in the way of the code.  Compilers can and should, and even
sometimes do, assist in this, without interfering with readability.
(I will leave `minimum' undefined here; I think it depends on
programmer tolerances.  `Mill him down another .3 microns!' :-) )

>The bottom line is that production should be part of the design
>process, not a middle step in well defined sequence of events.

Here I think we just have different definitions.  To me `design'
cannot include `production', though design can be iterative, with
productions interspersed.  This makes the two intertwined, but
still separate, processes.  I would be surprised if this `mixing'
did not help to lead to a workable design than otherwise.  Whether
the amount of help is proportional to the cost is for others to
determine, though; I have no experience here.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu