Date: Wed, 24 Feb 88 14:52:55 PST
From: jon@june.cs.washington.edu (Jon Jacky)
Subject: CASE Tool Usage
 
I have been looking at commercial CASE tools - in particular the products based
on bubbles-and-arrows diagrams (including Excelerator from Index Technology,
Teamwork from Cadre, and several others) - to consider how useful they might be
for a project my lab is embarking on - a control system for a medical cyclotron
and associated machinery for performing neutron radiation therapy for cancer.
 
Here is a memo (with references) summarizing my findings.  I emphasize that I
have NOT actually used any of these CASE tools; these conclusions are based on
surveys of journal and trade magazine articles, advertising, informal
conversations with users, and a few demonstrations I saw.
 
To summarize, I concluded that this class of CASE tools doesn't address
the problems we find most difficult, namely specifying the behavior of the
system, and designing a good set of tests.  Moreover, the bubbles-and-arrows
diagrams don't really express anything that doesn't appear in a program
outline consisting only of data declarations, procedure and function
declarations, and a program skeleton consisting only of procedure and function
calls, written in a strongly-typed language with nested scope, such as Pascal.
The bubble-and-arrow diagrams simply provide an alternate, graphic
representation of such a text.
 
One of the reasons I am submitting this to SOFT-ENG DIGEST is to learn whether
other readers believe this is a correct and fair appraisal, or whether I am
missing something.
 
- - Jonathan Jacky
University of Washington
 
(Here follows the text of my memo - bibliographic references at the end)
 
- ------------------------------------------------------------------------------
 
Structured Analysis (SA) is a catch-all term that describes the many similar
methodologies based on _data flow diagrams_ that consist of boxes and bubbles
with arcs and arrows going in and out.  One begins by deciding what the
boundary is between the system to be specified and the outside world.  Then you
draw a big box representing this boundary, and draw an arrow going into the box
for every input, and an arrow coming out of the box for every output.  You
label all the arrows, and as you do you make entries into a _data dictionary_
to keep track of these labels and what they represent.  For the cyclotron
control system, one arrow going into the box might represent the cyclotron
operator's terminal keyboard and one arrow coming out might represent the
status display screen. Then you consider the inside of the big box and you fill
it in with several other boxes, each representing a subsystem of the whole
system. You apportion the input and output arrows to the subsystem boxes and
add some more arrows to connect the subsystems, keeping the data dictionary up
to date as you go (descriptions of the operations performed by each subsystem
are also kept in the data dictionary).  Then you start a new diagram for each
subsystem box, dividing the interior of each subsystem into sub-subsystems. You
just keep going until you reach the level of detail at which you feel that the
specification is complete.
 
Structured analysis created a lot of excitement when it appeared in the mid
1970's.  Bergland provides a good review of several variants [1].
Disillusionment came when projects collapsed beneath the effort of
keeping all those diagrams and dictionaries up to date when changes had to be
made  [2].  For projects of significant size, SA is just not a practical
paper-and-pencil technique.  SA is currently enjoying a renaissance thanks to
the appearance of powerful graphics workstations.  Many vendors offer software
packages that allow you to draw the dataflow diagrams right on the screen,
meanwhile typing data dictionary entries into another window. The packages
automatically check the consistency between the various diagrams and the
dictionary, and propagate changes when they are made.  Up-to-date hardcopy can
be printed whenever it is needed.  These products are called CASE packages, for
"computer-aided software engineering."  Many shops use them and find them
very helpful.
 
Much of the appeal of SA is that the specifications suggest how to write the
program.  You just keep breaking down the subsystem boxes until you obtain
units  which are simple enough to identify with subroutines or procedures or
tasks or whatever the building blocks of your chosen programming language are.
Then you assign the units to programmers and they can start coding; everything
ought to work when you put the pieces together.  In fact some of the products
use the data dictionary and the diagrams to generate a sort of skeleton or
template program with the procedure headers and data declarations already
written in your language of choice.  Programmers need only fill in the
executable statements. [3]
 
It is important to note what SA does _not_ attempt to do.  SA addresses the
problem of breaking a big system down into subsystems; it simply begs the
question of how to specify the behavior of the subsystems.  It is still up to
the users to solve this problem.  Most SA products provide some way to associat
e
descriptive text with each subsystem.  This can be used to convey an informal
English-language description.  Some products define somewhat more formal
notations for this purpose, including programming language-like notations
called _pseudocode_ or _program development languages_ (PDL's), or special
notations for describing finite state machines.
 
Moreover, SA does not really specify how the various subsystems are invoked.
Are the various subsystems separate procedures which are invoked in turn,
perhaps in some kind of left-to-right order?  Or are they concurrent processes
which run simultaneously, each consuming the output of its predecessor as it
appears?  Both alternatives, and many others besides, are possible. SA was
originally created for business data processing and the classic data flow
diagrams left out a lot of the information needed to specify control systems,
including timing, concurrency, and synchronization.  This had to be handled in
the same old informal way.  To help remedy this, there is a variation, now
supported by several of the commercial products, in which different kinds of
arrows are used to represent data and various kinds of control signals [4,
5].  At least one vendor supports a detailed design and modelling stage in
which the subsystem boxes are translated to concurrent processes and the
various kinds of arrows are translated to the interprocess communication
mechanisms supported by the host operating system, such as queues and
mailboxes.  This product will even estimate response times to various kinds of
events. [6]
 
SA really deals with internal design and implementation more than
specification. Only the first diagram, the one consisting of a single big box,
really represents the requirements specification proper.  When the system is
very large, including hundreds of input and output signals, the graphic
representation is probably less useful than a more tabular text format.
 
A collection of data flow diagrams contains essentially the same information as
a program in Pascal (or any other strongly-typed language) consisting only of
declarations and procedure and function calls.   The data dictionary
corresponds to Pascal type declarations and variable declarations.  The various
boxes and bubbles correspond to procedure declarations.  The arcs and arrows
are the passed parameters (to be rigorous, incoming arrows should be value
parameters and outgoing arrows should be reference (Pascal "var") parameters).
The consistency checking is essentially what you get from any Pascal compiler,
which ensures that each procedure is defined before it is used, that each
procedure uses parameters consistent in number and type with its definition,
and (in many compilers) warns when a variable is used before it is set.
 
The diagrammatic representation is simply another way to view the decomposition
of a program into smaller units, which many people find helpful.  However, it
requires additional hardware and software, is less compact, and probably
requires more time to prepare, than the text representation.  Moreover, it
introduces new problems unrelated to the real goal of designing a system.  For
example, CASE product users tend to spend a lot of time working with (some
users say "struggling with") the graphics editor for data-flow diagrams, trying
to make diagrams that are attractive and easy to read.  The various products
offer more or less assistance with this, but in any case these diagrams really
ought not to be regarded the final product of the development effort. Moreover,
certain features of some products are not well-matched to subsequent stages of
development, or to good design practices in general.  For example, in one
product I saw, data dictionary entries were not written in the target
programming language, requiring a redundant manual translation step. Moreover,
the data dictionary was "flat" - data items from the various subsystems, which
should have been visible only within their own subsystems, all appeared
together in the same list with the items from the top level system that
had to be visible throughout.
 
The value CASE products offer is primarily managerial rather than technical.
They enforce the discipline of defining the data and the operations on them
before beginning coding, and provide a convenient way to generate a lot of
attractive documentation.  This is probably very valuable in many enviroments.
 
 
REFERENCES
 
1. Bergland, D.G.  Structured design methodologies, Fifteenth Annual Design
Automation Conference Proceedings, IEEE, 1978, 475 - 493. Reprinted in
Bergland, G.D. and Gordon, R.D. Software Design Strategies, IEEE Computer
Society, 1981, 297 - 315.
 
2. Yourdon, E.  Whatever happened to structured analysis?  Datamation,
June 1 1986, 133-136.
 
3. Olson C., Webb W., and Wieland R. Code generation from data flow diagrams.
Third International Workshop on Software Specification and Design.  IEEE
Computer Society, 1985, 172 - 176.
 
4. Ward, P.T.  The transformational schema: an extension of the data flow
diagram to represent control and timing.  IEEE Trans. Software Eng. SE-12(2)
February 1986, 198 - 210.
 
5. Ward, P.T. and Mellor, S.J. Structured development for real-time systems.
Yourdon, 1985.
 
6. Manuel, T. At last: a toolkit for real-time software.  Electronics,
Sept. 17, 1987, 81 - 83.
 
------------------------------