Component-Level Design

based on
Chapter 11 - Software Engineering: A Practitioner’s Approach, 6/e
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. What would be an example?

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 ly s is c la s s

P rin t J o b

n u m b e rO f P a g e s
n u m b e rO f S id e s
What are the differences?
p a p e rTy p e
m a g n if ic a t io n
p ro d u c t io n F e a t u re s
d e s ig n c o m p o n e n t
c o m p u t e J o b Co s t( ) c o m p u t e Jo b
p a s s J o b t o P rin t e r( )

P rin t J o b

in it ia t e J o b

Interface=method?
< < in t er f ace> > e la b o ra t e d d e s ig n c la s s
co m p u t eJ o b
Prin t J o b

OO view: a component
comput ePageCos t ( )
number Of Pages
comput ePaper Cos t ( ) number Of Sides
comput ePr odCos t ( ) paper Type

contains a set of
comput eTot alJ obC os t ( ) paper Weight
paper Size
paper Color
magnif icat ion
color Requir ement s
pr oduct ionFeat ur es
collaborating classes
collat ionOpt ions
bindingOpt ions
cover St ock
< < in t er f ace> > bleed
in it iat eJ o b pr ior it y
t ot alJ obC os t
buildWor kOr der ( ) WOnumber
checkPr ior it y ( )
pas s J obt o Pr oduct ion( )
comput ePageCos t ( )
comput ePaper Cos t ( )

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
comput ePr odCos t ( )
comput eTot alJ obCos t ( )
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 buildWor kOr der ( )
checkPr ior it y ( )
3
pas s J obt o Pr oduct ion( )
 Conventional Component
d es ig n co m p o nent
g etJ o b Data

Co mp utePag eCo s t

acces s Co s ts DB

Conventional view:
elab o rated m o d ule
 logic, the internal data
structures that are required to
Pag eCo s t

in: numberPages
in: numberDocs implement the processing logic,
and
in: s ides = 1 , 2
in: color=1 , 2 , 3 , 4
in: page s ize = A, B, C, B

 an interface that enables the

out : page cos t
in: job s ize
in: color=1 , 2 , 3 , 4
in: pageSize = A, B, C, B
out : BPC
component to be invoked and
out : SF
data to be passed to it.
g e t J o b Dat a ( n u m b e rP ag e s , n u m b e rDo cs ,
s id e s , co lo r, p ag e S ize , p ag e Co s t ) jo b s ize ( J S ) =
acce s s Co s t s DB (jo b S ize , co lo r, p ag e S ize , n u m b e rP ag e s * n u m b e rDo cs ;
BP C, S F ) lo o ku p b as e p ag e co s t ( BP C) -->
co m p u t e P ag e Co s t( ) acce s s Co s t s DB ( J S , co lo r) ;
lo o ku p s ize fact o r ( S F) -->
acce s s Co s t DB ( J S , co lo r, s ize )
jo b co m p le xit y fact o r ( J CF) =
1 + [ ( s id e s -1 ) * s id e Co s t + S F]
These courseware materials are to be used in conjunction with
p agSoftware
e co s t = BPEngineering:
C * J CF A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
 Cohesion
 Conventional view:
 the “single-mindedness” of a module
 OO view:
 a component or class encapsulates only attributes and operations that are closely
related to one another Levels of cohesion
 Functional, Layer, Communicational, Sequential, Procedural, Temporal, utility

Coupling
 Conventional view:
conventional
 The degree to which a component is connected to other components and to the external
world
OO view: a component contains
 OO view: a set of collaborating classes
 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 5
 Component Level Design
 Step 1. Identify all design classes that correspond to the problem domain,
infrastructure domain.

 Step 2. Elaborate all design classes (not acquired as reusable components).

 Step 2a. Specify message details when classes or component collaborate.
 Step 2b. Identify appropriate interfaces for each component.
 Step 2c. Elaborate attributes and define data types and data structures.
 Step 2d. Describe processing flow within each operation in detail.
What operation?
 Step 3. Describe persistent data sources (databases and files) and identify the classes
required to manage them.
 Step 4. Develop and elaborate behavioral representations for a class or component.
 Step 5. Elaborate deployment diagrams to provide additional implementation detail.
 Step 6. Factor every component-level design representation and always consider
alternatives.
 Is your design the best?

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
 Activity Diagram
v a lid a t e a t t rib u t e s
in p u t

a c c e s s Pa p e rDB (we ig h t )

re t u rn s b a s e C o s t p e rPa g e

p a p e rC o s t p e rPa g e =
b a s e C o s t p e rPa g e

s iz e = B p a p e rC o s t p e rPa g e =
p a p e rC o s t p e rPa g e * 1 . 2

 What is this about wrt.

s iz e = C p a p e rC o s t p e rPa g e =
p a p e rC o s t p e rPa g e * 1 . 4
Component-level design?

s iz e = D p a p e rC o s t p e rPa g e =
p a p e rC o s t p e rPa g e * 1 . 6
 What would be behavioral wrt.
Component-level design?
c o lo r is c u s t o m
p a p e rC o s t p e rPa g e =
p a p e rC o s t p e rPa g e * 1 . 1 4

c o lo r is s t a n d a rd

re t u rn s
( p a p e rC o s t p e rPa g e )

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
 Statechart
b eh avio r w it h in t h e
s t at e b u ild in g Jo b Dat a

d at aIn p u t In co mp let e
buildingJ obDa t a

e nt ry/ re a dJ obDa t a ()
e xit / dis pla yJ obDa t a ()
do/ c he c kCons is t e nc y()
inc lude / da t a Input

d at aIn p u t Co mp let ed [ all d at a

it ems co n s is t en t ] / d is p layUs erOp t io n s

c omput ingJ obCos t

e nt ry/ c omput e J ob
e xit / s a ve t ot a lJ obCos t

jo b Co s t Accep t ed [ cu s t o mer is au t h o rized ] /

 What is this about wrt.
g et Elect ro n icS ig n at u re Component-level design?
formingJ ob

e nt ry/ buildJ ob
e xit / s a ve WOnumbe r
do/
 How does this differ from AD w
Component-level design?
s ubmit t ingJ ob

e nt ry/ s ubmit J ob
e xit / init ia t e J ob
do/ pla c e on J obQue ue

jo b S u b mit t ed[ all au t h o rizat io n s acq u ired ] /

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
p rin t Wo rkOrd er
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
 Collaboration Diagram

:ProductionJob

1: buildJob ( WOnumber )
2: submitJob ( WOnumber )

 What is this about wrt.

Component-level design?
: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 9
 Refactoring
co mp ut eJ o b

PrintJ o b
initiateJ o b

Wo rkOrd er
ap p ro p riat e at t rib u t e s <<interface>>
g etJ o b Des criip tio n b uild J o b init iat eJ o b
b uild Wo rkOrd er ()
p as s J o b To P ro d u ct io n ( )
Pro d uct io nJ o b

s ub mitJ o b
J o b Queue
ap p ro p riat e at t rib u t e s

checkPrio rity ()

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
 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 11
 Stepwise Refinement
Recall:
open

walk to door;
reach for knob;
open door; repeat until door opens
turn knob clockwise;
walk through;if knob doesn't turn, then
close door. 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 12
 Algorithm Design Model
 represents the algorithm at a level of detail
that can be reviewed for quality  At which level?
 options: Component or Class?
 graphical (e.g. flowchart, box diagram)
 pseudocode (e.g., PDL) ... choice of many
 programming language(?)
 decision table
 conduct walkthrough to assess quality

 Is UML inadequate?

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
 Structured Programming
for Procedural Design
uses a limited set of logical constructs:  “go-to” considered ???
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’

 What’s more to Structured Programming than the above?

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
 A Structured Procedural Design
add a condition Z,
a if true, exit the program

x1
b x2 c

x3 d Can you add

something to
f e make this
“unstructured?
x4 ?

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 15
 Decision Tables:
Another Ambiguity Test
[Chung, RE Lecture Notes]

 Natural Language

“The system shall report to the operator all faults that originate in
critical functions or that occur during execution of a critical
sequence and for which there is no fault recovery response.”
(adapted from the specifications for the international space station)

 A decision table
originate in critical functions F T F T F T F T

Occur during critical sequence F F T T F F T T

No fault recovery response F F F F T T T T

Report to operator???

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
 Decision Table
Ru le s

Co n d it io n s 1 2 3 4 5 6

re gu lar cus t om e r T T

s ilve r cus t o m e r T T

g old cus t om e r T T

s p e cial d is cou n t F T F T F T

Ru le s

n o d is co u n t

app ly 8 p e rce n t d is co u n t

app ly 15 pe rce n t d is co u nt

app ly ad d it io n al x p e rce n t d is co u n t

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
 Program Design Language (PDL)
if condition x
then process a;
else process b;
endif
if-then-else 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 18
 Omitted Slides

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
 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 20
 Design Guidelines
 Components
 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
 Interfaces provide important information about communication and
collaboration

 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 21
 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 22
 Refactoring
co mp ut eJ o b

PrintJ o b
initiateJ o b

Wo rkOrd er
ap p ro p riat e at t rib u t e s <<interface>>
g etJ o b Des criip tio n b uild J o b init iat eJ o b
b uild Wo rkOrd er ()
p as s J o b To P ro d u ct io n ( )
Pro d uct io nJ o b

s ub mitJ o b
J o b Queue
ap p ro p riat e at t rib u t e s

checkPrio rity ()

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
 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 24
 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 25
 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 26