Software Engineering: A Practitioner’s Approach, 6/e
Chapter 11
Component-Level Design
copyright © 1996, 2001, 2005
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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
1
What is a Component?

OMG Unified Modeling Language Specification [OMG01]
defines a component as



“… a modular, deployable, and replaceable part of a system that
encapsulates implementation and exposes a set of interfaces.”
OO view: a component contains a set of collaborating
classes
Conventional view: logic, the internal data structures
that are required to implement the processing logic, and
an interface that enables the component to be invoked
and data to be passed to it.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
2
OO Component
a n a l y si s c l a ss
Pri n t Jo b
n u m b e rOf Pa g e s
n u m b e rOf Si d e s
p a p e rTy p e
m agnif ic at ion
p ro d u c t i o n Fe a t u re s
d e si g n c o m p o n e n t
c o m p u t e Jo b Co st( )
p a ssJo b t o Pri n t e r( )
c o m p u t e Jo b
Pri n t Jo b
i n i t i a t e Jo b
< < in t er f ace> >
co m p u t eJo b
comput ePageCost ( )
comput ePaper Cost ( )
comput ePr odCost ( )
comput eTot alJobCost ( )
< < in t er f ace> >
in it iat eJo b
buildWor kOr der ( )
checkPr ior it y ( )
passJobt o Pr oduct ion( )
elaborat ed design class
Print Job
number Of Pages
number Of Sides
paper Type
paper Weight
paper Size
paper Color
magnif icat ion
color Requir ement s
pr oduct ionFeat ur es
collat ionOpt ions
bindingOpt ions
cover St ock
bleed
pr ior it y
t ot alJobCost
WOnumber
comput ePageCost ( )
comput ePaper Cost ( )
comput ePr odCost ( )
comput eTot alJobCost ( )
buildWor kOr der ( )
checkPr ior it y ( )
passJobt o Pr oduct ion( )
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
3
Conventional Component
design component
getJobData
ComputePageCost
accessCostsDB
elaborated module
PageCost
in: numberPages
in: numberDocs
in: sides= 1 , 2
in: color=1 , 2 , 3 , 4
in: page size = A, B, C, B
out : page cost
in: j ob size
in: color=1 , 2 , 3 , 4
in: pageSize = A, B, C, B
out : BPC
out : SF
g e t Jo b Dat a ( n u m b e rPag e s, n u m b e rDo cs,
sid e s, co lo r, p ag e Size , p ag e Co st )
acce ssCo st sDB (j o b Size , co lo r, p ag e Size ,
BPC, SF)
co m p u t e Pag e Co st( )
j o b size ( JS) =
n u m b e rPag e s * n u m b e rDo cs;
lo o ku p b ase p ag e co st ( BPC) -->
acce ssCo st sDB ( JS, co lo r) ;
lo o ku p size fact o r ( SF) -->
acce ssCo st DB ( JS, co lo r, size )
j o b co m p le xit y fact o r ( JCF) =
1 + [ ( sid e s-1 ) * sid e Co st + SF]
p ag e co st = BPC * JCF
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
4
Basic Design Principles







The Open-Closed Principle (OCP). “A module [component] should be open for
extension but closed for modification.
The Liskov Substitution Principle (LSP). “Subclasses should be substitutable for
their base classes.
Dependency Inversion Principle (DIP). “Depend on abstractions. Do not depend
on concretions.”
The Interface Segregation Principle (ISP). “Many client-specific interfaces are
better than one general purpose interface.
The Release Reuse Equivalency Principle (REP). “The granule of reuse is the
granule of release.”
The Common Closure Principle (CCP). “Classes that change together belong
together.”
The Common Reuse Principle (CRP). “Classes that aren’t reused together should
not be grouped together.”
Source: Martin, R., “Design Principles and Design Patterns,” downloaded from http:www.objectmentor.com, 2000.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
5
Design Guidelines

Components


Interfaces


Naming conventions should be established for components that are specified as
part of the architectural model and then refined and elaborated as part of the
component-level model
Interfaces provide important information about communication and collaboration
(as well as helping us to achieve the OPC)
Dependencies and Inheritance

it is a good idea to model dependencies from left to right and inheritance from
bottom (derived classes) to top (base classes).
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
6
Cohesion

Conventional view:


OO view:


the “single-mindedness” of a module
cohesion implies that a component or class encapsulates
only attributes and operations that are closely related to one
another and to the class or component itself
Levels of cohesion







Functional
Layer
Communicational
Sequential
Procedural
Temporal
utility
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
7
Coupling

Conventional view:


OO view:


The degree to which a component is connected to other
components and to the external world
a qualitative measure of the degree to which classes are
connected to one another
Level of coupling









Content
Common
Control
Stamp
Data
Routine call
Type use
Inclusion or import
External
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
8
Component Level Design-I





Step 1. Identify all design classes that correspond to the
problem domain.
Step 2. Identify all design classes that correspond to the
infrastructure domain.
Step 3. Elaborate all design classes that are not acquired
as reusable components.
Step 3a. Specify message details when classes or
component collaborate.
Step 3b. Identify appropriate interfaces for each
component.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
9
Component-Level Design-II






Step 3c. Elaborate attributes and define data types and
data structures required to implement them.
Step 3d. Describe processing flow within each operation in
detail.
Step 4. Describe persistent data sources (databases and
files) and identify the classes required to manage them.
Step 5. Develop and elaborate behavioral representations
for a class or component.
Step 6. Elaborate deployment diagrams to provide
additional implementation detail.
Step 7. Factor every component-level design representation
and always consider alternatives.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
10
Collaboration Diagram
:ProductionJob
1: buildJob ( WOnumber )
2: submitJob ( WOnumber )
:WorkOrder
:JobQueue
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
11
Refactoring
computeJob
PrintJob
initiateJob
WorkOrder
<<interface>>
initiateJob
ap p ro p riat e at t rib u t e s
getJobDescriiption
buildWorkOrder ()
buildJob
p assJo b To Pro d u ct io n ( )
ProductionJob
submitJob
JobQueue
ap p ro p riat e at t rib u t e s
checkPriority ()
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
12
Activity Diagram
v alidat e at t ribut es
input
ac c es s PaperDB (weight )
ret urns baseCost perPage
paperCos t perPage =
bas eCos t perPage
s ize = B
paperCos t perPage =
paperCos t perPage * 1 . 2
s ize = C
paperCost perPage =
paperCost perPage * 1 . 4
s iz e = D
paperCost perPage =
paperCost perPage * 1 . 6
c olor is c us t om
paperCos t perPage =
paperCost perPage * 1 . 1 4
color is s t andard
ret urns
( paperCos t perPage )
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
13
Statechart
b eh avio r w it h in t h e
st at e b u ild in g Jo b Dat a
d at aIn p u t In co mp let e
buildingJobDat a
ent ry/ readJobDat a ()
exit / displayJobDat a ()
do/ checkConsist ency()
include/ dat aInput
d at aIn p u t Co mp let ed [ all d at a
it ems co n sist en t ] / d isp layUserOp t io n s
comput ingJobCost
ent ry/ comput eJob
exit / save t ot alJobCost
j o b Co st Accep t ed [ cu st o mer is au t h o rized ] /
g et Elect ro n icSig n at u re
f ormingJob
ent ry/ buildJob
exit / save WOnumber
do/
submit t ingJob
ent ry/ submit Job
exit / init iat eJob
do/ place on JobQueue
j o b Su b mit t ed[ all au t h o rizat io n s acq u ired ] /
p rin t Wo rkOrd er
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
14
Object Constraint Language (OCL)


complements UML by allowing a software engineer to use a
formal grammar and syntax to construct unambiguous
statements about various design model elements
simplest OCL language statements are constructed in four
parts:




(1) a context that defines the limited situation in which the
statement is valid;
(2) a property that represents some characteristics of the context
(e.g., if the context is a class, a property might be an attribute)
(3) an operation (e.g., arithmetic, set-oriented) that manipulates or
qualifies a property, and
(4) keywords (e.g., if, then, else, and, or, not, implies) that are
used to specify conditional expressions.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
15
OCL Example
context PrintJob::validate(upperCostBound :
Integer, custDeliveryReq :
Integer)
pre: upperCostBound > 0
and custDeliveryReq > 0
and self.jobAuthorization = 'no'
post: if self.totalJobCost <= upperCostBound
and self.deliveryDate <= custDeliveryReq
then
self.jobAuthorization = 'yes'
endif
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
16
Algorithm Design


the closest design activity to coding
the approach:




review the design description for the
component
use stepwise refinement to develop algorithm
use structured programming to implement
procedural logic
use ‘formal methods’ to prove logic
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
17
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, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
18
Algorithm Design Model


represents the algorithm at a level of detail
that can be reviewed for quality
options:





graphical (e.g. flowchart, box diagram)
pseudocode (e.g., PDL) ... choice of many
programming language
decision table
conduct walkthrough to assess quality
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
19
Structured Programming
for Procedural Design
uses a limited set of logical constructs:
sequence
conditional— if-then-else, select-case
loops— do-while, repeat until
leads to more readable, testable code
can be used in conjunction with ‘proof of
correctness’
important for achieving high quality,
but not enough
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
20
A Structured Procedural Design
add a condition Z,
if true, exit the program
a
x1
b
x2
x3
d
c
e
f
x4
g
x5
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
21
Decision Table
Rule s
Condit ions
regular cust omer
1
T
2
3
4
T
T
gold cust omer
F
6
T
silver cust omer
special discount
5
T
F
T
T
T
F
T
Rule s
no discount
apply 8 percent discount
apply 15 percent discount
apply addit ional x percent discount
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
22
Program Design Language (PDL)
if-then-else
if condition x
then process a;
else process b;
endif
PDL
easy to combine with source code
machine readable, no need for graphics input
graphics can be generated from PDL
enables declaration of data as well as procedure
easier to maintain
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
23
Why Design Language?
can be a derivative of the HOL of choice
e.g., Ada PDL
machine readable and processable
can be embedded with source code,
therefore easier to maintain
can be represented in great detail, if
designer and coder are different
easy to review
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
24