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 archi-
tect'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 devel-
oper'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 begin-
ning 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.
TheDesignPyramid
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 representa-
tion 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 con-
ducted during software engineering. The impact of data
structure on program structure and procedural complexity
causes data design to have a profound influence on soft-
ware 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 effi-
cient design or may simply involve the use of a set of mod-
ules (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 con-
strained.
Regardless of the design techniques to be used, well-
designed data can lead to better program structure, modu-
larity 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, specifi-
cation 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 per-
formed on the data structure, an abstract data type is
defined for use in subsequent software design.
Specification of the abstract data type may simplify soft-
ware design considerably.
3. A data dictionary should be established and used to define
both data and program design. The concept of a data dictio-
nary 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
ESE Module 3-5
StructuredDesign
3-5.2Essential Software Engineering
be used for the design of data. That is, overall data organi-
zation 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 analo-
gous 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 sophisti-
cated 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 struc-
ture 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 defini-
tion and development phase of the software engineering
process. As we have noted elsewhere, a clear definition of
information is essential to successful software develop-
ment.
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, defin-
ing interfaces that enable data to flow throughout the pro-
gram.
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 pro-
vide 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 con-
centrate 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 computer-
oriented 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 human-
computer 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 inter-
face 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 soft-
ware. 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, edu-
cation, 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 per-
formed, the meaning of input and output, and the goals
and objectives of the system] of the application or comput-
er usage in general;
- knowledgeable, intermittent users-reasonable semantic
knowledge of the application, but relatively low recall of
syntactic information necessary to use the interface;
- knowIedgeabIe, frequent users--good semantic and syn-
tactic knowledge that often leads to the power-user syn-
drome, that is, individuals who look for short cuts and
abbreviated modes of interaction.
The system perception (user's model) is the image of the
system that an end user carries in his or her head. For
example, if the user of a particular word processor were
asked to describe its operation, the system perception
would guide the response. The accuracy of the description
will depend upon the user's profile (e.g., novices would
provide a sketchy response at best) and overall familiarity
with software in the application domain. A user who
understands word processors fully, but has only worked
with the specific word processor once, might actually be
able to provide a more complete description of its function
than the novice who has spent weeks trying to learn the
system.
The system image combines the outward manifestation
of the computer-based system (the look and feel of the
interface), coupled with all supporting information (books,
manuals, video tapes) that describe system syntax and
semantics. When the system image and the system percep-
tion are coincident, users generally feel comfortable with
the software and use it effectively. To accomplish this
melding of the models, the design model must have been
developed to accommodate the information contained in
the user model, and the system image must accurately
reflect syntactic and semantic information about the inter-
face.
In essence, these models enable the interface designer
to satisfy a key element of the most important principle of
user interface design: "Know the user; know the tasks."
Procedural Design
Procedural design occurs after data and program structure
have been established. In an ideal world, the procedural
specification required to define algorithmic details would
be stated in a natural language such as English. After all,
members of a software development organization all speak
a natural language (in theory, at least); people outside the
software domain could more readily understand the speci-
fication, and no new learning would be required.
Unfortunately, there is one small problem. Procedural
design must specify procedural detail unambiguously, and
a lack of ambiguity in a natural language is not natural.
Using a natural language, we can write a set of procedural
steps in too many different ways. We frequently rely on
context to get a point across. We often write as if a dia-
logue with the reader were possible (it isn't). For these and
many other reasons, a more constrained mode for repre-
senting 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.
StructuredDesign ·· 3-5.3
[3] Shneiderman, B., Designing the User Interface, Addison-
Wesley, 1987. O
ArchitecturalDesign
When an architect presents the design of the house, it
is likely that she will first show you a three-dimensional
perspective of the structure so that you will under-
stand what it looks like before its ultimate implementa-
tion in the real world. In addition, the architect will
depict the internal layout of the house by showing
you a floor plan in which each living component
(room) and its interfaces will be shown. Electrical
wiring diagrams, plumbing schematics, the founda-
tion plan, exterior wall construction detail, and roofing
trusses are all part of the design, but initially, this infer-
mation is unimportant -- initially we are interested in
obtaining a big picture view of the design representa-
tion.
The modes of representation for computer soft-
ware and the overall design approach are remark-
ably similar to those that the architect uses for a
house. Architectural design focuses on the creation of
the "floor plan" for computer software. Instead of
showing the layout of rooms and their sizes, an archi-
tectural design for software shows the layout of pro-
gram components (modules) and their control hierar-
chy, also referred to as connectivity. The "doorways
and windows" for the software are represented as
module interface specifications in which all incoming
and outgoing data are represented. The "plumbing
and electrical layouts" for software are postponed
until procedural design.
The most commonly used approach for architec-
tural design is called structured design. Structured
design maps a floor plan for software using a data
flow model created during software requirements
analysis work.
Readings
The following excerpt has been adapted from
Software Engineering: A Practitioner's Approach and
presents adetailed discussion of structured design.
Structured design allows a convenient transition from
information representations, the data flow diagram (DFD),
contained in a Software Requirements Specification to a design description of program structure. The transition from
information flow to structure is accomplished as part of a
five-step process: (1) the type of information flow is estab-
3-5.4··EssentialSoftwareEngineering
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 trans-
form external data into an internal form and shall be identi-
fied as incoming flow. At the kernel of the software, a tran-
sition occurs. Incoming data are passed through a trans-
form center and begin to move along paths that now lead
"out" of the software. Data moving along these paths are