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