Transcript Transparency Masters for Software Engineering: A

Software Engineering: A Practitioner’s Approach, 6/e
Chapter 11a:
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.
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.
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 c las s
Print J ob
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( )
3
Conventional Component
design component
getJobData
ComputePageCost
accessCostsDB
elaborat ed 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
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.
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).
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
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
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.
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.
10
Collaboration Diagram
:ProductionJob
1: buildJob ( WOnumber )
2: submitJob ( WOnumber )
:WorkOrder
:JobQueue
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 ()
12
Activity Diagram
validat e at t ribut es
input
ac cessPaperDB (weight )
ret urns baseCost perPage
paperCost perPage =
baseCost perPage
s ize = B
paperCost perPage =
paperCost perPage * 1 . 2
s ize = C
paperCost perPage =
paperCost perPage * 1 . 4
size = D
paperCost perPage =
paperCost perPage * 1 . 6
color is cust om
paperCost perPage =
paperCost perPage * 1 . 1 4
c olor is st andard
ret urns
( paperCost perPage )
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
14