Software Engineering: A Practitioners Approach, 8/e
by Roger S. Pressman and Bruce R. Maxim
DESIGN CONCEPTS
Mitch Kapor, the creator of Lotus 1-2-3, presented a software design
manifesto in Dr. Dobbs Journal. He said:
Good software design should exhibit:
Firmness: A program should not have any bugs that inhibit its
function.
Commodity: A program should be suitable for the purposes for
which it was intended.
Delight: The experience of using the program should be
pleasurable one.
Software Design
Encompasses the set of principles, concepts, and practices that
lead to the development of a high quality system or product
Design principles establish and overriding philosophy that guides
the designer as the work is performed
Design concepts must be understood before the mechanics of
design practice are applied
Software design practices change continuously as new methods,
better analysis, and broader understanding evolve
Software Engineering Design
Data/Class design transforms analysis classes into
implementation classes and data structures
Architectural design defines relationships among the major
software structural elements
Interface design defines how software elements, hardware
elements, and end-users communicate
Component-level design transforms structural elements into
procedural descriptions of software components
Analysis Model -> Design Model
scenario- based
elements
use-cases - text
use-case diagrams
activity diagrams
swim lane diagrams
data flow diagrams
control-flow diagrams
processing narratives
Int erfac e Design
Analysis Model
class- based
elements
class diagrams
analysis packages
CRC models
collaboration diagrams
Component Level Design
f low- oriented
elements
behavioral
elements
state diagrams
sequence diagrams
Arc hit ec t ural Design
Dat a/ Class Design
Design Model
Design and Quality
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
A design should exhibit an architecture that
o (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 design should be modular; that is, the software should be
logically partitioned into elements or subsystems
A design should contain distinct representations of data,
architecture, interfaces, and components.
A design should lead to data structures that are appropriate for
the classes to be implemented and are drawn from recognizable
data patterns.
A design should lead to components that exhibit independent
functional characteristics.
A design should lead to interfaces that reduce the complexity of
connections between components and with the external
environment.
A design should be derived using a repeatable method that is
driven by information obtained during software requirements
analysis.
A design should be represented using a notation that effectively
communicates its meaning.
DESIGN PRINCIPLES
The design process should not suffer from tunnel vision.
The design should be traceable to the analysis model.
The design should not reinvent the wheel.
The design should minimize the intellectual distance [DAV95]
between the software and the problem as it exists in the real
world.
The design should exhibit uniformity and integration.
The design should be structured to accommodate change.
The design should be structured to degrade gently, even when
aberrant data, events, or operating conditions are encountered.
Design is not coding, coding is not design.
The design should be assessed for quality as it is being created,
not after the fact.
The design should be reviewed to minimize conceptual
(semantic) errors
FUNDAMENTAL CONCEPTS
Abstractiondata, procedure, control
Architecturethe overall structure of the software
Patternsconveys the essence of a proven design solution
Separation of concernsany complex problem can be more
easily handled if it is subdivided into pieces
Modularitycompartmentalization of data and function
Hidingcontrolled interfaces
Functional independencesingle-minded function and low
coupling
Refinementelaboration of detail for all abstractions
Aspectsa mechanism for understanding how global
requirements affect design
Refactoringa reorganization technique that simplifies the
design
Design Classesprovide design detail that will enable analysis classes
to be implemented
DATA ABSTRACTION
Implemented as a data structure
ARCHITECTURE
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
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 namedescribes the essence of the pattern in a
short but expressive name
Intentdescribes the pattern and what it does
Also-known-aslists any synonyms for the pattern
Motivationprovides an example of the problem
Applicabilitynotes specific design situations in which
the pattern is applicable
Structuredescribes the classes that are required to
implement the pattern
Participantsdescribes the responsibilities of the classes
that are required to implement the pattern
Collaborationsdescribes how the participants
collaborate to carry out their responsibilities
Consequencesdescribes the design forces that affect
the pattern and the potential trade-offs that must be
considered when the pattern is implemented
Related patternscross-references related design
patterns
SEPARATION OF CONCERNS
Any complex problem can be more easily handled if it is
subdivided into pieces that can each be solved and/or optimized
independently
A concern is a feature or behavior that is specified as part of the
requirements model for the software
By separating concerns into smaller, and therefore more
manageable pieces, a problem takes less effort and time to
solve.
MODULARITY
"modularity is the single attribute of software that allows a
program to be intellectually manageable" [Mye78].
Monolithic software (i.e., a 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.
In almost all instances, you should break the design into many
modules, hoping to make understanding easier and as a
consequence, reduce the cost required to build the software.
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 encapsulationan attribute of high quality design
results in higher quality software
Functional Independence
Functional independence is achieved by developing modules with
"single-minded" function and an "aversion" to excessive
interaction with other modules.
Cohesion is an indication of the relative functional strength of a
module.
A cohesive module performs a single task, requiring little
interaction with other components in other parts of a program.
Stated simply, a cohesive module should (ideally) do just one
thing.
Coupling is an indication of the relative interdependence among
modules.
Coupling depends on the interface complexity between modules,
the point at which entry or reference is made to a module, and
what data pass across the interface.
ASPECTS
Consider two requirements, A and B. Requirement A crosscuts
requirement B if a software decomposition [refinement] has
been chosen in which B cannot be satisfied without taking A into
account. [Ros04]
An aspect is a representation of a cross-cutting concern.
AspectsAn Example
Consider two requirements for the SafeHomeAssured.com
WebApp. Requirement A is described via the use-case Access
camera surveillance via the Internet. A design refinement
would focus on those modules that would enable a registered
user to access video from cameras placed throughout a space.
Requirement B is a generic security requirement that states that
a registered user must be validated prior to using
SafeHomeAssured.com. This requirement is applicable for all
functions that are available to registered SafeHome users. As
design refinement occurs, A* is a design representation for
requirement A and B* is a design representation for requirement
B. Therefore, A* and B* are representations of concerns, and B*
cross-cuts A*.
An aspect is a representation of a cross-cutting concern.
Therefore, the design representation, B*, of the requirement, a
registered user must be validated prior to using
SafeHomeAssured.com, is an aspect of the SafeHome
WebApp.
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 refactored, the existing design is examined for
o redundancy
o unused design elements
o inefficient or unnecessary algorithms
o poorly constructed or inappropriate data structures
o or any other design failure that can be corrected to yield a
better design.
OO DESIGN CONCEPTS
Design classes
Entity classes
Boundary classes
Controller classes
Inheritanceall responsibilities of a superclass is immediately
inherited by all subclasses
Messagesstimulate some behavior to occur in the receiving
object
Polymorphisma characteristic that greatly reduces the effort
required to extend the design
DESIGN CLASSES
Analysis classes are refined during design to become entity
classes
Boundary classes are developed during design to create the
interface (e.g., interactive screen or printed reports) that the
user sees and interacts with as the software is used.
Boundary classes are designed with the responsibility of
managing the way entity objects are represented to users.
Controller classes are designed to manage the creation or update
of entity objects;
the instantiation of boundary objects as they obtain information
from entity objects;
complex communication between sets of objects;
validation of data communicated between objects or between
the user and the application.
DESIGN CLASS CHARACTERISTICS
Complete - includes all necessary attributes and methods) and
sufficient (contains only those methods needed to achieve class
intent)
Primitiveness each class method focuses on providing one
service
High cohesion small, focused, single-minded classes
Low coupling class collaboration kept to minimum
DESIGN MODEL ELEMENTS
Data elements
o Data model --> data structures
o Data model --> database architecture
Architectural elements
o Application domain
o Analysis classes, their relationships, collaborations and
behaviors are transformed into design realizations
o Patterns and styles (Chapters 9 and 12)
Interface elements
o the user interface (UI)
o external interfaces to other systems, devices, networks or
other producers or consumers of information
o internal interfaces between various design components.
Component elements
Deployment elements
DATA MODELING
examines data objects independently of processing
focuses attention on the data domain
creates a model at the customers level of abstraction
indicates how data objects relate to one another
WHAT IS A DATA OBJECT
a representation of almost any composite information that must
be understood by software.
composite informationsomething that has a number of
different properties or attributes
can be an external entity (e.g., anything that produces or
consumes information), a thing (e.g., a report or a display), an
occurrence (e.g., a telephone call) or event (e.g., an alarm), a
role (e.g., salesperson), an organizational unit (e.g., accounting
department), a place (e.g., a warehouse), or a structure (e.g., a
file).
The description of the data object incorporates the data object
and all of its attributes.
A data object encapsulates data onlythere is no reference
within a data object to operations that act on the data.
WHAT IS A RELATIONSHIP?
Data objects are connected to one another in different ways.
o A connection is established between person and car
because the two objects are related.
A person owns a car
A person is insured to drive a car
The relationships owns and insured to drive define the relevant
connections between person and car.
Several instances of a relationship can exist
Objects can be related in many different ways
ARCHITECTURAL ELEMENTS
The architectural model [Sha96] is derived from three sources:
o information about the application domain for the software
to be built;
o specific requirements model elements such as data flow
diagrams or analysis classes, their relationships and
collaborations for the problem at hand, and
o the availability of architectural patterns (Chapter 16) and
styles (Chapter 13).
INTERFACE ELEMENTS
Interface is a set of operations that describes the externally
observable behavior of a class and provides access to its public
operations
Important elements
o User interface (UI)
o External interfaces to other systems
o Internal interfaces between various design components
Modeled using UML communication diagrams (called
collaboration diagrams in UML 1.x)
COMPONENT ELEMENTS
Describes the internal detail of each software component
Defines
o Data structures for all local data objects
o Algorithmic detail for all component processing functions
o Interface that allows access to all component operations
Modeled using UML component diagrams, UML activity diagrams,
pseudocode (PDL), and sometimes flowcharts
DEPLOYMENT ELEMENTS
Indicates how software functionality and subsystems will be
allocated within the physical computing environment
Modeled using UML deployment diagrams
Descriptor form deployment diagrams show the computing
environment but does not indicate configuration details
Instance form deployment diagrams identifying specific named
hardware configurations are developed during the latter stages
of design
