brister@td2cad.intel.com (James Brister) (06/20/88)
This may be a stupid question, and I hope I'm in the right newsgroup. Send any flames directly to me and I'll shut up. For the past few years my professors have rambled on about data structures, compiler design and more, ad nauseam. But none of them have ever mentioned the best way, (or any way really) to go about sitting down and actually writing a program. What I mean is: do experienced programmers usually write flow charts, or pseudo code. Do they write the whole program out by hand first or build it up in their favorite editor? What's a good way to organize the writing process? I have all these great ideas running around in my head that I find difficult to get out without making mistakes in the task itself. If you want to reply to me personally, and if anyone else is interested, I will summarize any answers, and then post them. +------------------------------------+----------------------------------------+ | Any opinions are my own and not | brister@td2cad.intel.com | | of my employer. | USNAIL: 3065 Bowers Ave MS SC9-37 | | (Corporations only have policys) | Santa Clara, CA 95051 | +------------------------------------+----------------------------------------+
jmc@ptsfa.PacBell.COM (Jerry Carlin) (06/20/88)
In article <900@td2cad.intel.com> brister@td3cad.UUCP (James Brister) writes: >What I mean is: do experienced programmers usually write flow charts, >or pseudo code. Do they write the whole program out by hand first or >build it up in their favorite editor? > >What's a good way to organize the writing process? I have all these >great ideas running around in my head that I find difficult to get >out without making mistakes in the task itself. Good question! In spite of all the theory and people that say we can reduce programming to a "factory", it is still a "craft" (in the highest sense). There are a lot of aids, and experienced people will use them when appropriate. It is almost never (as in <1%) a good idea to code at the keyboard without knowing what you are doing. On the other hand, for relatively simple programs, I'll code the comments first, then the mainline and then fill in the functions without ever using pseudo code/diagramming techniques etc. For complex systems, I'll use everything under the sun. The best way to organize the process comes with experience: some problems need "data structuring", some "data flow", some "object-oriented" etc. Beware of snake-oil. There is no magic elixer. By the way, you will always make mistakes. Murphy's law lives. I hope this helped you. (In case you're wondering, I've been programming for about 12 years). -- Jerry Carlin (415) 823-2441 {bellcore,sun,ames,pyramid}!pacbell!jmc To dream the impossible dream. To fight the unbeatable foe.
freeman@spar.SPAR.SLB.COM (Jay Freeman) (06/21/88)
That's a fascinating subject; there are probably as many different answers as there are programmers. When I am doing a big system, I usually spend as long a time as possible in a design phase, thinking about data structures, algorithms and control flow at a quite abstract level, often accumulating large stacks of notes on paper, backs of envelopes and so on. I don't use software tools too much for this phase, not because there aren't any (an excellent text editor and perhaps a database tool for chasing down reference material would be the premier items), but because I do much of this work in places where there is no computer (in the shower, commuting, sitting in coffee houses, lying in bed trying to get to sleep ...). A key part of the design is figuring out how to bring the system up; I'm sure your professors tell you that getting everything all written, then compiled, then starting to test, is NOT the way! It's important to define a development path that starts with only a few pieces of the whole thing up and running, and ends with a complete system, such that you can move from point to point on the path by adding small modules to the system, in such a way that each module is separately testable by itself and that the system is immediately testable after module installation to see that the integration worked. If the modules are large, then each module is a project in its own right, and has its own development path. The overall development path then becomes a directed graph. The graph may even have cycles -- one does prototypes and throws them away, and so on. When I start to code I generally use a text editor that is sufficiently familiar that I don't have to think about using it, enter algorithms and data structure either in source or in in psuedocode -- structured English -- and then transmogrify them into real source in the latter case. Depending on the language, it is often easier to think about what's going on by looking at psuedocode. With higher-level languages, the psuedocode is less often necessary. Subject to the constraint on maintaining a testable development path, there are several ways to think about the order in which to implement various modules. Top-down is nice and logical, but often leads to lots of stub functions which are difficult to test until you have coded out to the leaves of the call graph; then you have to do lots of careful incremental testing as the effects of "real" functions propagate their way back to the root. Bottom-up is useful if you are sure what primitives you are going to need; you can then write them, test them independently, and start putting them together. Sometimes I develop along the path of least resistance, working on whatever part of the system I think I best understand and am most prepared to deal with. That changes from day to day, of course. A case can be made for thinking hard about what part of the system is riskiest and working on that part as soon as possible -- if the whole thing isn't going to work, you want to know about it as soon as possible so you can work out a fix or do something else. It is often very handy to use a system that provides some kind of top-level interpreter so that you can call and test functions interactively as you create them. Lisp is great for this, as are some of the interpreted Cs. Most traditional systems and application languages fail badly on that score. And in that context it is a useful rule of thumb never to create a data structure without also creating a function that prints it out in a form that humans can read; you end up inserting that function time after time as a debugging aid. My, how I ramble. Hope this is useful or at least provokes thought. -- Jay Freeman <canonical disclaimer -- these are my opinions only>
larry@pdn.UUCP (Larry Swift) (06/21/88)
In article <900@td2cad.intel.com> brister@td3cad.UUCP (James Brister) writes: >What I mean is: do experienced programmers usually write flow charts, >or pseudo code. Do they write the whole program out by hand first or >build it up in their favorite editor? Flow charts or state diagrams (I prefer the former) are better thought organizers, but are difficult to maintain, so pseudo code usually wins out. However, with flow charts it is difficult to forget about a path. Does ANYONE write code by hand, anymore? I doubt it. Larry Swift UUCP: uunet!pdn!larry Paradyne Corp., LF-207 Phone: (813) 530-8605 P. O. Box 2826 Largo, FL, 34649-9981 She's old and she's creaky, but she holds!
jonson@unicom.UUCP (Mary D Johnson) (06/22/88)
As an old Physics professor of mine once said 'if it works, use it' The basics are still there whether you are coding 10 lines or 10 million lines. Define the problem: what are your expected inputs; what are your expected outputs; what kinds of logical steps are needed; and most important DOCUMENT! PS. I have been programming and analyzing for 26+ years and teaching for 9 years.
alonzo@microsoft.UUCP (Alonzo Gariepy) (06/25/88)
In article <3537@pdn.UUCP> larry@pdn.UUCP (0000-Larry Swift) writes: >In article <900@td2cad.intel.com> brister@td3cad.UUCP (James Brister) writes: >>What I mean is: do experienced programmers usually write flow charts, >>or pseudo code. Do they write the whole program out by hand first or >>build it up in their favorite editor? > >Flow charts or state diagrams (I prefer the former) are better thought >organizers, but are difficult to maintain, so pseudo code usually wins out. >However, with flow charts it is difficult to forget about a path. Does >ANYONE write code by hand, anymore? I doubt it. > I do. Write code by hand sometimes, that is. I tend to design solutions before I design a computer system. Then I design a computer system, and then the program. The externals of a program have to be established before you start to design the code. I generally design the code from the top, down. This gives me some idea of the kind of primitives I need and allows the functions of the program to be modularized. I can identify similar tasks that can be merged into single routines (although I favour small routines, and many are called only once). I work my way down to designing the primitives of the system and identifying tricky algorithms and data structures. I start implementation with the primitives, tricky algorithms and data structures. This is where I use paper. The best form of data structures, the most suitable algorithm and implementation, and the correct behaviour and choice of primitives are all interdependent. I tend to sketch these things out on a narrow lined pad with a pencil. The tricky algorithms I often actually code on paper, especially if I have decided that they need to be coded in assembler. Obviously, few programs have very many tricky algorithms. I often use the same tools when putting together an ADT (abstract data type). Perhaps I work on these things best in an organic environment, as opposed to with a vdt in my face, a disk and fan in my ears, and a handfull of keyboard. I don't normally work out the fine points of the top level design until I have done the implementation described above. The majority of most programs is control structures, initialization, error handling, i/o, etc. These things are usually very straightforward and I code them directly into the editor with comments. Keeping routines small puts more emphasis into the design and allows for fewer oversights in coding. My main() routine typically contains only procedure calls with perhaps one or two loops and if statements. Sometimes, when I don't yet know how to do something, I put a comment in instead. The important thing is to know the inputs and outputs of procedures that do transformations on data, and know the mission of procedures that have large side effects. I only use flow charts for designing the flow of information, never for the flow of control. State tables are useful for state driven programs, if you are forced to use an operating system so primitive that it doesn't have multitasking cheap enough to replace a state model. My feeling is that if understanding the flow of control ever becomes a problem, you have made a major design error and should start over. In multi-process programs, complex control flow is replaced by complex message passing. This can become a nightmare if you haven't chosen a good model for process design. With cheap enough multitasking, it makes sense to keep processes small and focused the same as you do with procedures. Proper error handling and resource control in very complex programs dominates many other design and coding considerations. It seems to take many years of hard earned pain before you realize that most useful programs will have added to them new features, a new interface, new machines to run on, etc. It becomes worth the effort to do clean designs up front that save you the agony of patching up bad code later. And let me tell you, bad coding is universal... Alonzo Gariepy Net disclaimUsual
gmcgary@eagle_snax.UUCP (07/01/88)
Pick up a copy of _Programmers_At_Work_(1st_Series)_ by Susan Lammers
published by Microsoft Press. This is a collection of interviews with
famous and not-so-famous programmers such as Dan Bricklin, Gary
Kildall, Bill Gates, etc...
The person whose work habits I most identified with was Gary Kildall.
I don't know if he produces good software, since I've never seen his
work, I only know that his statements in the interview echo my own
feelings about the programming process.
In the early phases of a project, I tend to think about the problem
a lot at odd moments such as while commuting, or showering. I also
haunt the research libraries of my local major university starting
the Computer and Control Abstracts and then tracking references once
I find some good papers initially. If I get stuck on something, I
just let go of it and concentrate on something else. I trust my
sub-conscious to figure things out.
I spent a number of my formative years reading program-design books,
particularly Glenford Myers's _Composite/Structured_Design_ which I
still re-read every couple of years. Although this book presents
a design methodology using boxes and arrows and stuff like that, I
rarely use it except when I get stuck. By now, I know these
design principles intimately, so I can tell as I am coding whether or
not I am creating modules that have the desirable design properties
(low coupling, high strength/cohesion)
I seldom bother with pseudo-code. I find that legal C-code with long,
descriptive identifier & function names with occasional comments
express algorithms as readably and straightforwardly as pseudo-code.
I could go on and on, but this should give you a feeling of what works
for me...
--
-- Greg McGary
-- gmcgary@sun.com
-- {ucbvax,seismo,ihnp4,cbosgd}!sun!gmcgary
-- {decvax,ima,alliant,phoenix}!eagle_snax!gmcgarypsc@lznv.ATT.COM (Paul S. R. Chisholm) (07/01/88)
< "Would you buy a used operating system from these guys?" > In article <1559@microsoft.UUCP>, alonzo@microsoft.UUCP (Alonzo Gariepy) writes: >In article <900@td2cad.intel.com> brister@td3cad.UUCP (James Brister) writes: > What I mean is: do experienced programmers usually write flow charts, > or pseudo code. An anecdote from CS 701 (any other UW-Madcity alumni remember the graduate compiler course?) In the last week or two, the professor (Marvin Solomon, great teacher) said we had to turn in some external documentation. (Right before the project was due; hey, I guess he was teaching us about the real world.-) Someone asked, "Should we go back and write flowcharts?" The entire class broke out into hysterical laughter. No, I don't think anyone writes flow charts any more. > Do they write the whole program out by hand first or > build it up in their favorite editor? I envy the heck out of people who can design in their head, keeping just the right amount of detail, then type the program in top-down. > I do. Write code by hand sometimes, that is. Me, too. I can't get a design right the first time. It takes me two or three attempts. I need those scribbled-on pieces of paper, with goofs lightly crossed out, as places to make mistakes that I can throw out! Writing with an editor just isn't the same. Material that I wrote and changed is gone forever. Worse, it's harder to throw out a compilable bad effort. And the temptation to sweat details too early is enormous when the compiler is right *there*. . . . Besides, it gets cold out by the PC. If I bring my notebook to bed and scribble there, I stay comfy and warm. (And so does my wife.) > Alonzo Gariepy -Paul S. R. Chisholm, {ihnp4,cbosgd,allegra,rutgers}!mtune!lznv!psc AT&T Mail !psrchisholm, Internet psc@lznv.att.com I'm not speaking for my employer, I'm just speaking my mind.
nick@hp-sdd.HP.COM (Nick Flor) (07/04/88)
In article <900@td2cad.intel.com> brister@td3cad.UUCP (James Brister) writes: > >For the past few years my professors have rambled on about data >structures, compiler design and more, ad nauseam. But none of them >have ever mentioned the best way, (or any way really) to go about >sitting down and actually writing a program. > >What I mean is: do experienced programmers usually write flow charts, >or pseudo code. Do they write the whole program out by hand first or >build it up in their favorite editor? Yikes. It is kind of scary reading some of the responses to your posting James. Seems like there are a lot of programmers employing ad hoc methods in the development of their software. Reminds me of a story Professor W. Howden told us about a conference he attended where a speaker said something like "Newton said 'if I have seen farther, it is only because I've stood on the shoulders of giants'. The problem with programming is that everyone's stepping on each others toes'". But I digress. Anyways, let me see if I can shed some light on the topic: To understand what tools are needed to develop a program, one first needs to understand the techniques humans use to solve complex problems. For things that are too complex, humans use two main techniques: 1) Abstraction 2) Decomposition When developing a large program whose entirety you cannot fathom off the top of your head, the best thing to do is to decompose it into a bunch of more manageable abstract entities. After more thinking, you can then decompose these abstract items even further, until you have a concrete realization of the solution, ie. code. Programs consist of a variety of functions working on a variety of data. Most languages support functional abstraction, but not data abstraction. This is why you cannot just sit down and start programming for languages like 'C' and Pascal. Good tools for software development are those that support both functional and data abstraction in addition to provisions for decomposition of both functions and data. The most common tools used today for software engineering are dataflow diagrams & structure charts. But by no means are they the best. Anyways, I could go on and on and on. Your best bet is to read a book on software engineering. Hope this helps.. and let's have more discussion on this subject. Nick -- + Disclaimer: The above opinions are my own, not necessarily my employer's. + + Oh, sure. Sure. I'm going. But I got | Nick V. Flor * * o * * + + your number, see? And one of these | Hewlett Packard SDD * * /I\ * * + + days, the joke's gonna be on you. | ..hplabs!hp-sdd!nick * * / \ * * +
lishka@uwslh.UUCP (Fish-Guts) (07/06/88)
In article <1392@lznv.ATT.COM> psc@lznv.ATT.COM (Paul S. R. Chisholm) writes: >< "Would you buy a used operating system from these guys?" > > >In article <1559@microsoft.UUCP>, alonzo@microsoft.UUCP (Alonzo Gariepy) writes: >>In article <900@td2cad.intel.com> brister@td3cad.UUCP (James Brister) writes: >> What I mean is: do experienced programmers usually write flow charts, >> or pseudo code. > >An anecdote from CS 701 (any other UW-Madcity alumni remember the >graduate compiler course?) ^^^^^^^^^^ Hey, nice to see a familiar school mentioned! I hope to be taking the course in the fall semester. >No, I don't think anyone writes flow charts any more. It depends what you mean by flow-charts. A point that I haven't seen mentioned yet is that different programmers see programs in different ways. A partner and I were working on a natural-language parser/generator, and I found that one of the biggest differences between us was: she thought of code in terms of written text (i.e. pseudo-code, real-code, whatever), whereas I can only think of programs by "visualizing" them (by writing out flowcharts, pictures of data-structures, whatever). I found that she couldn't think in pictures, and her textual forms of representation were just so many words to me. After we figured that out, it was a lot easier working with one another, and we created a good set of programs together. 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. >Me, too. I can't get a design right the first time. It takes me two >or three attempts. I need those scribbled-on pieces of paper, with >goofs lightly crossed out, as places to make mistakes that I can throw >out! Writing with an editor just isn't the same. Material that I >wrote and changed is gone forever. Worse, it's harder to throw out a >compilable bad effort. And the temptation to sweat details too early >is enormous when the compiler is right *there*. . . . 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.... Although I can't think of any foolproof design method, I have a suggestion (for the original poster): use good tools. I use programs like RCS and Gnu-Emacs, so that I can change code and usually have a method of undo'ing my additions. It is not fun to learn this the hard way! Also, tools like profilers and symbolic-debuggers really help when you are stuck or are fine tuning...no matter what strategy you use. >Besides, it gets cold out by the PC. If I bring my notebook to bed and >scribble there, I stay comfy and warm. (And so does my wife.) Designing programs in bed can be fun, but my girlfriend really hates it when I have finally settled down to sleep, only to exclaim "hey, wait a minute!" and go back to more designing. Insights come at the worst moments sometimes! >-Paul S. R. Chisholm, {ihnp4,cbosgd,allegra,rutgers}!mtune!lznv!psc The above are what I have learned in school and by making a lot of mistakes at my work. I would be glad to continue this topic with anyone (esp. the original poster) over email. -Chris -- Christopher Lishka | lishka@uwslh.uucp Wisconsin State Lab of Hygiene | lishka%uwslh.uucp@cs.wisc.edu Immunology Section (608)262-1617 | ...!{rutgers|ucbvax|...}!uwvax!uwslh!lishka "...Just because someone is shy and gets straight A's does not mean they won't put wads of gum in your arm pits." - Lynda Barry, "Ernie Pook's Commeek: Gum of Mystery"
nick@hp-sdd.HP.COM (Nick Flor) (07/06/88)
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. Speaking of which, for those of you who have not taken a software engineering course, one of the most common software life cycle models is the phased life cycle model. Briefly, there are 5 phases 1) Requirements -- in this phase you specify what you want the software to do without regard to details about how it should be done. 2) Design -- general and detailed design of the software. 3) Implementation -- coding the design up. 4) Validation -- making sure the implementation conforms to the specifications 5) Maintenance -- bug fixes, enhancements. Supposedly you can go from one phase to the next, much like a production line, without going back, but in practice this isn't the case. I guess dataflow diagrams can be used in phases 1&2. Structure charts, 2D diagrams, etc. in phase 2. Flow charts/pseudocode in the detailed design phase (phase 2.5). Good editors in phase 3. Static and dynamic analyzers, i.e. debuggers etc., in phase 4. > 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. Arguments welcome, Nick -- + Disclaimer: The above opinions are my own, not necessarily my employer's. + + Oh, sure. Sure. I'm going. But I got | Nick V. Flor * * o * * + + your number, see? And one of these | Hewlett Packard SDD * * /I\ * * + + days, the joke's gonna be on you. | ..hplabs!hp-sdd!nick * * / \ * * +
chpf127@ut-emx.UUCP (J. Eaton) (07/06/88)
In article <1335@hp-sdd.HP.COM>, nick@hp-sdd.HP.COM (Nick Flor) writes: > 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. > Arguments welcome, Almost true (infinitely?), but is VI really a good editor? I think it's easier to use Emacs for that (and many other) tricks :-) > Nick J. Eaton UT Department of Chemical Engineering Something stupid should go here but I can't think of ... oh, there.
karenc@amadeus.TEK.COM (Karen Cate;6291502;92-734;LP=A;60.D) (07/08/88)
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
nick@hp-sdd.HP.COM (Nick Flor) (07/11/88)
In article <3675@teklds.TEK.COM> karenc@amadeus.UUCP (Karen Cate) writes: > > 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. > Although it was easier for you to model your system in terms of control flow, let me ask you how you made the transition from control flow diagrams to functions and data. i.e. from the control flow diagrams, how did you determine what functions and data types you needed in your program. Computer languages allow you to write functions that operate on data. Although control flow diagrams show you the sequence of events that occur, and can give you a good intellectual feel for how the program works, they don't lend themselves well for decomposition into abstract functions and data types that you can write a program for; especially if you are still in the design phase. Again, I don't find anything wrong with control flow diagrams in the detailed design phase, but in the high level, i.e. general, design phase I'm not convinced of their usefulness. then again, I could be wrong... Nick -- + Disclaimer: The above opinions are my own, not necessarily my employer's. + + Oh, sure. Sure. I'm going. But I got | Nick V. Flor * * o * * + + your number, see? And one of these | Hewlett Packard SDD * * /I\ * * + + days, the joke's gonna be on you. | ..hplabs!hp-sdd!nick * * / \ * * +
karenc@amadeus.TEK.COM (Karen Cate;6291502;92-734;LP=A;60.D) (07/16/88)
Warning: This is fairly long, but someone may find it interesting... In article <1339@hp-sdd.HP.COM> nick@hp-sdd.UUCP (Nick Flor) writes: >In article <3675@teklds.TEK.COM> karenc@amadeus.UUCP (Karen Cate) writes: >> >> 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. >> >Although it was easier for you to model your system in terms of control >flow, let me ask you how you made the transition from control flow >diagrams to functions and data. i.e. from the control flow diagrams, how did >you determine what functions and data types you needed in your program. > The main reason this worked was because we had an easily and well defined "data base". The data objects/structures "fell" right out of the Product Definition. First let's remember the application. It was a system designed to keep track of stock data for a limited "portfolio" and display the data in several different forms. The data was to enter the "system" in one of two different ways, and "leave" the system (i.e. be displayed) in several different ways. The fact that the data structures were so obvious, was one of the reasons we felt control flow was so much more appropriate. This is a very small project compared to what most of "us" (i.e. soft-eng group readers) are accustomed to. We did not have to write the program, just design it. We went through a multi-stage design process. Each step produced a document: 1. Product Definition -Problem Definition -System Justification -Solution Strategy -Priorities for System Features -System Acceptance Criteria -Glossary 2. Software Requirements Specification -Product Overview and Summary o General Overview o Data Acquired o Local Data Storage o Data Entry o Data Representation o On-line help o Statistics -External Interfaces and Control Flow o User Displays and Reports o Command Summary (Softkey def'ns) o High Level Control Flow Diagram -Exception Handling -Early Subsets and Implementation Priorities -Forseeable Modifications and Enhancements -Design Guidelines -Glossary 3. Architectural Design Specification -Control Flow Diagrams -Conceptual Layout of Data Structures and Data Bases -Names, Dimensional Units, and Other Attributes of Data Objects -Name and Functional Description for Each Module -Interface Spec. for Each Module -Timing Constraints -Exception Conditions -Glossary 4. User's Manual (preliminary) 5. Project Legacy Report -Project Description -Initial Expectations -Current Status -Remaining Areas of Concern The Control Flow Diagram: +--------+ | Main | +--------+ | +---------------------------------------------------------+ | | | | +-------+ +----------+ +--------+ +--------+ | File | | DataComm | | Report | | System | | Mgmt. | +----------+ +--------+ +--------+ +-------+ | | | +-Remote +-------------+ +-Store | Retrieve | | | | +------+ +--------+ +-Edit +-Local | HLCV | | Report | | Retrieve* +------+ +--------+ +-Export | | | +-Local +-Local +-Import | Retrieve* | Retrieve* | | +-HLCV +-Trend | Table | Table | | +-HLCV +-Trend Graph Graph *-Local Retrieve is called from three places. Each "box" and "leaf" was a function. The "box" functions merely put up a menu, and called the correct routine depending on the user's choice. Each "leaf" function accessed the "data base" (which was actually to be implemented as a linked list of records in RAM, and stored in two files on disk), massaged the data into the correct format, and displayed it for the user. The local and remote retrieval functions pulled data into RAM (either from a local disk, or some "electronic news retrieval service"). We felt that no data "flowed" through the system, only through the leaves [i.e: (Data Base)->(Graph Fcn)->(User)]. Data flow didn't make any sense. One reason we chose this topic was that one member of my group needed such a tool at that time. He wanted to actually implement it that summer... I lost touch with them over the summer, so I don't know if he ever did. [If any of you guys are reading this, I'd love to hear from you!] > >then again, I could be wrong... > Not necessarily. The point I was trying to make was that "it depends". Most "traditional" or business related software systems really do rely on data flow. Their purpose is to move large amounts of data to and from many places. Not ALL applications do this, as I tried to show with my example. It may still not make much sense, but I'm not willing to type in my 60 or so pages of documentation. I've already spent too long on this... I feel strongly about it though... Too many people do things "this way" because that's what so-and-so said was "the right way", even though it's not the most intelligent way of doing it. [Gee, that sounds condiscending. It was not meant to be.] I fought that philosophy all through college -- having such and so percent comments (which was so much wasted time, in many cases, it couldn't be in a block at the beginning of the procedure, but virtually every line had to be explained individually...), Warnier-Orr diagrams that were incredibly misleading (but required none-the-less), etc and so on. Several times, I looked at what I handed in when I got it back and noticed glaring errors that were not caught by whoever did the grading (99% of the time, that person was not the teacher). Gag. Sorry this is so long. I've given up trying to edit for brevity. I end up leaving too much out. > >Nick >-- >+ Disclaimer: The above opinions are my own, not necessarily my employer's. + >+ Oh, sure. Sure. I'm going. But I got | Nick V. Flor * * o * * + >+ your number, see? And one of these | Hewlett Packard SDD * * /I\ * * + >+ days, the joke's gonna be on you. | ..hplabs!hp-sdd!nick * * / \ * * + Karen A. Cate Tektronix Inc, Beaverton OR tektronix!amadeus!karenc -OR- karenc@amadeus.LA.TEK.COM