FREE ESSAY ON STRUCTURED DESIGN

STRUCTURED DESIGN

Introduction
Structured Design is a method to convert an ``informal specification'' including a set of
data flow diagrams and process specifications into a design that could be implemented
using a language like Pascal or C. It was developed by Edward Yourdon and Larry
Constantine, reportedly by examining a number of systems that had been developed in the
1960's that were regarded as good design examples, and identifying common features and
patterns that they contained. 
Structured Design does not produce designs that have a number of desirable properties: 
? It doesn't take advantage of the newer features provided by object-oriented programming
languages. While structured design provides some limited support for ``encapsulation of
data'' (information hiding) it doesn't really support inheritance or templates, so it
doesn't help you to take advantage of opportunities for reuse of software. 
? It doesn't produce designs that are suitable for ``highly interactive'' systems - that
is, systems which the user interacts with the system using a mouse as well as a terminal,
so that the user has more control over the order in which things are done, than is
generally provided by systems that use a ``command line'' interface, or that rely on
simple menus that could be used with a terminal, rather than on a workstation or PC
running a windowing system. These simpler interfaces (command line, and simple menu based
ones) were the only ones in widespread use when this design method was developed. 
? It doesn't produce designs that are useful for real time systems, or other systems in
which performance requirements play a greater role than they do in more traditional
business systems. We will continue to assume, as is still usually the case, that it's
sufficient (and therefore appropriate) to design and implement without much consideration
of performance requirements - and, after that, we'll perform tests that include
``performance tests,'' in order to look for evidence that resource requirements haven't
been met, find bottlenecks, and then recode (and possibly also redesign) where needed. 
? It doesn't lead to innovative or elegant designs. Techniques like these can be used to
deal with the 90% (or more) of the system that is routine - just like most of the same
systems that solve this kind of problem - and that can be dealt with well enough using
straightforward, conventional methods. The use of this kind of method will (arguably)
free up more of your time for those parts of the problem that do require innovation or
expertise. 
However, Structured Design does provide usable, maintainable designs for the type of
programs (and programming languages) it supports. As well, highly interactive and real
time systems often include subsystems that can be developed using this older method, so
it may still be useful. 
Finally, some of the ideas we'll see by studying this method have been carried forward
into some of the more modern design techniques. The newer methods are more complicated
and not (yet) as well described as Structured Design, so (one hopes that) this is a
useful ``example of a design method'' to study before considering a more modern one. 
Structured Design is discussed in Pressman's text, Software Engineering: A Practitioner's
Approach. Another more detailed (and very readable) reference is the book by Page-Jones
which is on reserve in the library: 
M. Page-Jones
The Practical Guide to Structured Systems Design
Second Edition, Prentice Hall (Yourdon Press), 1988 
Structure Charts
Structured Design can be used to convert a set of data flow diagrams and process
specifications into a design specification that includes 
? a structure chart, which shows the system's modules and data areas, their control
structure, and the I/O between them; 
? a module specification for each of the modules in the structure chart (as well as for
the interface for each data area). 
More will be said about module specifications later on; we'll start by considering the
components of a structure chart. 
Modules
A module corresponds to a single function or procedure in a language like FORTRAN or
Pascal, or to a single function in C or C++ (but, not generally to an ``object'' or
``class'' in C++). 
A module is drawn as a rectangle, labeled by the module's name - which should also be a
reasonable name for a function or procedure (or, occasionally, subsystem) in the program
being developed. Here are two examples. 
The above notation is used to represent modules for procedures we'll need to develop
ourselves. It's also useful (or necessary) to show ``library modules'' that are part of
the operating system (or windowing system, or, more generally, software library or
libraries) that supports the system we're developing - that is, modules that we don't
need to develop ourselves. An extra vertical bar on each side of the rectangle is used to
identify these: 
A Control Hierarchy
A structure chart includes one main module - the module at the top of the structure
chart, which corresponds to the ``main'' part of the program being produced. Each module
is connected to all the modules that it calls directly. This connection is shown by
having an arrow pointing from the calling module to the module it can call. 
This design technique doesn't seem to introduce recursive functions (by itself). However,
you certainly might add these as you improve the structure chart at the end of
``architectural design,'' so you might end up drawing an arrow that connects a module to
itself, etc. 
Data Areas
A structure chart also include representations of ``data areas.'' In the ``first draft''
structure charts that we obtain at the beginning of structured design, we'll draw a data
area by listing the data area's name between two horizontal lines: 
However, the time the structure chart has been completed, we will have identified a set
of interface functions used for all communication between the data area and the rest of
the system - that is, we should have completed at least the beginning steps of data
design. At that point, the data area (also now called an informational cluster) will be
drawn as follows: 
The boxes at the top are labeled with the names of each of the interface functions that
can be used by the rest of the system to access (or change) the data area that is now
shown below them. 
In a ``draft'' or ``first cut'' structure chart, you would draw arrows from each one of
the modules (in the rest of the system) that could access the data area, down to the top
horizontal line in the representation of the data area. In the ``completed'' structure
chart, each of these modules (from the rest of the system) must call one or more of the
``interface'' functions - so you'd draw the arrows down to the box (or boxes) for the
interface function (or interface functions) that the module calls. 
It doesn't ever make sense to show an arrow going up from a data area or informational
cluster to another module in the system, because (it's generally the case) that the
``data area'' is passive, and can't call (or, therefore, ``control'') anything else. 
You can also use this ``informational cluster'' notation to group together a set of
``interface functions'' that collectively provide access to an I/O device, so that the
part of the system that communicates directly with that device - and would need to be
modified if that device was replaced - are grouped together, and easy to find. 
Unfortunately, you won't find any reference to these ``informational clusters'' in
Pressman's books; they're included (in Chapter 7) in Page-Jones' book on Structured
Design. I believe they're also a recent addition to the notation and the method,
representing a good idea that's been borrowed from object-oriented development - namely,
a good extension of this older design technique to facilitate ``information hiding'' (and
combine it better with ``data design''). 
Data Flow
The structure chart also shows data that can be passed between modules (or between
modules and interface functions for data areas or I/O devices). Two symbols are used for
data items - one for ``regular'' data items, and another for ``control signals'' - which
you can think of as corresponding to someone pushing a button (and which would be drawn
on augmented data flow diagrams using dashed arrows, as previously described. 
A ``regular'' item is drawn using a short arrow, with a hollow circle at the one end of
the arrow (and the arrow head at the other). This is labeled by the name of the data
item. 
A ``control signal'' is drawn using almost the same symbol: The circle at the end of the
arrow is filled in, rather than hollow. It is labeled by the name of the control signal.

The data flows are drawn close to (`flowing along'') the connections between modules, or
between modules and interface functions, and each point from the module or function
sending the data to the module or function receiving it. Each of these connections
between modules corresponds to a (possible) procedure call - so you'd generally have data
flows down to the called module corresponding to each of the inputs provided by the
module calling it, and you'd have data flows back up from the called modules
corresponding to each of the outputs that the called module might return. 
For example, the following diagram shows that the module ``Register Student'' can call
the module ``Get ISBN Number,'' and that ``Get ISBN Number'' can return a control signal,
``cancel,'' and a ``regular'' data item, ``ID number,'' as input. (Yes, this example is
nonsensical; the diagram will be fixed as soon as time permits!) 
(Lack of) Terminators
The structure chart does not generally include anything that corresponds directly to the
``Terminators'' on data flow diagrams - that is, to the people or other systems that the
system being developed interacts with. It also does not generally include any of the data
flows between the system and these terminators. 
Off Page Connectors
There is one more symbol that isn't ``standard'' - you might not even find it in
Page-Jones' book - but that does seem necessary (and that is, in fact, a standard flow
chart symbol) - the Off Page Connector. 
If you've run out of room at the bottom of page then, instead of having an arrow down to
another module that's to be called, draw the arrow as going down to the top of one of
these connectors. Label the connector ``To (name of module you're calling)'' by writing
this message inside it, and put the number of the page that will contain the module being
called, beside the connector. Show the data flowing to and from the called module beside
the arrow to the connector, just as you would if it pointed directly to the module
instead. 
On the page that contains the called module, show a matching off page connector at the
top. Label this with ``From (module that did the calling)'' and put the page number of
the module that called this one beside the connector. Draw an arrow from the bottom point
of the connector down to the called module and reproduce the data flowing from and back
to the calling module along this connection. 
With the possible exception of this addition of an ``off page connector,'' the notation
described here matches the notation used by Page-Jones exactly, in his book on Structured
Design. You can find quite a few examples of structure charts in that book, if you'd like
to see a complete one now. A few of these will be appearing in the next pages of online
notes. 
Steps to Follow
Structured Design consists of two major steps: 
1. Produce a ``First Cut'' Structure Chart 
2. Evaluate and improve the structure chart until a usable structure chart has been
obtained 
The first step starts with the data flow diagrams and consists of lots of small decisions
and tests. The second step provides a way to improve the result of first step (which we
don't generally expect to be very good). Since the second step does exist, it isn't
necessary to worry too much about how to make some of the decisions in the first step if
they aren't clear - you will have an opportunity to improve the structure chart that you
create by making these decisions later on.