argus1@ssc-bee.UUCP (Murray Newcomb) (01/28/85)
This is for the line eater.
This is the first of five articles on a automated structure analysis
and design tool used inside of Boeing. This is being provided
because of the high response on a earlier query to the various UNIX
networks for the formation of a SIG on automated program development.
This article is taken from a newsletter internal to Boeing (and selected
companies) which was published in July 84 to clarify the analysis
(structure chart) phase of this UNIX based (sys III, V, BSD4.2) VAX,
onyx and zilog system (plus others).
Short Discussion of the Analysis of Structure Charts
A new system for the analysis of structure charts has been added
to the system. It is similar to the existing dataflow diagram
analysis, specification, and reporting system, but there are a number
of notable differences which will be discussed in this document.
The dataflow diagram system is used in the functional specification phase
of the design of a new system to describe the flow of data between components.
Dataflow diagrams and the associated specifiction sheets and data dictionary,
as provided by this system, provide an excellent way to capture high-level
abstractions and to analyze their functional decomposition.
The structure chart system provides a nuts and bolts decomposition
of program modules. Whereas dataflow diagrams are extremely abstract,
structure charts are extremely concrete and can be fruitfully used
in the detailed design phase prior to the construction of pdl and code.
Structure charts provide a graphical means to capture input and
output parameters of program modules, to show the order of execution
and hierarchical decomposition of program modules. A sample
structure chart is composed below:
+------------+
|SCAN |
|STRUCTURE |
|CHART |
+------------+
|
+--------------O-------------O----O---------------------+
|[INPUT_PARS, |[VED_DGRM, | |[BUFFER, |[<DIAGRAM_STRUCTURE>,
|{CTRL_FLAGS}, |<BUFFER>, | |{DIAGRAM_STRUCTURE}, |{ERRORS}]
|{ERRORS}] |{ERRORS}] | |{ERRORS}] |
| | | | |
v v | v v
+------------+ +------------+ | +------------+ +------------+
|ANALYZE | |READ | | |DECOMPOSE | |ANALYZE |
|EXECUTION | |DIAGRAM | | |DIAGRAM INTO| |DIAGRAM |
|PARAMETERS | |INTO BUFFER | | |COMPONENTS | |COMPONENTS |
+------------+ +------------+ | +------------+ +------------+
|
|
|[DIAGRAM_STRUCTURES, {RELATIONS},
|{ERRORS}]
|
v
+------------+
|CREATE |
|RELATIONS |
| |
+------------+
In this diagram, SCAN_STRUCTURE_CHART is the main program, and all the
module boxes below it attached by arrows are invoked in left-to-right
top-down order. The parameters that are shown are all formal parameters
of the individual modules. Actual parameters are not shown, neither
are the values that the parameters may assume. The rules for the attachment
of formal parameters to arrows are the same as the rules for the attachment
of dataflow labels to dataflow arrows, and are discussed in the scanner
document in the system user's guide. The rules for formal parameter
specification are quite simple. Formal parameters will appear in the module
specification sheet in the same order that they appear on the diagram. All
parameters are enclosed by the square brackets [ and ]. Anything appearing
inside [ and ] are input parameters unless otherwise marked. Curley braces
{ and } around a parameter will make the parameter into an output only
parameter. Angular braces, < and >, around a parameter will make the parameter
into an input or output parameter. Parameters are separated by commas and
spaces. You must reuse the angular and curley braces for each parameter in
the formal parameter specification of a module.
The power of the system for the creation of detailed design is revealed when
the module and element specification sheets are edited after the structure
chart is scanned or edited and rescanned. There the graphical representation
of the diagram is captured in a relational database. The formal parameters
appear in the order specified on the diagram, and the individual parameters
appear with the input-output attributes specified on the diagram. The modules
called by the module appear in the order they are called. The stores appear
in the order and with the parameters with which they are read and written.
Parameters can be edited as individual elements. A wealth of descriptive
detail can be added to the detailed design.
The question is often asked, "How do structure charts and dataflow diagrams
relate to each other?" In the software life cycle, the functional
specification of a system is accomplished by means of a dataflow diagram
description of the system. The detailed design of the individual modules
of the system is accomplished with the structure chart system. There is
no rigid mapping between the processes and the modules; however, the
elements which appear on structure charts are the same elements into which
data flows decompose!
It would really help if you would include your name, telephone (area
code - last time a person forgot) and address. Its hard to form
a SIG without members. Any ideas.
Murray S. Newcomb (206)-763-5138 Analyst Boeing Computer Services
P.O.Box 24346, MS 7A-04 Seattle, Washington 98124
waserman@ucsfcgl.UUCP (Tony Wasserman%MIS) (02/02/85)
There are also commercially available packages for supporting Structured Systems Analysis and Structured Design. The ones I know of are available from Tektronix and Interactive Development Environments, Inc. The Tektronix program runs on one of their displays. The IDE programs run on a Sun Workstation. I can provide more information on the IDE Dataflow Diagram Editor and the Structure Chart Editor. Call IDE at (415) 333-2122 or reply to me and I will have information sent. Tony Wasserman ucbvax!ucsfmis!waserman waserman@berkeley (ARPA)