ESE Module 3-5
Structured Design
Frank Lloyd Wright, a famous architect, once
remarked that physicians had it easy when it come to
mistakes: When they make one, they tend to bury it!
Architects, on the other hand, have to suffer with their
mistakes (and look at them) for decades. "The architect's only option, " remarked Wright, "is to plant
shrubs!"
Software developers are a lot like architects.
When they make a design mistake, they (and the
generations that come after them) have to live with it
for many years.
The legacy system (a term popularized as the
emphasis on reengineering (see ESE Component 4)
has grown) is a manifestation of the software developer's plight. Many legacy systems suffer from design
mistakes that were made years or even decades ago.
Because of these mistakes, legacy systems are hard to
fix, challenging to adapt, and difficult to change.
A rational approach to software design can help
you to eliminate many design mistakes at the beginning of the process. First, you must understand basic
design principles (ESE Module 3-4). Then you should
learn and apply an effective design method. That's
what we'll do in this ESE module.
The Design Pyramid
Design occurs in a series of layers. As we move
through each layer, the level of abstraction with
which we represent the software decreases. In the first
video segment of this ESE module, Dr. Pressman will
discuss the "design pyramid." a graphical representation of the layers that are part of software design.
The pyramid is an extremely stable structure. It has
a low center of gravity and is difficult to topple.
Software designs that are created using the design
pyramid are also stable, for reasons that will become
apparent as you read the following section and view
the video segment.
Readings
The following excerpt has been adapted from
Software Engineering: A Practitioner's Approach and
presents the layers of the design pyramid.
Data Design
Data design is the first (and some would say the most
important) of four design layers (activities) that are conducted during software engineering. The impact of data
structure on program structure and procedural complexity
causes data design to have a profound influence on software quality. Information hiding and data abstraction
provide the foundation for an approach to data design.
The process of data design is summarized by
Wasserman [1]:
The primary activity during data design is to select logical
representations of data objects (data structures) identified
during the requirements definition and specification phase.
The selection process may involve algorithmic analysis of
alternative structures in order to determine the most efficient design or may simply involve the use of a set of modules (a "package") that provides the desired operations
upon some representation of an object.
An important related activity during design is to
identify those program modules that must operate directly
upon the logical data structures. In this way the scope of
effect of individual data design decisions can be constrained.
Regardless of the design techniques to be used, welldesigned data can lead to better program structure, modularity and reduced procedural complexity.
Wasserman [1] has proposed a set of principles that
may be used to specify and design data:
1. The systematic analysis principles applied to function and
behavior should also be applied to data. We spend much time
and effort deriving, reviewing and specifying functional
requirements and preliminary design. Representations of
data flow and content should also be developed and
reviewed, data objects should be identified [see ESE
Module 3-3, parts 1 and 2], alternative data organizations
should be considered, and the impact of data modeling on
software design should be evaluated. For example, specification of a multi-ringed linked list may nicely satisfy data
requirements but may lead to an unwieldy software
design. An alternative data organization may lead to better
results.
2. All data structures and the operations to be performed on
each should be identified. The design of an efficient data
structure must take the operations to be performed on the
data structure into account. For example, consider a data
structure made up of a set of diverse data elements. The
data structure is to be manipulated in a number of major
software functions. Upon evaluation of the operation performed on the data structure, an abstract data type is
defined for use in subsequent software design.
Specification of the abstract data type may simplify software design considerably.
3. A data dictionary should be established and used to define
both data and program design. The concept of a data dictionary has been introduced [ESE Module 3-3, part 3]. A data
dictionary explicitly represents the relationships among
data objects and the constraints on the elements of a data
structure. Algorithms that must take advantage of specific
relationships can be more easily defined if a dictionary-like
data specification exists.
4. Low-level data design decisions should be deferred until late
in the design process. A process of stepwise refinement may
3-5.2 Essential Software Engineering
be used for the design of data. That is, overall data organization may be defined during requirements analysis;
refined during preliminary design work; and specified in
detail during the detail design step. The top-down
approach to data design provides benefits that are analogous to a top-down approach to software design--major
structural attributes are designed and evaluated first, so
that the architecture of the data may be established.
5. The representation of data structures should be known only to
those modules that must make direct use of the data contained
within the structure. The concept of information hiding and
the related concept of coupling provide important insight
into the quality of a software design. Principle 5 alludes to
the importance of these concepts as well as "the importance
of separating the logical view of a data object from its
physical view." [1].
6. A library of useful data structures and the operations that
may be applied to them should be developed. Data structures
and operations should be viewed as a resource for software
design. Data structures can be designed for reusability. A
library of data structure templates (abstract data types) can
reduce both specification and design effort for data.
7. A software design and programming language should support
the specification and realization of abstract data types. The
implementation (and corresponding design) of a sophisticated data structure can be made exceedingly difficult if no
means for direct specification of the structure exists. For
example, implementation (or design) of a linked list structure or a multilevel heterogeneous array would be difficult
if the target programming language was FORTRAN,
because the language does not support direct specification
of these data structures.
The principles described above form a basis for a data
design approach that can be integrated into both the definition and development phase of the software engineering
process. As we have noted elsewhere, a clear definition of
information is essential to successful software development.
Architectural Design
The primary objective of architectural design is to develop
a modular program structure and represent the control
relationships between modules. In addition, architectural
design melds program structure and data structure, defining interfaces that enable data to flow throughout the program.
To understand the importance of architecture design,
we present a brief story from everyday life:
You've saved your money, purchased a beautiful
piece of land and have decided to build the house of your
dreams. Having no experience in such matters, you visit a
builder and explain your desires (e.g., number and size of
rooms, contemporary styling, spa (of course!), cathedral
ceilings, lots of glass, etc.). The builder listens carefully,
asks a few questions, and then tells you that he'll have a
design in a few weeks.
As you wait anxiously for his call, you conjure up
many different (and outrageously expensive) images of
your new house. What will he come up with? Finally, the
design is finished and you rush to the builder's office.
Pulling out a large manila folder, the builder spreads a
diagram of the plumbing for the second-floor bathroom in
front of you and proceeds to explain it in great detail.
"But what about the overall design?" you say.
"Don't worry," says the builder, "we'll get to that later.
Does the builder's approach seem a bit unusual? Does
our hero feel comfortable with the builder's final response?
Of course not! Anyone would first want to see a sketch of
the house, a floor plan, and other information that will provide an architectural view. Yet many software developers
act like the builder in our story. They concentrate on the
plumbing (procedural details and code) to the exclusion of
the software architecture.
Design methods encourage a software engineer to concentrate on architectural design before worrying about the
plumbing. Although each method has a different approach
to architectural derivation, all recognize the importance of
a holistic view of software.
Interface Design
The overall process for designing a user interface begins
with the creation of different models of system function (as
perceived from the outside). The human- and computeroriented tasks that are required to achieve system function
are then delineated; design issues that apply to all interface
designs are considered; tools are used to prototype and
ultimately implement the design model; and the result is
evaluated for quality.
Four different models come into play when a humancomputer interface (HCI) is to be designed. The software
engineer creates a design model; a human engineer (or the
software engineer) establishes a user model the end user
develops a mental image that is often called the user's
model or the system perception; and the implementers of
the system create a system image. [2] Unfortunately, each
of these models may differ significantly. The role of interface design is to reconcile these differences and derive a
consistent representation of the interface.
A design model of the entire system incorporates data,
architectural and procedural representations of the software. The requirements specification may establish certain
constraints that help to define the user of the system. For
interactive systems, the interface design is as important as
the data, architectural and procedural design.
The user model depicts the profile of end users of the
system. To build an effective user interface, "all design
should begin with an understanding of the intended users,
including profiles of their age, sex, physical abilities, education, cultural or ethnic background, motivation, goals
and personality." [3] In addition, users can be categorized
 novices--no syntactic knowledge [knowledge of the
mechanics of interaction] of the system and little semantic
knowledge [an understanding of the functions that are performed, the meaning of input and output, and the goals
and objectives of the system] of the application or computer usage in general;
 knowledgeable, intermittent users-reasonable semantic
Structured Design ·· 3-5.3
knowledge of the application, but relatively low recall of
syntactic information necessary to use the interface;
 knowIedgeabIe, frequent users--good semantic and syntactic knowledge that often leads to the power-user syndrome, that is, individuals who look for short cuts and
abbreviated modes of interaction.
[3] Shneiderman, B., Designing the User Interface, AddisonWesley, 1987. O
Architectural Design
When an architect presents the design of the house, it
is likely that she will first show you a three-dimensional
The system perception (user's model) is the image of the
perspective of the structure so that you will undersystem that an end user carries in his or her head. For
stand what it looks like before its ultimate implementaexample, if the user of a particular word processor were
tion in the real world. In addition, the architect will
asked to describe its operation, the system perception
depict the internal layout of the house by showing
would guide the response. The accuracy of the description
you a floor plan in which each living component
will depend upon the user's profile (e.g., novices would
(room) and its interfaces will be shown. Electrical
provide a sketchy response at best) and overall familiarity
wiring diagrams, plumbing schematics, the foundawith software in the application domain. A user who
tion plan, exterior wall construction detail, and roofing
understands word processors fully, but has only worked
trusses are all part of the design, but initially, this inferwith the specific word processor once, might actually be
mation is unimportant -- initially we are interested in
able to provide a more complete description of its function
obtaining a big picture view of the design representathan the novice who has spent weeks trying to learn the
tion.
system.
The modes of representation for computer softThe system image combines the outward manifestation
ware and the overall design approach are remarkof the computer-based system (the look and feel of the
ably similar to those that the architect uses for a
interface), coupled with all supporting information (books,
house. Architectural design focuses on the creation of
manuals, video tapes) that describe system syntax and
the "floor plan" for computer software. Instead of
semantics. When the system image and the system percepshowing the layout of rooms and their sizes, an archition are coincident, users generally feel comfortable with
tectural design for software shows the layout of prothe software and use it effectively. To accomplish this
gram components (modules) and their control hierarmelding of the models, the design model must have been
chy, also referred to as connectivity. The "doorways
developed to accommodate the information contained in
and windows" for the software are represented as
the user model, and the system image must accurately
module interface specifications in which all incoming
reflect syntactic and semantic information about the interand outgoing data are represented. The "plumbing
face.
and electrical layouts" for software are postponed
In essence, these models enable the interface designer
until procedural design.
to satisfy a key element of the most important principle of
The most commonly used approach for architecuser interface design: "Know the user; know the tasks."
tural design is called structured design. Structured
design maps a floor plan for software using a data
Procedural Design
flow model created during software requirements
analysis work.
Procedural design occurs after data and program structure
have been established. In an ideal world, the procedural
Readings
specification required to define algorithmic details would
be stated in a natural language such as English. After all,
The following excerpt has been adapted from
members of a software development organization all speak
Software Engineering: A Practitioner's Approach and
a natural language (in theory, at least); people outside the
presents a detailed discussion of structured design.
software domain could more readily understand the speciStructured design allows a convenient transition from
fication, and no new learning would be required.
information representations, the data flow diagram (DFD),
Unfortunately, there is one small problem. Procedural
contained in a Software Requirements Specification to a
design must specify procedural detail unambiguously, and
design description of program structure. The transition from
a lack of ambiguity in a natural language is not natural.
information flow to structure is accomplished as part of a
Using a natural language, we can write a set of procedural
five-step process: (1) the type of information flow is estabsteps in too many different ways. We frequently rely on
context to get a point across. We often write as if a dialogue with the reader were possible (it isn't). For these and
many other reasons, a more constrained mode for representing procedural detail must be used.
[1] Wasserman, A., "Principles of Systematic Data Design
and Implementation," in Software Design Techniques, 3rd
edition, IEEE Computer Society Press, 1980, p. 287-293.
[2] Rubin, T., User Interface Design for Computer Systems,
Halstead Press, 1988.
3-5.4 ·· Essential Software Engineering
lished; (2) flow boundaries are indicated; (3) the DFD is
mapped into program structure; (4) control hierarchy is
defined by factoring; (5) resultant structure is refined
using design measures and heuristics. The information
flow type is the driver for the mapping approach required
in Step 3. In the following paragraphs we examine two
flow types map to transaction structure.
Transform Flow
Recalling the context model (level 0 data flow diagram),
information must enter and exit software in an external
world form. For example, data typed on a keyboard, tones
on a telephone line, and pictures on a computer graphics
display are all forms of external world information. Such
externalized data must be converted into an internal form
for processing.
Information enters the system along paths that transform external data into an internal form and shall be identified as incoming flow. At the kernel of the software, a transition occurs. Incoming data are passed through a transform center and begin to move along paths that now lead
"out" of the software. Data moving along these paths are
called outgoing flow. The overall flow of data occurs in a
sequential manner and follows one or only a few, straight
line paths. When a segment of a data flow diagram
exhibits these characteristics, transform flow is present.
map to transaction structure;
endif
factor the structure;
refine the structure;
develop interface and data descriptions;
enddo
Design begins with an evaluation of the level 2 or level 3
data flow diagram. The information flow category (i.e.,
transform or transaction flow) is established, and flow
boundaries that delineate the transform or transaction center are defined. Based on the location of boundaries, transforms (the DFD 'bubbles") are mapped into program structure as modules. The precise mapping and definition of
modules is accomplished by distributing control top-down
in the structure (called factoring) and applying guidelines
for effective modularity described in [ESE Module 3-4].
TRANSFORM ANALYSIS
Transform analysis is set of design steps that allows a DFD
with transform flow characteristics to be mapped into a
predefined template for program structure. In this section,
transform analysis is described by applying design steps to
an example system--a portion of a home security system
called SafeHome.
An Example
Transaction Flow
The context model implies transform flow; therefore, it is
possible to characterize all data flow in this category.
However, information flow is often characterized by a single data item, called a transaction, that triggers other data
flow along one of many paths. When a DFD takes the form
shown in Figure 14.2 SAPE, transaction flow is present.
Transaction flow is characterized by data moving
along an incoming path that converts external world infermation into a transaction. The transaction is evaluated,
and based on its value, flow along one of many action
paths is initiated. The hub of information flow from which
many action paths emanate is called a transaction center.
It should be noted that within a DFD for a large system, both transform and transaction flow may be present.
For example, in a transaction-oriented flow, information
flow along an action path may have transform flow characteristics.
The SafeHome security system is representative of many
computer-based products and systems in use today. The
product monitors the real world and reacts to changes that
it encounters. It also interacts with a user through a series
of typed inputs and alphanumeric displays. The level 0
data flow diagram for SafeHome, is shown in Figure 1.
A Process Abstract
The overall approach to data flow-oriented design is illustrated in the pseudocode that follows:
refine the data flow diagram;
do while (design issues remain to be resolved)
if flow type = transform then
identify incoming/outgoing branches;
map to transform structure;
else
identify transaction center;
identify data acquisition path;
During requirements analysis, more detailed flow models
would be created for SafeHome. In addition, control and
process specifications, a data dictionary, and various
behavioral models would also be created.
Design Steps
The above example will be used to illustrate each step in
transform analysis. The steps begin with a re-evaluation of
Structured Design ·· 3-5.5
work done during requirements analysis and then move to
the development of program structure.
monitor sensors subsystem and we proceed without further refinement.
Step 1. Review the fundamental system model. The fundamental system model encompasses the level 0 DFD and
supporting information. In actuality the design step begins
with an evaluation of both the System Specification and the
Software Requirements Specification. Both documents
describe information flow and structure at the software
interface. Figures 1 and 2 depict level O and level 1 data
flow for the SafeHome software.
Step 2. Review and refine data flow diagrams for the
software. Information obtained from analysis models contained in the Software Requirements Specification is
refined to produce greater detail. For example, the level 2
DFD for monitor sensors (Figure 3) is examined, and a
level 3 data flow diagram is derived as shown in Figure 4.
At level 3, each transform in the data flow diagram exhibits
relatively high cohesion. That is, the process implied by a
transform performs a single, distinct function that can be
implemented as a module in the SafeHome software.
Therefore, the DFD in Figure 4 contains sufficient detail
for a "first cut" at the design of program structure for the
Step 3. Determine whether the DFD has transform or
transaction flow characteristics. In general, information
flow within a system can always be represented as transform. However, when an obvious transaction characteristic is encountered, a different design mapping is recommended. In this step, the designer selects a global (software-wide) flow characteristics based on the prevailing
nature of the DFD. In addition, local regions of transform
or transaction flow are isolated. These subflows can be
used to refine program structure derived from a global
characteristic described above. For now, we focus our
attention only on the monitor sensors subsystem data flow
depicted in Figure 4.
Evaluating the DFD (Figure 4), we see data entering
the software along one incoming path and exiting along
three outgoing paths. No distinct transaction center is
implied (although the transform acquire alarm conditions
could be perceived as such). Therefore, an overall transform characteristic will be assumed for information flow.
Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries. In the preceding section, incoming flow was described as a path in which infermation is converted from external to internal form; outgoing flow converts from internal to external form. Incoming
and outgoing flow boundaries are open to interpretation.
That is, different designers may select slightly different
points in the flow as boundary locations. In fact, alternative design solutions can be derived by varying the placement of flow boundaries. Although care should be taken
when boundaries are selected, a variance of one bubble
along a flow path will generally have little impact on the
final program structure.
Flow boundaries for the digital dashboard example are
illustrated in Figure 5. The transforms (bubbles) that comprise the transform center lie within the two shaded
boundaries that run from top to bottom in the figure. An
argument can be made to readjust a boundary (e.g. an
incoming flow boundary separating read sensors and
acquire response info could be proposed). The emphasis
in this design step should be on selecting reasonable
3-5.6 ·· Essential Software Engineering
boundaries, rather than lengthy iteration on placement of
divisions.
Step 5. Perform first-level factoring. Program structure
represents a top-down distribution of control. Factoring
results in a program structure in which top-level modules
perform decision making and low-level modules perform
most input, computational and output work. Middle-level
modules perform some control and do moderate amounts
of work.
When transform flow is encountered, a DFD is
mapped to a specific structure that provides control for
incoming, transform, and outgoing information processing.
This first-level factoring is illustrated in Figure 6. A main
controller resides at the top of the program structure and
serves to coordinate the following subordinate control
functions:
 an incoming information processing controller coordinates receipt of all incoming data;
 a transform flow controller supervises all operations
on data in internalized form (e.g., a module that invokes
data transformation procedures);
 an outgoing information processing controller coordinates production of output information.
Although a three-pronged structure is implied by
Figure 6, complex flows in large systems may dictate two
or more control modules for each of the generic control
functions described above. The number of modules at the
first level should be limited to the minimum that can
accomplish control functions and still maintain good coupling and cohesion characteristics.
Continuing the monitor sensors subsystem for
SafeHome, first-level factoring is illustrated as a structure
in Figure 7. Each control module is given a name that
implies the function of subordinate modules it controls.
Step 6. Perform second-level factoring, Second-level factoring is accomplished by mapping individual transforms
(bubbles) of a DFD into appropriate modules within the
program structure. Beginning at the transform center
boundary, and moving outward along incoming and then
outgoing paths, transforms are mapped into subordinate
levels of the software structure. The general approach to
second-level factoring is illustrated in Figure 8.
Although Figure 8 illustrates a one-to-one mapping
between DFD transforms and software modules, different
mapping frequently occur. Two or even three bubbles can
be combined and represented as one module (recalling
potential problems with cohesion) or a single bubble may
be expanded to two or more modules. Practical considerations and measures of design quality dictate the outcome of
second-level factoring.
Program structure derived from the outgoing flow
paths of the DFD is shown in Figure 9. A simple one-toone mapping of bubbles to modules can be observed by
following flow from the transform center boundary outward. Review and refinement may lead to changes in this
structure, but it can serve as a first-cut design.
Structured Design ·· 3-5.7
The narrative serves as a first generation Design
Specification. However, further refinement and additions
occur regularly during this period of design.
Step 7. Refine the first-cut program structure using
design heuristics for improved software quality. A firstcut program structure can always be refined by applying
concepts of module independence. Modules are exploded or
imploded to produce sensible factoring, good cohesion, minimal coupling, and most importantly, a structure that can
be implemented without difficulty, tested without confusion, and maintained without grief.
Refinements are dictated by practical considerations
and common sense. There are times, for example, when the
controller for incoming data flow is totally unnecessary,
when some input processing is required in a module that is
subordinate to the transform controller, when high coupling due to global data cannot be avoided or when optimal structural characteristics cannot be achieved. Software
requirements coupled with human judgment is the final
arbiter.
Second-level factoring for incoming flow follows in the Many modifications can be made to the first-cut strucsame manner. Factoring is again accomplished by moving
ture developed for the SafeHome monitor sensors subsysoutward from the transform center boundary on the
tem. Among many possibilities: (1) the incoming controller
incoming flow side. The transform center of monitor sencan be removed in that it is unnecessary when a single
sors subsystem software is mapped somewhat differently.
incoming flow path is to be managed; (2) the substructure
Each of the data conversion or calculation transforms of the
generated from the transform flow can be imploded into
transform portion of the DFD is mapped into a module
the module establish alarm conditions, which will now
subordinate to the transform controller. A completed firstinclude the processing implied by select phone number
cut program structure is shown in Figure 10.
(The transform controller will not be needed and the small
The modules mapped in the manner described above
decrease in cohesion is tolerable); (3) the modules format
and shown in Figure 10 represent an initial design of prodisplay and generate display can be imploded (we assume
gram structure. Although modules are named in a manner
that display formatting is quite simple) into a new module
that implies function, a brief processing narrative (adapted
called produce display. The refined software structure for
from the PSPEC created during analysis modeling) should
the monitor sensors subsystem is shown in Figure 11.
be written for each. The narrative describes:
 information that passes into and out of the module (an
interface description);
 information that is retained by a module, e.g. data
stored in a local data structure;
 a procedural narrative that indicates major decision
points and tasks;
 a brief discussion of restrictions and special features
(e.g, file I/O, hardware dependent characteristics, special
timing requirements).
The objective of the preceding seven steps is to develop a global representation of software. That is, once structure is defined, we can evaluate and refine software architedure by viewing it as a whole. Modifications made at
this time require little additional work yet can have a profound impact on software quality and maintainability.
The reader should pause for a moment and consider
the difference between the design approach described
above and the process of "writing programs." If code is the
only representation of software, the developer will have
great difficulty evaluating or refining at a global or holistic
level and will, in fact, have difficulty "seeing the forest for
the trees."
3-5.8 ·· Essential Software Engineering
TRANSACTION ANALYSIS
In many software applications, a single data item triggers
one or a number of information flows that effect a function
implied by the triggering data item. The data item, called a
transaction, and its corresponding flow characteristics were
discussed earlier. In this section we consider design steps
used to treat transaction flow.
An Example
Transaction analysis will be illustrated by considering the
user interaction subsystem of the SafeHome software.
Level 1 data flow for this subsystem is shown as part of
Figure 2. Refining the flow, level 2 data flow diagram (a
corresponding data dictionary, CSPEC and PSPECs would
also be created) is developed and shown in Figure 12.
Referring to the figure, user commands flows into the
system and results in additional information flow along
one of three action paths. A single data item, command
type, causes the data flow to fan outward from a hub.
Therefore, the overall data flow characteristic is transaction-oriented.
It should be noted that information flow along two of
the three action paths accommodates additional incoming
flow (e.g., system parameters and data are input on the
configure action path. Each action path flows into a single
transform, display messages and status.
Design Steps
acteristic. However, flow along two of the action paths
emanating from the invoke command processing bubble
appears to have transform flow characteristics. Therefore,
flow boundaries must be established for both flow types.
Step 4. Identify the transaction center and the flow characteristics along each of the action paths. The location of
the transaction center can be immediately discerned from
the DFD. The transaction center lies at the origin of a number of action paths that flow radically from it. For the flow
shown in Figure 12, the invoke command processing bubble is the transaction center.
The incoming path (i.e., the flow path along which a
transaction is received) and all action paths must also be
isolated. Boundaries that define a reception path and
action paths are isolated. Each action path must be evaluated for its individual flow characteristic. For example, the
password path has transform characteristics. Incoming,
transform and outgoing flows are indicated with boundaries.
Step 5. Map the DFD in a program structure amenable to
transaction processing. Transaction flow is mapped into a
program structure that contains an incoming branch and a
dispatch branch. Structure for the incoming branch is
developed in much the same way as transform analysis.
Starting at the transaction center, bubbles along the incoming path are mapped into modules. The structure of the
dispatch branch contains a dispatcher module that controls
all subordinate action modules. Each action flow path of
the DFD is mapped to a structure that corresponds to its
specific flow characteristics. This process is illustrated in
Figure 13.
Design steps for transaction analysis are similar and in
some cases identical to steps for transform analysis. A
major difference lies in the mapping of DFD to software
structure.
Step 1. Review the fundamental system model.
Step 2. Review and refine data flow diagrams for the
software.
Step 3. Determine whether the DFD has transform or
transaction flow characteristics. Steps 1, 2 and 3 are identical to corresponding steps in transform analysis. The
DFD shown in Figure 12 has a classic transaction flow char-
Considering the user interaction subsystem data flow,
first-level factoring for step 5 is shown in Figure 14. The
bubbles read user command and activate/deactivate system map directly into the program structure without the
need for intermediate control modules. The transaction
center, invoke command processing, maps directly into a
dispatcher module of the same name. Controllers for system configuration and password processing are
mapped as indicated in Figure 12.
Structured Design ·· 3-5.9
Exercise 3-12,
Mapping DFDs Into a
Program Architecture
Review the data flow diagrams that you created as
part of Exercise 3-8 (ESE Module 3-3, part 2).
1. Refine the DFDs to a level at which each bubble is
functionally cohesive.
2. Attempt the mapping techniques that were
described in the above reading.
3. Review your results with colleagues.
Step 6. Factor and refine the transaction structure and the
structure of each action path. Each action path of the data
flow diagram has its own information flow characteristics.
We have already noted that transform or transaction flow
may be encountered. The action path-related substructure
is developed using the design steps discussed in this and
the preceding section.
As an example, consider the password processing
information flow shown in Figure 12. The flow exhibits
classic transform characteristics. A password is input
(incoming flow) and transmitted to a transform center,
where it is compared against stored passwords. An alarm
and warning message (outgoing flow) are then produced.
The configure path is drawn similarly using the transform
mapping. The resultant program structure is shown in
Figure 15.
Step 7. Refine the first-cut program structure using
design heuristics for improved software quality. This
step for transaction analysis is identical to the corresponding step for transform analysis. In both design approaches,
criteria such as module independence, practicality (efficacy
of implementation and test), and maintainability must be
carefully considered as structural modifications are proposed.
Procedural Design
Software design should always be modularized to create a set of program components (also called procedures, modules, functions). It is the internal workings of
a program component (module) that absorb our
attention during procedural design.
Every program component programs a specific
transformation on some portion of the information that
is processed by an application. In essence, a program
component accepts control information or data
objects, applies an algorithm to modify control or
data in some way, and then produces the modified
information as output. In executing its processing
algorithm, the program component may invoke other
program components, may create and destroy local
data, and may make use of global data. The algorithm may be as simple as a straight line sequence of
processing steps or as complex as recursive, multiplenested compound logic.
During procedural design, a software engineer
represents the algorithmic detail of a program component. The representation must properly indicate
how information will be transformed within the component, and must also be consistent with the interface between the component and other parts of the
application.
Procedural design is something that every programmer does--whether he or she realizes it or not.
Whenever you "write" a program using source code,
you are creating a procedural design representation.
In theory, this approach is reasonable, but in practice,
it has proven to be less than adequate. Using source
code as our procedural design representation does
not lend itself well to an important technique for deriv-
3-5.10 ·· Essential Software Engineering
ing algorithmic transformations--a technique that we
call stepwise refinement or stepwise elaboration. It
forces us to represent the procedural design at a low
level of abstraction--a level of detail that can sometimes be difficult to understand and is inherently programming language specific. It discourages review,
because of the amount of information that must be
considered when each component is evaluated.
For these and other reasons, the software engineering approach to procedural design makes use of
an intermediate representation that is either graphical
or textual in nature.
Readings
The following excerpt has been adapted from
Software Engineering: A Pracfitioner's Approach and
presents a brief discussion of structured programming.
The foundation for procedural design was formed in the
early 1960s. During this period, researchers proposed the
use of a set of existing logical constructs from which any
program could be formed. The constructs emphasized
"maintenance of functional domain." That is, each construct had a predictable logical structure, was entered at
the top and exited at the bottom, enabling a reader to follow procedural flow more easily.
The constructs are sequence, condition, and repetition.
Sequence implements processing steps that are essential in
the specification of any algorithm. Condition provides the
facility for selected processing based on some logical occurrence, and repetition provides for looping. These three
constructs are fundamental to structured programming--an
important design technique in the broader field that we
have learned to call software engineering.
Structured programming suggests that all procedural
design be limited to three logical constructs: the sequence,
the conditional, and the loop. Over the years, the conditional and loop constructs have been given names: if-thenelse and do-while/repeat-unti1, respectively.
The structured constructs were proposed to limit the
procedural design of software to a small number of predictable operations. Complexity metrics indicate that the
use of the structured constructs reduces program complexity and thereby enhances readability, testability and maintainability. The use of a limited number of logical constructs also contributes to a human understanding process
that psychologists call chunking. To understand this
process, consider the way in which you are reading this
page. You do not read individual letters, but rather, you
recognize patterns or chunks of letters that form words or
phrases. The structured constructs are logical chunks that
allow a reader to recognize procedural elements of a module, rather than reading the design or code line by line.
Understanding is enhanced when readily recognizable logical forms are encountered.
Any program, regardless of application area or technical complexity, can be designed and implemented using
only the three structured constructs. It should be noted,
however, that dogmatic use of only these constructs can
sometimes cause practical difficulties.
Exercise 3-13,
Procedural Design
You'll recall that in ESE Module 3-3. part 3, a process
called AnalyzeTriangle was described. Input values A
B. and C representing the sides of a triangle, are analyzed to determine the output value, TYPE. that indicated whether the input is an equilateral, isosceles or
scalene triangle. An ERROR value is also output to indicate that no triangle exists or some other data error.
1. Develop your first elaboration of the procedural
design. This elaboration should contain no more than
six steps.
2. Refine your first elaboration by expanding each of
the steps. Your second elaboration should contain no
more than 12 to 18 steps. At this point, you should
begin to introduce the structured programming constructs.
3. Complete your procedural design by developing
a detailed PDL representation of the program component.
4. Review your work with one or more colleagues.
Structured Design ·· 3-5.11
Post-Test, Module 3-5
This post-test has been designed to help you assess
the degree to which you've absorbed the information
presented in this ESE module.
Structured Design
1. Data design translates data objects developed
during data modeling into:
a. data structures
b. modules
c. structured programming constructs
d. the program architecture
2. We partition the program architecture both horizontally and vertically. The primary reason for doing
this is:
a. to make the program easier to code
b. to make the program easier to design
c. to make the program easier to change
d. all of the above
e. none of the above
3. Factoring leads to a program architecture in
which:
a. all modules do the same amount of work
b. worker modules reside at the top of the
architecture
c. worker modules reside at the bottom of
architecture
d. decision making happens in just one module
e. none of the above
4. Module a invokes modules b, c, and d. A change
in module a affects a module named f.
This represents:
a. a violation of the scope of effect, scope of
control rule
b. a violation of structured programming
c. proper application of scope of effect, scope
of control rule
d. proper application of structured
programming
5. The first step in mapping a data flow diagram into
a program architecture is to:
a. determine the architecture hierarchy
b. determine the flow type
c. determine the module names
d. define a set of mapping rules
6. A structure chart is just another name for the:
a. flowchart
b. program architecture
c. data structure
d. none of the above
7. Transform mapping is performed when the data
flow:
a. has a linear characteristic and can be
partitioned into incoming and outgoing flow
paths
b. has a linear characteristic and can be
partitioned into decision paths
c. has a linear characteristic and can be
partitioned into mapping paths
d. has been refined to level 2
8. The architecture that results as a consequence of
transform mapping will typically have how may controllers beneath the executive module?
a. 2
b. 3
c. 4
d. 5
9. Data flow through a transform-mapped architecture flows:
a. up
b. down
c. up-down-up-down
d. there is no data flow through the architecture
10. One of the first things that you'll have to isolate
during transaction mapping is:
a. the transaction data object
b. the transaction architecture
c. the transaction value
d. the transaction center
11. How many basic constructs are needed to
design a program that conforms completely to the
principles of structured programming?
a. 3
b. 4
c. 5
d. 6
12. To prove that a loop has been properly characterized as part of a procedural design, you have to
identify:
a. the loop variable
b. the loop index
c. the loop invariant
d. all of the above
e. none of the above
Copyright 1995 R.S. Pressman & Associates, Inc.
No part of this material may be electronically copied,
transmitted, or posted without the express written
permission of R.S. Pressman & Associates, Inc.
These materials have been posted on the Local Web
Server of the Department of Computer Science with
permission of R.S. Pressman & Associates, Inc. and are
for use only by students registered for DCS/235 at
Queen Mary and Westfield College.