soft-eng@MITRE.ARPA (Alok Nigam) (07/16/88)
Soft-Eng Digest Sat, 16 Jul 88 V: Issue 17
Today's Topics:
Basics of Program Design (2 msgs)
Beta Testers Needed
CASE Tools Query (2 msgs)
Finite State Machine (FSA) compiler
Finite State Machines
Fortran follies (7 msgs)
Source Control -- The Saga Continues
Structured Analysis ques. (3 msgs)
----------------------------------------------------------------------
Date: 21 Jun 88 17:29:44 GMT
From: pixar!unicom!jonson@bloom-beacon.mit.edu (Mary D Johnson)
Subject: Basics of Program Design
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.
------------------------------
Date: 25 Jun 88 10:00:51 GMT
From: microsoft!alonzo@beaver.cs.washington.edu (Alonzo Gariepy)
Subject: Basics of Program Design
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...
------------------------------
Date: 8 Jun 88 23:42:04 GMT
From: ucsdhub!sdsu!roetzhei@ucsd.edu (William Roetzheim)
Subject: Beta Testers Needed
I have completed development work on a new IBM-PC based
CASE (computer assisted software engineering) tool, and am looking for
qualified individuals willing to beta test the software. I will send
the software and rough user's manual at no cost in exchange for an in
depth look at the software and report of discovered defects and recommended
changes. If requested, I will also be willing to give beta testers a copy
of the finished product for my duplication costs (ie. for the documentation).
STRUCTURED DESIGNER'S TOOLBOX (SDT) is a PC based CASE environment
supporting software design. SDT implements all components of HIPO-II, an
updated versioin of the original IBM HIPO (Hierarchy plus Input-Process-
Output) technique. SDT and HIPO-II were developed by me along with an
accompanying book (Structured Design Using HIPO-II) which will be
published by Prentice-Hall this fall. HIPO-II adds features to HIPO
such as:
1. HIPO's single class of hierarchical modules (functional
process) has been expanded to include modules which represent user
interaction via menus, interrupt based modules, keyboard activated
modules, modules which are common within a design, and library modules.
2. HIPO-II includes built in, automatic prototyping capabilities.
3. HIPO-II shows program control flow - including sequence,
alternation, iteration, concurrency, and recursion - directly on the
hierarchy chart.
4. IPO processing descriptions are entered using pseudocode.
The pseudocode (structured english) is also output for use by the
programming team.
5. HIPO-II includes facilities for the design and use of a common
system-wide data base and global data structures.
6. The input-output portion of the IPO charts has been reformatted
to match typical module internal header formats commonly used during the
software implementation stage. This allows the design process to
directly generate program module header entries for use by the programming
team.
7. HIPO-II is designed to directly support and interface with
project management software.
In addition, SDT demonstrates several innovative user interface
techniques which simplify maintenance of the program design. Examples
include design windows, program design components and libraries, and
information hiding on a global and local scale.
I will also be speaking at the CASE 88 conference in Cambridge
(July 1988) and the Pacific Northwest Software Quality Conference in
Portland (September 1988) and will be available to talk to any beta
testers (or others) at that time.
If interested, please send me your qualifications and a shipping
address. I can be reached at the above Email address or:
William H. Roetzheim
3891 American Avenue
La Mesa, CA 92041
(619) 223-2307 (work number)
------------------------------
Date: 8 Jun 88 14:42:36 GMT
From: att!mtunx!whuts!homxb!largo@bloom-beacon.mit.edu (J.BAKER)
Subject: CASE Tools Query
I want to learn about the current capabilities of CASE tools that
run on 1) PCs and 2) SUNs. My knowledge of SA, DFD, DD, etc.
is about four years old so keep that in mind in your responses.
My application is Sys Eng of network services and network control
systems. DFD bubbles can be h/w, s/w or people. We don't do
detailed design, mostly interfaces and high level functional
requirements. I see CASE tools enhancing our work by adding
easy-to-use graphical summaries of architecture and data flow as
well as providing a database of message structures and content.
What real-time extensions are available? Can dependencies, sequencing,
and timing (of messages and processes) be represented graphically?
How about consistency checking and integration with other tools?
I would appreciate any pointers to articles or vendors where I might
get more information.
------------------------------
Date: 10 Jun 88 19:09:34 GMT
From: hpda!hpcuhb!hpsmtc1!ding@bloom-beacon.mit.edu (Ignatius Ding)
Subject: CASE Tools Query
Many studies have been done by software vendors, CASE users or
independent consultants in the last couple of years. Most recently, there
were several major investigations conducted by aerospace companies, system
houses and software consortiums, including HP, DEC, SEI and others.
Unfortunately, I am unable to release any of our reports to others outside
the company because they are all classified. Subscribing CASE Newletter
maybe is a good way to start your research. MCC, SEI and SPC all have
published quite a few articles on IPSE or CASE tools. Some of them are in
the public domain. You might give a try to contact them for a copy of the
investigation reports. Some papers published or presented at International
Software Engineering Conferences, CASE Expo, CASE Symposium, etc. do
provide some limited review for products or software environments for
certain time window. These articles could offer you a sneak preview of
this area but you have to keep in mind that the evolving IPSE/CASE
technology these days obsoletes most of findings in a matter of months.
Many people within Bell Labs also invested a substantial amount time
and energy on this topic. They may or may not locate at Holmdel. You
might want to ask around. There are at least three locations I know of
working on CASE tools. Plus the joint projects with UC Berkley.
A few leads .....
SEI : Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
Contact - Robert.Ellison@SEI.CMU.EDU
CASExpo : Publisher of CASEnews
CASEpxo
3825-1 South George Mason Drive
Falls Church, Virginia 22041
CASE Symposium: Digital Consulting, Inc.
6 Windsor Street
Andover, MA 01810
(617) 470-3870
------------------------------
Date: 13 Jun 88 12:35:31 GMT
From: mnetor!spectrix!yunexus!geac!daveb@uunet.uu.net (David Collier-Brown)
Subject: Finite State Machine (FSA) compiler
> (6) I am currently modifying some code based on an undocumented and
> erroneous Finite State Machine -- ARRRGH
EGNILGES@pucc.Princeton.EDU writes:
> You have my sympathy, but if you replace the string "Finite State
> Machine", the "ARRRGH" is still valid!
For mere humans, there is a good FSA compiler in the Kermit
distribution, called "wart". Use of it makes
1) the notation a fair bit easier to follow, and
2) the ugly generated/required code irrelevant.
I have an upgraded version, available by mail for anyone with a C
compiler. Please note that Wart does not have to genrate C: FORTRAN
II would probably be ok. You need a C compiler to compile Wart
itself.
A short description follows:
WART(1)
NAME
wart -- a dfa compiler
SYNOPSIS
wart [file]
DESCRIPTION
Wart is a program which takes a yacc-like file of code
and directives and generates a c program from it. The
directives define a deterministic finite automaton (DFA),
and are primarily for producing protocol engines, such as
are used by C-Kermit.
The format of the file is:
lines to be copied
%states <list of state names>
%events <list of event names>
%%
event { block of code to be executed }
...
<state[,state]> event { block of code to be executed }
<state> event { more code... }
...
%%
more lines to be copied
Wart therefor implements a small subset of the Unix
'lex' lexical analyzer generator. Unlike lex, wart may be
distributed without requirement for a Unix license.
Wart is intended for production of state table switch-
ers. It allows a set of states to be defined, along with a
function for getting input, and a table of state transi-
tions. A C program is generated which performs actions and
switches states based on the current state and the input.
[...]
HISTORY
Wart was written by Jeff Damens of the Columbia Center
for Computing Activities, November, 1985, to facilitate
development of Unix Kermit. It was updated by David Brown
of Tesseract Technologies in February, 1986.
The program is Copyright (C) 1985, the Trustees of
Columbia University in the City of New York.
The earlier version assumed that the event would be a
single ascii character, and did not support the "%events"
directive.
------------------------------
Date: 9 Jun 88 22:43:23 GMT
From: phoenix!pucc!EGNILGES@princeton.edu (Ed Nilges)
Subject: Finite State Machines
>From: PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU
>Subject: Gotos and Finite State Machines
>
>After all these years we're still discussing that old fourletter word.
>Here comes a summary of much stomach chunning ...
>
"Chunning" is a nice new word, altho "churning" was intended, devil a
doubt.
> .....
>(6) I am currently modifying some code based on an undocumented and
> erroneous Finite State Machine -- ARRRGH
>
You have my sympathy, but if you replace the string "Finite State
Machine", the "ARRRGH" is still valid! This is not the case if
you remove "undocumented and erroneous", but leave "Finite State
Machine" in the original statement. Put the blame where it belongs!
>
>(7) A finite state machine is no more or less than a flowchart without
> boxes (Ref - Any good text on the theory of Computabillity).
No, a finite state machine is an alternative representation of a
language of Chomsky type 3. See John E. Hopcroft and Jeffrey D.
Ullman's FORMAL LANGUAGES AND THEIR RELATION TO AUTOMATA, Addison-
Wesley, 1973, page 33:
"Let G = (V(N),V(T),P,S) be a type 3 grammar. Then there
exists a finite automaton M = (K,V(T),squiggle,S,F) with
T(M) = L(G)"
What this means in English is that a language whose syntax rules
are of the form A::=aB or A::=a, where A and B are nonterminals
(things like "noun" and "verb") and a is a terminal (things like
"cat" and "John") can be parsed by a finite state machine which
goes only one way on its input tape, can't write on its input tape,
and is in one of a number of states. Graphical representations of
finite state machines look the the horrible flowchart of yore;
but the inability of the finite state automaton to act like a
full-scale computer means that these type of "flowcharts" are much
more disciplined (and consequently less hard to understand) than
flowcharts of programs for real computers (which are Turing machines,
much more powerful than finite state automata).
For instance, the userid of the original submitter, PAAAAAAR, is
a member of the language:
<userid> ::= <userid_head>R
<userid_head> ::= <peeee><sigh> { N.B.: sorry }
<peeee> ::= P
<sigh> ::= A
<sigh> ::= <sigh>A
(the language consisting of PAR, PAAR, PAAAR ....)
The work of constructing a automaton for recognizing these strings is
left as an exercise for the reader.
The fact that the Chomsky (yes, that's Noam Chomsky of the dreaded
New York Review of Books in a mathematical, rather than political,
incarnation) type 3 language maps so nicely onto finite state auto-
mata means that if you acquire a feel for recognizing "languages"
where they are type 3 means that you have a useful technique handy,
finite state automata, for solving a problem. For example, messages
coming over a communications line or the sequence of records in a
structured file might form a type 3 language. The technique is most
heavily used in the lexical analysis phase of compilers to recognize
identifiers and such.
I realize that this compressed introduction may be a bit confusing to
some. Does anybody out there want to submit a tutorial on automata,
languages, and their real-world application to this conference?
------------------------------
Date: 21 Jun 88 21:35:24 GMT
From: killer!tness7!tness1!sugar!ssd@eddie.mit.edu (Scott Denham)
Subject: Fortran follies
In article <701@garth.UUCP>, smryan@garth.UUCP (Steven Ryan) writes:
>
> Assuming all dummy arrays are assumed-size (largest dimension is *) breaks
> vectorisers and optimisers which need to know the array size. (This has to
> do with dependency analysis.)
>
You make a good point. I have since learned that the most recent version
of IBM's vectorizing compiler makes what is probably the most reasonable
assumtion that can be made: a final dimension of 1 or * on a dummy array
are treated the same; for purposes of vectorization and optimization the
acutal dimension is assumed to be unknown. Any other value is assumed to
be correct. I suppose the rationale is that if the programmer went to the
trouble to put a dimension in there, it is probably meaningful. As it turns
out, this approach is useful for us, or would be if all vector compiler
vendors used the same logic. The only other way to guide the compiler in
making decisions is through the use of directives, and these have no
standard form at all. Further, an estimate of size is much safer than a
binary VECTOR/NOVECTOR directive, since the boundary will differ on
different architectures and possibly on different models within the
same architecture.
------------------------------
Date: 22 Jun 88 23:33:02 GMT
From: garth!smryan@unix.sri.com (Steven Ryan)
Subject: Fortran follies
In article <2157@sugar.UUCP> ssd@sugar.UUCP (Scott Denham) writes:
>You make a good point. I have since learned that the most recent version
>of IBM's vectorizing compiler makes what is probably the most reasonable
>assumtion that can be made: a final dimension of 1 or * on a dummy array
>are treated the same; for purposes of vectorization and optimization the
>acutal dimension is assumed to be unknown. Any other value is assumed to
>be correct.
As does the CDC Cyber 205 Fortran for the (?) last year. (I only know when
I coded--the powers that be decided when/if it was released.)
> Further, an estimate of size is much safer than a
>binary VECTOR/NOVECTOR directive, since the boundary will differ on
>different architectures and possibly on different models within the
>same architecture.
64 elements for a Cray, 4096 for a Cyber 990, 65535 for a Cyber 205/ETA 10.
I don't know what IBM vectors are like. Is the Hitachi machine (?VPxxxx)
in existent yet?
------------------------------
Date: 23 Jun 88 14:36:41 GMT
From: s.cc.purdue.edu!ags@h.cc.purdue.edu (Dave Seaman)
Subject: Fortran follies
In article <777@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes:
>In article <2157@sugar.UUCP> ssd@sugar.UUCP (Scott Denham) writes:
>>You make a good point. I have since learned that the most recent version
>>of IBM's vectorizing compiler makes what is probably the most reasonable
>>assumtion that can be made: a final dimension of 1 or * on a dummy array
>>are treated the same; for purposes of vectorization and optimization the
>>acutal dimension is assumed to be unknown. Any other value is assumed to
>>be correct.
>
>As does the CDC Cyber 205 Fortran for the (?) last year. (I only know when
>I coded--the powers that be decided when/if it was released.)
>
Unfortunately the Cyber 205 FTN200 compiler turns out to be nonstandard
because of this. You cannot treat an array with final dimension 1 as being
indistinguishable from an assumed-size array, because the standard says the
following is legal Fortran:
subroutine sub (a)
real a(1)
print *, a
end
The routine is not legal if the declaration is changed to "real a(*)".
FTN200 used to handle this correctly, but when the change was made so that
runtime array bounds checking (when enabled) would not apply to dummy
arrays with a final bound of 1, an undesired side effect was to make code
like that above fail to compile. And yes, there are legitimate reasons for
writing code like this.
------------------------------
Date: 24 Jun 88 21:35:49 GMT
From: titan!david@rice.edu (David Callahan)
Subject: Fortran follies
In article <2157@sugar.UUCP> ssd@sugar.UUCP (Scott Denham) writes:
>In article <701@garth.UUCP>, smryan@garth.UUCP (Steven Ryan) writes:
>>
>> Assuming all dummy arrays are assumed-size (largest dimension is *) breaks
>> vectorisers and optimisers which need to know the array size. (This has to
>> do with dependency analysis.)
>
>You make a good point.
I'm not sure about that. Vectorizers will only rarely need the largest
dimension since it does not appear in the addressing arithmetic. For that
reason it probably will not be used by the decision procedure which
determines if a pair of references to a particular variable overlap and
so will not influence vectorization. Furthermore, unless the bound
is hardwired as a constant, it won't be very useful anyway. If you
see reduced vectorization it may be due to an assumption that the
dimension is short and hence vectorization would be unprofitable.
------------------------------
Date: 24 Jun 88 07:05:25 GMT
From: killer!tness7!tness1!sugar!ssd@eddie.mit.edu (Scott Denham)
Subject: Fortran follies
In article <777@garth.UUCP>, smryan@garth.UUCP writes:
Lots of stuff deleted..........
>
> 64 elements for a Cray, 4096 for a Cyber 990, 65535 for a Cyber 205/ETA 10.
> I don't know what IBM vectors are like. Is the Hitachi machine (?VPxxxx)
> in existent yet?
The IBM vectors are 128 elements in the current implementation, but the
architecture definition allows for 16 (I think) to 512; it's done in a
nice way so the compiler doesn't have to KNOW what it is.
The Amdahl (Fujitsu) VP's have a reconfigurable register section that
can go from something like 8 regs of 8192 to 256 regs of 256. If the
Hitachi machine is the one being nmarketed here by NAS, it exists, and
they claim some pretty impressive price/performance relative to the IBM
3090's.
------------------------------
Date: 24 Jun 88 23:56:28 GMT
From: garth!smryan@unix.sri.com (Steven Ryan)
Subject: Fortran follies
In article <2168@sugar.UUCP> ssd@sugar.UUCP (Scott Denham) writes:
> it's done in a
>nice way so the compiler doesn't have to KNOW what it is.
Actually, you want the compiler to know if you want really snazzy dependency
analysis. (Ah, yes, see this diophantine equation has a solution for n=xxx.
But my vectors ar only yyy long. Oh, no problem.) Of course nobody has
dependency analysis quite that snazzy.
------------------------------
Date: 24 Jun 88 23:40:13 GMT
From: garth!smryan@unix.sri.com (Steven Ryan)
Subject: Fortran follies
In article <3244@s.cc.purdue.edu> ags@s.cc.purdue.edu.UUCP (Dave Seaman) writes:
>>As does the CDC Cyber 205 Fortran ....
>
>Unfortunately the Cyber 205 FTN200 compiler turns out to be nonstandard
>because of this. You cannot treat an array with final dimension 1 as being
>indistinguishable from an assumed-size array, because the standard says the
>following is legal Fortran .......
>FTN200 used to handle this correctly, but when the change was made so that
>runtime array bounds checking (when enabled) would not apply to dummy
>arrays with a final bound of 1, an undesired side effect was to make code
>like that above fail to compile. And yes, there are legitimate reasons for
>writing code like this.
Not to disagree. The compiler was changed to make the manager happy.
I would've preferred to make people change 1 to * when that was they meant.
------------------------------
Date: Tue, 7 Jun 88 23:48 EST
From: John Beecher-Deighan <JBD%cgi.com@RELAY.CS.NET>
Subject: Source Control -- The Saga Continues
I've been fairly passive in this newsgroup up to now, but since the
discussion is winding itself around to something near and dear to my heart
(read: I have real nightmares about this stuff) I thought I would put my two
cents in.
First of all, my code control background is heavily influenced by UNIX's
SCCS program. I am now doing code control using VMS's MMS package: for all
practical purposes the same thing (no flames from AT&T or DEC people,
please).
Next, I am a *user* of these products. I'm with a
small-rapidly-becomming-a-medium sized company, and we just don't have the
resources to build tools, even when it would probably be a good idea to do
so. I have to make do with off the shelf products.
Which brings me to my problem. I have to control software that is maintained
on the VAX under VMS/MMS, but that has to run on the following environments:
OS/2 on PC/AT's
UNIX on SUNs
VAX under VMS
Macintosh under whatever they're calling their OS
Plus, we have to support different versions, runnable on all of the above
machines. Another gentleman and myself do the "real work" on this project,
but the head count is going to go up any day now.
WISH LIST
Now that you've waded through all that, I would like to present a wish list
of functions (I hate the engineer-ism "functionality") that I currently
don't have, but would be damn nice to have:
- an *intelligent* merge editor. Every try to use the "check
out, check in" "feature" that's included in SCCS? I don't
know about you, but I've never worked on a multi-user
project where some merging had to take place. That merging
has to be done by hand. An editor (full screen, pleeze!?)
to help you do the merging would be a boon!
- This is not a "fuction", but how about a program to
determine the "readability" of programs? I'm thinking about
the case where your #define's and #ifdef's make your code
damn near unreadable (and un-maintainable). (O.K., this
*is* C, but there has to be a similar facility in Pascal
and Fortran...). It would be nice if there was something
that looked at a program, determined that you were over
some percentage of conditional compilation to generic code,
and created two (or more) files (hopefully more readable
than the one you started out with).
THE REAL PROBLEM
Here's my real problem: this C program I have to maintain is directly
descended (translated) from a LISP program. The LISP program is still
"living". LISP development is done on a Symbolics. LISP development does not
use source code control ("We're not a COBOL shop here" was one of the
"reasons" given to me), nor would it be easy to impose a source code control
system on the LISP code (for hardware, software, but mostly political
reasons). We have to keep the C and the LISP in synch, as much as possible.
Now you begin to see my problem.
It's late, I'm depressed. Any comments should be directed to jbd@cgi.com.
More to follow, unless I'm shouted down...
------------------------------
Date: 8 Jun 88 21:50:59 GMT
From: bunker!rha@yale-zoo.arpa (Robert H. Averack)
Subject: Structured Analysis ques.
In article <2449@uvacs.CS.VIRGINIA.EDU> hsd@uvacs.cs.virginia.edu.UUCP (Harry S. Delugach) writes:
>One doesn't have to separate the two phases (requirements and design)
>as long as the designer keeps in mind the distinction between them --
>which decisions which are fundamental to the system's purpose and which
>merely carry out the purpose?
I think we need to be a little careful here. It should be clear that
one needs to know WHAT a system is supposed to do BEFORE it is possible to
determine HOW to do it. Therefore, even if the time gap between these
decisions is one hour, one could consider them as separate phases.
Again, the essential point here is: WHAT before HOW.
------------------------------
Date: 8 Jun 88 12:35:42 GMT
From: mcvax!ukc!stl!stc!datlog!dlhpedg!cl@uunet.uu.net (Charles Lambert)
Subject: Structured Analysis ques.
In article <4150003@hpcilzb.HP.COM> chris@hpcilzb.HP.COM (Chris Toomey) writes:
> Let's say I'm developing a very simple spelling program (similar to UNIX's
>spell) which will repeatedly prompt the user for words ...
>
>
> ------- ---------
> ---------- words / \ --------------> correct
> | user | -------->| spell | ---------
> ---------- \ / --------------> incorrect
> -------- ---------
>
>
> As this DFD illustrates, the net input to the program is the words the user
>enters, and the net output is the two files correct and incorrect.
As I remember, the rules for a Context Diagram state that the components of
the outputs must be present in the inputs; i.e. there can be no net
production of information (computer processes are not yet creative :-).
To apply this rule, you also need the Data Dictionary descriptions of the
data.
Files are not data, they are stores; so they don't count as "outputs" in
your diagram. I think your diagram should look like this:
------- correct_words ---------
---------- words / \ --------------> correct
| user | -------->| spell | wrong_words ---------
---------- \ / --------------> incorrect
-------- ---------
^
| correct_words
-----------
| lexicon |
-----------
where the Data Dictionary would state:
words ::= correct_words|wrong_words
(The class "words" is the sum of the classes "correct_words" and
"wrong_words")
Now the outputs only contain information derived from the inputs.
Now I've always been uncertain about prompts in DFDs, but I reason this way:
prompts are part of the mechanism of getting input data in just the same
way as commands to a disk driver (in fact, a user interface is a
user-driver :-). DFDs are concerned only with the flow of "data", by which
is meant "information", not with the mechanisms of pushing and pulling. So
prompts don't belong on a DFD. This actually follows from the rule stated
above because they contain nothing that is present in any input.
------------------------------
Date: 15 Jun 88 13:07:44 GMT
From: mnetor!utzoo!yunexus!geac!daveb@uunet.uu.net (David Collier-Brown)
Subject: Structured Analysis ques.
>In article <2449@uvacs.CS.VIRGINIA.EDU> hsd@uvacs.cs.virginia.edu.UUCP (Harry S. Delugach) writes:
>>One doesn't have to separate the two phases (requirements and design)
>>as long as the designer keeps in mind the distinction between them --
>>which decisions which are fundamental to the system's purpose and which
>>merely carry out the purpose?
In article <3668@bunker.UUCP> rha@bunker.UUCP (Robert H. Averack) writes:> I think we need to be a little careful here. It should be clear that
>one needs to know WHAT a system is supposed to do BEFORE it is possible to
>determine HOW to do it. Therefore, even if the time gap between these
>decisions is one hour, one could consider them as separate phases.
One thing to watch out for is managment misunderstanding of the
nature of specification and design. Unless you're resolving a
well-understood problem, one often has to use an iterative algorithm
to build a tree of requirements and designs:
algorithm:
think about problem set ("specification")
specify solution set ("architectural design")
for all possible solutions "S"
make "S" the new problem set
recurse ("specification" again)
on failure, backtrack
result:
topmost requirement
|
+----------------------------+
secondary requirement 1 secondary requirement 2
|
+-----------------------------------+
secondary sub-requirement 1.1 secondary sub-requirement 1.2
This raises the **nasty spectre** of having to "design" during the
specification stage. Thus you get people defining an architectural
phase, etc, ad infinitum[1].
It's a spectre, though.
In fact, all you're doing is validating the requirements: no-one
can argue that impossible requirements are valid!
--dave (I once got screamed at for asking if the database could
**do** something: that was "an optimization question") c-b
[1] The problem has about 20 variants, all trivially different. Half
of them are discussed under "mixing design with implementation".
------------------------------
End of Soft-Eng Digest
******************************