Chapter Comments
Chapter
9-1
9
Design Engineering
CHAPTER OVERVIEW AND COMMENTS
The intent of this chapter is to provide an introduction to the design process and
to describe fundamental design concepts that are essential to an understanding
of any software design method. Basic concepts are introduced and a
fundamental design model is discussed. The design model consists of the data
design, architectural design, interface design, and component-level design.
The goal of design engineering is to produce a model or representation that
exhibits firmness, commodity, and delight.
To accomplish this, a designer must practice diversification and then
convergence.
Belady states that “diversification is the acquisition of a repertoire of alternatives,
the raw material of design: components, component solutions, and knowledge,
all contained in catalogs, textbooks, and the mind.”
Once this diverse set of information is assembled, the designer must pick and
choose elements from the repertoire that meet the requirements designed by
requirement engineering and the analysis models.
As this occurs, alternatives are considered and rejected, and the design engineer
converges on “one particular configuration of components, and thus the creation
of the final product.”
9.1 Design within the Context of Software Engineering
Software design is the last software engineering action within the modeling
activity and sets the stage for construction (code generation and testing).
The flow of information during software design is illustrated in Figure below. The
analysis model, manifested by scenario-based, class-based, flow-oriented and
behavioral elements, feed the design task.
The architectural design defines the relationship between more structural
elements of the software, the architectural styles and design patterns that can be
9-2
SEPA, 6/e Instructor’s Guide
used to achieve the requirements defined for the system, and the constraints that
affect the way in which the architectural design can be implemented.
The architectural design can be derived from the System Specs, the analysis
model, and interaction of subsystems defined within the analysis model.
sc e n a r i o- b a se d
e l e m e nt s
Co m p o n e n t L e v e l D e sig n
f l ow- o r i e n t e d
e l e m e nt s
use-cases - text
use-case diagrams
activity diagrams
swim lane diagrams
data flow diagrams
control-flow diagrams
processing narratives
In t e r f a c e D e sig n
Analysis Model
c l a ss- b a se d
e l e me nt s
class diagrams
analysis packages
CRC models
collaboration diagrams
be ha v i or a l
e l e me nt s
A r c h it e c t u r a l D e sig n
state diagrams
sequence diagrams
D a t a / Cla ss D e sig n
Design Model
The interface design describes how the software communicates with systems
that interpolate with it, and with humans who use it. An interface implies a flow of
information (data, and or control) and a specific type of behavior.
The component-level design transforms structural elements of the software
architecture into a procedural description of software components.
The importance of software design can be stated with a single word – quality.
Design is the place where quality is fostered in software engineering. Design
provides us with representations of software that can be assessed for quality.
Design is the only way that we can accurately translate a customer’s
requirements into a finished software product or system.
Chapter Comments
9-3
9.2 Design Process and Design Quality
Software design is an iterative process through which requirements are
translated into a “blueprint” for constructing the software.
Initially, the blueprint depicts a holistic view of software, i.e. the design is
represented at a high-level of abstraction.
Throughout the design process, the quality of the evolving design is assessed
with a series of formal technique reviews or design walkthroughs.
Three characteristics serve as a guide for the evaluation of a good design:



The design must implement all of the explicit requirements contained in the
analysis model, and it must accommodate all of the implicit requirements
desired by the customer.
The design must be a readable, understandable guide for those who generate
code and for those who test and subsequently support the software.
The design should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation perspective.
Quality Guidelines
In order to evaluate the quality of a design representation, we must establish
technical criteria for good design.
1. A design should exhibit an architecture that:
(1) Has been created using recognizable architectural styles or patterns,
(2) Is composed of components that exhibit good design characteristics, and
(3) Can be implemented in an evolutionary fashion
a. For smaller systems, design can sometimes be developed linearly.
2. A design should be modular; that is, the software should be logically
partitioned into elements or subsystems
3. A design should contain distinct representations of data, architecture,
interfaces, and components.
4. A design should lead to data structures that are appropriate for the classes to
be implemented and are drawn from recognizable data patterns.
5. A design should lead to components that exhibit independent functional
characteristics.
6. A design should lead to interfaces that reduce the complexity of connections
between components and with the external environment.
7. A design should be derived using a repeatable method that is driven by
information obtained during software requirements analysis.
8. A design should be represented using a notation that effectively
communicates its meaning.
9-4
SEPA, 6/e Instructor’s Guide
Quality Attributes
Hewlett-Packard developed a set of software quality attributes that has been
given the acronym FURPS. The FURPS quality attributes represent a target for
all software design:
 Functionality: is assessed by evaluating the features set and capabilities of
the program, the generality of the functions that are delivered, and the
security of the overall system.
 Usability: is assessed by considering human factors, overall aesthetics,
consistency, and documentation.
 Reliability: is evaluated by measuring the frequency and severity of failure,
the accuracy of output results, the mean-time-to-failure, the ability to recover
from failure, and the predictability of the program.
 Performance: is measured by processing speed, response time, resource
consumption, throughput, and efficiency.
 Supportability: combines the ability to extend the program extensibility,
adaptability, serviceability  maintainability. In addition, testability,
compatibility, configurability, etc.
9.3 Design Concepts
This section discusses many significant design concepts (abstraction,
refinement, modularity, architecture, patterns, refactoring, functional
independence, information hiding, and OO design concepts).
9.3.1 Abstraction
At the highest level of abstraction, a solution is stated in broad terms using the
language of the problem environment. At lower levels of abstraction, a more
detailed description of the solution is provided.
As we move through different levels of abstraction, we work to create procedural
and data abstractions. A procedural abstraction refers to a sequence of
instructions that have a specific and limited function. An example of a procedural
abstraction would be the word open for a door.
A data abstraction is a named collection of data that describes a data object. In
the context of the procedural abstraction open, we can define a data abstraction
called door. Like any data object, the data abstraction for door would
encompass a set of attributes that describe the door (e.g. door type, swing
direction, weight).
9.3.2 Architecture
Software architecture alludes to the “overall structure of the software and the
ways in which the structure provides conceptual integrity for a system.”
In its simplest from, architecture is the structure of organization of program
components (modules), the manner in which these components interact, and the
structure of data that are used by the components.
Chapter Comments
9-5
Te goal of software design is to derive an architectural rendering of a system.
This rendering serves as a framework from which detailed design activities are
constructed.
A set of architectural patterns enable a software engineer to reuse design-level
concepts.
The architectural design can be represented using one or more of a number of
different models.
Structural models represent architecture as an organized collection of program
components.
Framework models increase the level of design abstraction by attempting to
identify repeatable architectural design frameworks that are encountered in
similar types of applications.
Dynamic models address the behavioral aspects of the program architecture,
indicating how the structure or system configuration may change as a function of
external events.
Process models focus on the design of business or technical process that the
system must accommodate.
Functional models can be used to represent the functional hierarchy of a system.
Architectural design will be discussed in Chapter 10.
9.3.3 Patterns
A design pattern “conveys the essence of a proven design solution to a recurring
problem within a certain context amidst computing concerns.”
A design pattern describes a design structure that solves a particular design
problem within a specific context and amid “forces” that may have an impact on
the manner in which the pattern is applied and used.
The intent of each design pattern is to provide a description that enables a
designer to determine:
1. whether the pattern is applicable to the current work,
2. whether the pattern can be reused, and
3. whether the pattern can serve as a guide for developing a similar, but
functionally or structurally different pattern.
9-6
SEPA, 6/e Instructor’s Guide
9.3.4 Modularity
Software architecture and design patterns embody modularity; that is, software is
divided into separately named and addressable components, sometimes called
modules that are integrated to satisfy problem requirements.
Monolithic software (large program composed of a single module) cannot be
easily grasped by a software engineer. The number of control paths, span of
reference, number of variables, and overall complexity would make
understanding close to impossible.
It is the compartmentalization of data and function. It is easier to solve a
complex problem when you break it into manageable pieces. “Divide-andconquer”
Don’t over-modularize. The simplicity of each small module will be overshadowed
by the complexity of integration “Cost”.
9.3.5 Information Hiding
It is about controlled interfaces. Modules should be specified and design so that
information (algorithm and data) contained within a module is inaccessible to
other modules that have no need for such information.
Hiding implies that effective modularity can be achieved by defining by a set of
independent modules that communicate with one another only that information
necessary to achieve software function.
The use of Information Hiding as a design criterion for modular systems provides
the greatest benefits when modifications are required during testing and later,
during software maintenance. Because most data and procedures are hidden
from other parts of the software, inadvertent errors introduced during
modifications are less likely to propagate to other location within the software.
9.3.6 Functional Independence
The concept of functional Independence is a direct outgrowth of modularity and
the concepts of abstraction and information hiding.
Design software so that each module addresses a specific sub-function of
requirements and has a simple interface when viewed from other parts of the
program structure.
Functional independence is a key to good design, and design is the key to
software quality.
Chapter Comments
9-7
Independence is assessed using two qualitative criteria: cohesion and
coupling.
Cohesion is an indication of the relative functional strength of a module.
Coupling is an indication of the relative interdependence among modules.
A cohesive module should do just one thing.
Coupling is a qualitative indication of the degree to which a module is connected
to other modules and to the outside world “lowest possible”.
9.3.7 Refinement
It is the elaboration of detail for all abstractions. It is a top down strategy.
A program is developed by successfully refining levels of procedural detail.
A hierarchy is developed by decomposing a macroscopic statement of function (a
procedural abstraction) in a stepwise fashion until programming language
statements are reached.
We begin with a statement of function or data that is defined at a high level of
abstraction.
The statement describes function or information conceptually but provides no
information about the internal workings of the function or the internal structure of
the data.
Refinement causes the designer to elaborate on the original statement, providing
more and more detail as each successive refinement (elaboration) occurs.
Abstraction enables a designer to specify procedure and data and yet suppress
low-level details.
Refinement helps the designer to reveal low-level details as design progresses.
Refinement causes the designer to elaborate on the original statement, providing
more and more detail as each successive refinement “elaboration” occurs.
9.3.8 Refactoring
It is a reorganization technique that simplifies the design of a component without
changing its function or behavior. When software is re-factored, the existing
design is examined for redundancy, unused design elements, inefficient or
unnecessary algorithms, poorly constructed data structures, or any other design
failures that can be corrected to yield a better design.
9-8
SEPA, 6/e Instructor’s Guide
Data Abstraction
Procedural Abstraction
“The overall structure of the software and the ways in which that structure
provides conceptual integrity for a system.” [SHA95a]

Structural properties. This aspect of the architectural design representation
defines the components of a system (e.g., modules, objects, filters) and the
manner in which those components are packaged and interact with one
another. For example, objects are packaged to encapsulate both data and the
processing that manipulates the data and interact via the invocation of
methods
Chapter Comments


9-9
Extra-functional properties. The architectural design description should
address how the design architecture achieves requirements for performance,
capacity, reliability, security, adaptability, and other system characteristics.
Families of related systems. The architectural design should draw upon
repeatable patterns that are commonly encountered in the design of families
of similar systems. In essence, the design should have the ability to reuse
architectural building blocks.
Patterns
Design Pattern Template
Pattern name—describes the essence of the pattern in a short but expressive
name
Intent—describes the pattern and what it does
Also-known-as—lists any synonyms for the pattern
Motivation—provides an example of the problem
Applicability—notes specific design situations in which the pattern is applicable
Structure—describes the classes that are required to implement the pattern
Participants—describes the responsibilities of the classes that are required to
implement the pattern
Collaborations—describes how the participants collaborate to carry out their
responsibilities
Consequences—describes the “design forces” that affect the pattern and the
potential trade-offs that must be considered when the pattern is implemented
Related patterns—cross-references related design patterns
Modular Design
easier to build, easier to change, easier to fix ...
9-10
SEPA, 6/e Instructor’s Guide
Modularity: Trade-offs
What is the "right" number of modules for a specific software design?
Information Hiding
Why Information Hiding?






Reduces the likelihood of “side effects”
Limits the global impact of local design decisions
Emphasizes communication through controlled interfaces
Discourages the use of global data
Leads to encapsulation—an attribute of high quality design
Results in higher quality software
Chapter Comments
Stepwise Refinement
Functional Independence
COHESION - the degree to which a
module performs one and only one
function.
COUPLING - the degree to which a
module is "connected" to other
modules in the system.
Sizing Modules: Two Views
What's
inside??
MODULE
How big
is it??
9-11
9-12
SEPA, 6/e Instructor’s Guide
Refactoring
 Fowler [FOW99] defines refactoring in the following manner:
 "Refactoring is the process of changing a software system in such a
way that it does not alter the external behavior of the code [design] yet
improves its internal structure.”
 When software is re-factored, the existing design is examined for
 redundancy
 unused design elements
 inefficient or unnecessary algorithms
 poorly constructed or inappropriate data structures,
 or any other design failure that can be corrected to yield a better
design.
OO Design Concepts
 Entity classes
 Boundary classes
 Controller classes
 Inheritance—all responsibilities of a super-class is immediately inherited by all
subclasses
 Messages—stimulate some behavior to occur in the receiving object
 Polymorphism—a characteristic that greatly reduces the effort required to
extend the design
9.3.9 Design classes
As the design model evolves, the software team must define a set of design
classes that refines the analysis classes and creates a new set of design
classes.
Five different classes’ types are shown below:
1. User Interface classes: define all abstractions that are necessary for HCI.
2. Business domain classes: are often refinements of the analysis classes
defined earlier. The classes identify the attributes and services that are
required to implement some element of the business domain.
3. Process classes: implement lower-level business abstractions required to
fully manage the business domain classes.
4. Persistent classes: represent data stores that will persist beyond the
execution of the software.
5. System classes: implement software management and control functions
that enable the system to operate and communicate within its computing
environment and with the outside world.
Chapter Comments
9-13
Inheritance (Example)
 Design options:
 The class can be designed and built from scratch. That is,
inheritance is not used.
 The class hierarchy can be searched to determine if a class higher
in the hierarchy (a super-class) contains most of the required
attributes and operations. The new class inherits from the superclass and additions may then be added, as required.
 The class hierarchy can be restructured so that the required
attributes and operations can be inherited by the new class.
 Characteristics of an existing class can be overridden and different
versions of attributes or operations are implemented for the new
class.
Messages
:SenderObject
message (<parameters>)
:ReceiverObject
Polymorphism
Conventional approach …
case of graphtype:
if graphtype = linegraph then DrawLineGraph (data);
if graphtype = piechart then DrawPieChart (data);
if graphtype = histogram then DrawHisto (data);
if graphtype = kiviat then DrawKiviat (data);
end case;
9-14
SEPA, 6/e Instructor’s Guide
All of the graphs become subclasses of a general class called graph. Using a
concept called overloading [TAY90], each subclass defines an operation called
draw. An object can send a draw message to any one of the objects instantiated
from any one of the subclasses. The object receiving the message will invoke its
own draw operation to create the appropriate graph.
graphtype draw
9.4 The Design Model
high
a na ly sis mode l
class diagrams
analysis packages
CRC models
collaborat ion diagrams
dat a f low diagrams
cont rol-f low diagrams
processing narrat ives
design class realizat ions
subsyst ems
collaborat ion diagrams
use-cases - t ext
use-case diagrams
act ivit y diagrams
sw im lane diagrams
collaborat ion diagrams
st at e diagrams
sequence diagrams
class diagrams
analysis packages
CRC models
collaborat ion diagrams
dat a f low diagrams
cont rol-f low diagrams
processing narrat ives
st at e diagrams
sequence diagrams
t echnical int erf ace
design
Navigat ion design
GUI design
component diagrams
design classes
act ivit y diagrams
sequence diagrams
de sign mode l
ref inement s t o:
low
ref inement s t o:
design class realizat ions
subsyst ems
collaborat ion diagrams
archit ect ure
element s
component diagrams
design classes
act ivit y diagrams
sequence diagrams
int erface
element s
component -level
element s
Requirement s:
const raint s
int eroperabilit y
t arget s and
conf igurat ion
design class realizat ions
subsyst ems
collaborat ion diagrams
component diagrams
design classes
act ivit y diagrams
sequence diagrams
deployment diagrams
deployment -level
element s
process dimension
 Data elements
 Data model --> data structures
 Data model --> database architecture
 Architectural elements “similar to the floor plan of a house”
 “You can use an eraser on the drafting table or a sledge
hammer on the construction site.”
Frank
Lloyd Wright
 Application domain
Chapter Comments
9-15
 Analysis classes, their relationships, collaborations and behaviors
are transformed into design realizations
 Patterns and “styles”
 Interface elements “The way in which utilities connections come into the
house and are distributed among the rooms”
 the user interface (UI)
 external interfaces to other systems, devices, networks or other
producers or consumers of information
 internal interfaces between various design components.
MobilePhone
WirelessPDA
Cont rolPanel
LCDdisplay
LEDindicat or s
keyPadChar act er ist ics
speaker
wir elessInt er f ace
K ey Pad
r eadKeySt r oke( )
decodeKey ( )
displaySt at us( )
light LEDs( )
sendCont r olMsg( )
< < int erf ac e> >
K ey Pad
r eadKeyst r oke( )
decodeKey( )
Figure 9 . 6 UML int erf ac e represent at ion f or Co n t r o l P a n e l
 Component elements
It is equivalent to a set of detailed drawings and specs for each room in a
house.
The component-level design for software fully describes the internal detail
of each software component.
 Deployment elements
Indicates how software functionally and subsystem terms will be allocated
within the physical computing environment that will support the software.
9-16
SEPA, 6/e Instructor’s Guide
9.5 Pattern-Based Software Design
9.5.1 Describing a Design Pattern
 The best designers in any field have an uncanny ability to see patterns
that characterize a problem and corresponding patterns that can be
combined to create a solution
 A description of a design pattern may also consider a set of design forces.
 Design forces describe non-functional requirements (e.g., ease of
maintainability, portability) associated the software for which the
pattern is to be applied.
 Forces define the constraints that may restrict the manner in which
the design is to be implemented.
 Design forces describe the environment and conditions that must
exist to make the design pattern applicable.
 The pattern characteristics (classes, responsibilities, and collaborations)
indicate the attributes of the design that may be adjusted to enable the
pattern to accommodate a variety of problems.
 These attributes represent characteristics of the design that can be
searched (via database) so that an appropriate pattern can be found.
 Finally, guidance associated with the use of a design pattern provides an
indication of the ramification of design decisions.
 The name of design patterns should be chosen with care.
 One of the key technical problems in software reuse is the inability to find
existing patterns when hundreds or thousands of candidate patterns exist.
 The search of the “right” pattern is aided immeasurably by a meaningful
pattern name.
9.5.2 Using Patterns in Design
Design patterns can be used throughout software design.
Once the analysis model has been developed, the designer can examine a
detailed representation of the problem to be solved and the constraints that are
imposed by the problem.
The problem description is examined at various levels of abstraction to determine
if it is amenable to one or more of the following design patterns:
Architectural patterns: These patterns define the overall structure of the
software, indicate the relationships among subsystems and software
components, and define the rules for specifying relationships among the
elements (classes, packages, components, subsystems) of the architecture.
Chapter Comments
9-17
Design patterns: These patterns address a specific element of the design such
as an aggregation of components to solve some design problems, relationships
among components, or the mechanisms for effecting component-to-component
communication.
Idioms: Sometimes called coding patterns, these language-specific patterns
generally implement an algorithmic element of a component, a specific interface
protocol, or a mechanism for communication among components.
Frameworks
 A framework is not an architectural pattern, but rather a skeleton with a
collection of “plug points” (also called hooks and slots) that enable it to be
adapted to a specific problem domain.
 Gamma et al note that:
 Design patterns are more abstract than frameworks.
 Design patterns are smaller architectural elements than frameworks
 Design patterns are less specialized than frameworks