Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!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: <3699@teklds.TEK.COM> Date: 15 Jul 88 17:31:30 GMT Sender: nobody@teklds.TEK.COM Reply-To: karenc@amadeus (Karen Cate) Organization: Tektronix, Inc., Beaverton, OR. Lines: 163 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