Path: utzoo!attcan!uunet!husc6!mailrus!ames!ucsd!ucsdhub!hp-sdd!nick From: nick@hp-sdd.HP.COM (Nick Flor) Newsgroups: comp.software-eng Subject: Re: Basics of Program Design Message-ID: <1339@hp-sdd.HP.COM> Date: 11 Jul 88 06:24:15 GMT References: <3675@teklds.TEK.COM> Reply-To: nick@hp-sdd.UUCP (Nick Flor) Distribution: na Organization: Hewlett Packard, San Diego Lines: 36 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 * * / \ * * +