Path: utzoo!attcan!uunet!tektronix!teklds!amadeus!karenc
From: karenc@amadeus.TEK.COM (Karen Cate;6291502;92-734;LP=A;60.D)
Newsgroups: comp.software-eng
Subject: Re: Basics of Program Design
Message-ID: <3675@teklds.TEK.COM>
Date: 7 Jul 88 22:11:45 GMT
References: <900@td2cad.intel.com> <3537@pdn.UUCP> <1559@microsoft.UUCP> <1392@lznv.ATT.COM> <349@uwslh.UUCP> <1335@hp-sdd.HP.COM>
Sender: news@teklds.TEK.COM
Reply-To: karenc@amadeus.UUCP (Karen Cate)
Distribution: na
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 86

In article <1335@hp-sdd.HP.COM> nick@hp-sdd.UUCP (Nick Flor) writes:
>In article <349@uwslh.UUCP> lishka@uwslh.UUCP (Fish-Guts) writes:
>>
>>     At my *real* job I flow chart every now and then, but only for
>>complex parts of large programs.  I would hate to flow chart a 10,000
>>line C program in full!  (It isn't worth the effort to me to go that
>>far).  However, I draw a hell of a lot of diagrams of just about
>>anything that I need to clarify...it helps me, and it helps the people
>>I am writing these programs for, because I have found that they rarely
>>think in terms of "real" or "pseudo" code (most of them are not
>>programmers).  Flow charting has its place; same as pseudo-coding and
>>whatever else.  Some people still use it. 
>>
>
>Glad to see more discussion on design.  Let me put in my 2 cents 
>worth about flow charts:
>
>Flow charts show flow of control.  As such, they are more useful for
>documenting detailed parts of a program, e.g a complex algorithm.
>They are generally not useful in high level design, where you are trying
>to figure out what functions and data must be created.  Again, dataflow
>diagrams would be more useful during initial design.
>
>Flow charts should primarily be used in the detailed design phase.

     This is fun.  Here's my $.02:

     I have used "hacked-up" versions of both data flow diagrams and
     flow charts.  Looking back, I used whatever made the most sense 
     out of my ideas (i.e. whatever was easiest at the time).  For
     example, I took a Software Engineering class my senior year.  The
     major project was to design some software system.  We didn't have
     to write the code, just design the spec's using a system the 
     instructor liked.  That included data flow diagrams.  

     A couple of people in my group were interested in the stock market,
     so we decided to write what we called a stock portfolio manager.
     When it came time to generate data flow diagrams, we had a lot of
     trouble.  Essentially we had a database of stock information that
     was either entered by hand, or automatically downloaded from another
     system (part of Compuserve, or something).  The rest of the "package"
     were just "filters" that plotted or graphed the data from a menu-
     driven user interface.

     We did our best guess, which looked something like a broom:  one 
     input, a bubble, and a bunch of "parallel" outputs (which roughly
     corresponded to each menu option).  We took that to the instructor
     with the comment that we felt our system would be more suited to 
     control flow diagrams (essentially a flow chart).  The instructor
     agreed, so we based the rest of our design work on those.

     Another group tried to automate a restaurant with a system similar
     to what many grocery stores have (with a few basic modifications).
     This application is particularly adapted to data-flow.  It's purpose
     is to gather and disseminate data to and from several places...
     I guess our application moved the user around to look at the data
     from various angles...
     
>>     Odd...I never write down code by hand.  I always edit a printout
>>if I need to see more than a screenful at a time.  Different strokes....
>
>Yes.  Why write it twice if you have a good editor?  It's infinitely easier
>to type 'dd' to erase a line in VI, than to use a pencil eraser.
>
     At least I'm not alone out here with my bad memory.  I also tend
     to do a lot of design on paper, before I start typing.  For recent
     projects I've been using one pile of paper for code segments (I
     have been solving code intricacies rather than conceptual ones),
     another pile for data structures/variable names, and I use my
     terminal to look up documentation (socket man pages, etc).  If
     there's not enough information there, there's always the telephone...

     The other advantage to this system is that at least two thirds of
     it is portable.  I can sit at home with dogs and husband so that I
     can see them once in a while...  But that's another topic.
>
>Arguments welcome,

     We don't argue, we just forcibly state our opinions!
>
>Nick

     Karen A. Cate 
     Software Engineer at large
     Tektronix Inc, Beaverton OR
     tektronix!amadeus!karenc -OR- karenc@amadeus.LA.TEK.COM