Supplementary Slides for
Software Engineering:
A Practitioner's Approach, 5/e
copyright © 1996, 2001
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
This presentation, slides, or hardcopy may NOT be used for
short courses, industry seminars, or consulting purposes.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
1
Slide 14
Chapter 13
Design Concepts and Principles
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
2
Analysis to Design
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
3
Where Do We Begin?
modeling
Prototype
Spec
Design
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
4
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.
From Davis [DAV95]
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
5
Fundamental Concepts
abstraction—data, procedure, control
refinement—elaboration of detail for all abstractions
modularity—compartmentalization of data and
function
architecture—overall structure of the software
 Structural properties
 Extra-structural properties
 Styles and patterns
procedure—the algorithms that achieve function
hiding—controlled interfaces
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
6
Data Abstraction
door
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism
implemented as a data structure
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
7
Procedural Abstraction
open
details of enter
algorithm
implemented with a "knowledge" of the
object that is associated with enter
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
8
Stepwise Refinement
open
walk to door;
reach for knob;
open door;
walk through;
close door.
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
9
Modular Design
easier to build, easier to change, easier to fix ...
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
10
Modularity: Trade-offs
What is the "right" number of modules
for a specific software design?
module development cost
cost of
software
module
integration
cost
optimal number
of modules
number of modules
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
11
Sizing Modules: Two Views
What's
inside??
How big
is it??
MODULE
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
12
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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
13
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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
14
Control Hierarchy
Represents the organization of program
components & implies a hierarchy of control
Does not represent:
 Procedural aspect of SW such as sequence, order,
repetition
 Applicability to all architectural styles
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
15
Representation – treelike diagram
M
a
depth
d
f
c
b
e
g
Fan-out
k
h
l
n
m
o
p
q
Fan-in
i
j
r
Width
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
16
Note on diagram…
 Depth and width provide an indication of the number of
levels of control and overall span of control, respectively
 Fan-out is a measure of the number of modules that are
directly controlled by another module
 Fan-in indicates how many modules directly control a given
modules
 A module that control another module is said to be superordinate to it
 A module controlled by another is said to be subordinate to
the controller
 Eg. M is super-ordinate to a, b & c
 Eg. h is subordinate to e & ultimately to M
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
17
Structural Partitioning
Horizontal Partitioning
Vertical Partitioning (factoring)
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
18
Data Structure
 A representation of the logical relationship
among individual elements of data
1. Scalar item
2. Sequential vector
3. N-dimensional space (array)
4. Linked list
 Hierarchical data structure – multi linked list
 Different level of abstraction, eg. stack
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
19
Information Hiding
module
controlled
interface
• algorithm
• data structure
• details of external interface
• resource allocation policy
clients
"secret"
a specific design decision
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
20
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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
21
Design Heuristics
Reduce coupling, improve cohesion
Minimize fan-out, strive for fan-in
Keep the scope of effect within the scope of
control
Evaluate module interface to reduce
complexity and redundancy and improve
consistency
Function is predictable, but not overly
restrictive
Strive for “controlled entry” modules by
avoiding “pathological connection”
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
22
Design Model
Component-level
design
interface design
Architectural design
maintenance
test
implementation
Data design
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
23
Design documentation
 Scope of design effort
 Derived from system specification & SW requirement
specification
 Data design
 Architectural design
 Interfaces
 Components
 Cross reference
 Test plan
 constraints
 Supplementary data
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
24