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