Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tekcbi.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxb!mhuxn!mhuxm!mhuxj!houxm!vax135!cornell!uw-beaver!tektronix!tekig!tekcbi!donz
From: donz@tekcbi.UUCP (Don Zocchi)
Newsgroups: net.arch
Subject: RE: Automated Structured Analysis
Message-ID: <173@tekcbi.UUCP>
Date: Wed, 13-Feb-85 00:55:28 EST
Article-I.D.: tekcbi.173
Posted: Wed Feb 13 00:55:28 1985
Date-Received: Fri, 15-Feb-85 04:25:26 EST
Organization: Tektronix, Beaverton OR
Lines: 17

I have used Structured Analysis (Data Flow Diagramming) for a number of years.
It is a very useful tool, for helping you communicate/think about the user's
problem.  I have also carried it to extremes.  In the limit (approaching the
level of coding), SA becomes cumbersome (Even with Tek's SA_Tools).
A perfect example of this is performing an SA on the FFT problem.
I did an SA for an FFT (which I was retrofitting into an assembly language
system), I found that one line of C pseudo code broke down into a full data
flow diagram.  Lets apply this to a 10K line program, where are you going to
keep the diagrams?  How will you keep track of each diagrams interactions?
At the coding level, SA tends to fall apart, because it is an analysis tool.
I see merit at you're striking out at the SA/Code windmill, but the transition
from SA to code has been less severe, than the transition from Current System
Problems to Solution (Code).

			Don Zocchi
			(The opinions expressed above don't reflect
			my employers or anyone elses anything).