Chapter 11

Component--Level Design
Component
Moonzoo Kim
CS Division of EECS Dept.
KAIST
moonzoo@cs.kaist.ac.kr
http://pswlab.kaist.ac.kr/courses/CS350-07

CS350 Intro. to SE
Spring 2008 1
 Overview of Ch 11.
M d li Component
Modeling C
Component-t-level
l l Design
D i
„ 11.1 What is a component
„ An
A object-
object
bj t-oriented
i t d view
i
„ 11.2 Designing class-
class-based components
„ Basic design
g pprinciples
p
„ Component--level design guidelines
Component
„ Cohesion
„ Coupling
„ 11.3 Conducting component-
component-level design
„ 11.4 Object constraint language (OCL)
„ 11.5 Designing conventional components
„ Graphical design notation
„ Tabular design
g notation
„ Program design language
CS350 Intro. to SE
Spring 2008 2
 What is a Component?
„ OMG Unified Modelingg Language
g g Specification
p [[OMG01]]
defines a component as
„ “… a modular, deployable, and replaceable part of a system that
encapsulates implementation and exposes a set of interfaces
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.

CS350 Intro. to SE
Spring 2008 3
 OO Component
Analysis class
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
Design component
m agnif ic at ion
c o m p u t e Jo b
p ro d u c t i o n Fe a t u re s

c o m p u t e Jo b Co st( ) Pri n t Jo b
p a ssJo b t o Pri n t e r( )

i n i t i a t e Jo b

< < in
i t er f ace>
>>
co m p u t eJo b
Elaborated
abo ated design
des g class
c ass
Print Job
comput ePageCost ( ) number Of Pages
comput ePaper Cost ( ) number Of Sides
comput ePr odCost ( ) paper Type
comput eTot alJobCost ( ) paper Weight
paper Size
paper Color
magnif icat ion
color Requir
q ement s
pr oduct ionFeat ur es
collat ionOpt ions
bindingOpt ions
cover St ock
< < in t er f ace> > bleed
in it iat eJo b pr ior it y
t ot alJobCost
buildWor kOr der ( ) WOnumber
checkPr ior it y ( )
passJobt o Pr oduct ion( ) comput ePageCost ( )
comput ePaper Cost ( )
comput ePr odCost ( )
comput eTot alJobCost ( )
buildWor kOr der ( )
checkPr ior it y ( )
passJobt o Pr oduct ion( )

CS350 Intro. to SE
Spring 2008 4
 Basic Design Principles
„ The Open
Open--Closed Principle (OCP).
„ “A module [component] should be open for extension but closed for
modification.
modification
„ The Liskov Substitution Principle (LSP).
„ “Subclasses should be substitutable for their base classes.
„ Dependency Inversion Principle (DIP)
(DIP).
„ “Depend on abstractions. Do not depend on concretions.”
„ The Interface Segregation Principle (ISP).
„ “Many
Many client-
client-specific interfaces are better than one general purpose interface
interface.
„ The Release Reuse Equivalency Principle (REP).
„ “The granule of reuse is the granule of release.”
„ The Common Closure Principle (CCP)
(CCP).
„ “Classes that change together belong together.”
„ The Common Reuse Principle (CRP).
„ “Classes
Classes that aren’t
aren t reused together should not be grouped together
together.”

CS350 Intro. to SE
Spring 2008 5
Source: Martin, R., “Design Principles and Design Patterns,”
downloaded from http://www.objectmentor.com, 2000.

CS350 Intro. to SE
Spring 2008 6
 The OCP in Action (pg332)
„ The scene: guys have come up with.
„ Vinod's cubicle. „ Shakira:: Amaze me.
Shakira
„ The players: „ Vinod ((laughing):
g g) Theyy call it a
„ Vinod, Shakira doggie angst sensor.
members of the SafeHome software
engineering team. „ Shakira:: Say what?
Shakira
„ The conversation: „ Vinod:: It
Vinod It'ss for people who leave
„ Vinod:: I just got a call from Doug
Vinod their pets home in apartments or
[the team manager]. He says condos or houses that are close to
marketing wants to add a new one another. The dog g starts to bark.
sensor. The neighbor gets angry and
complains. With this sensor, if the
„ Shakira (smirking): Not again,
dog barks for more than, say, a
jeez!
minute, the sensor sets a special
„ Vinod:: Yeah ... and you're not
Vinod alarm mode that calls the owner on
going to believe what these his or her cell phone.
„ Shakira:: You're kidding me, right?
Shakira
CS350 Intro.
Intro. to
toSE
SE
Spring2008
Spring 2008 7
„ Vinod: Nope. Doug wants to know
Vinod: deal.
how much time it's going to take to „ Shakira:: Knowing Doug, he'll keep
Shakira
add it to the security function. us focused and not deliver the
„ Shakira (thinking a moment): Not doggie thing until the next release.
much ... look. [She shows Vinod „ Vinod:: That's not a bad thing, but
Vinod
Figure 11.4] We've isolated the can you implement now if he wants
actual
t l sensor classes
l b
behind
hi d th
the you to?
sensor interface. As long as we „ Shakira:: Yeah, the way we
Shakira
have specs for the doggie sensor, designed the interface lets me do it
adding it should be a piece of cakecake. with no hassle.
Only thing I'll have to do is create an
„ appropriate component ... uh, class,
for it.
it No change to the Detector
component at all.
„ Vinod:: So I'll tell Doug it's no big
Vinod

CS350 Intro.
Intro. to
toSE
SE
Spring2008
Spring 2008 8
 Design Guidelines
„ Components
p
„ 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
component--level model
„ Interfaces
„ 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).

CS350 Intro. to SE
Spring 2008 9
 Cohesion
„ OO view:
„ cohesion implies that a component or class
encapsulates
l t only l attributes
tt ib t andd operations
ti th
thatt are
closely related to one another and to the class or
component itself
„ Levels of cohesion
„ Functional
„ Layer
„ Communicational
„ Sequential
„ Procedural
„ Temporal
„ utility
y

CS350 Intro. to SE
Spring 2008 10
 Cohesion in Action (pg336-
(pg336-337)
„ The scene: „ Ed: We originally defined five
Ed:
„ Jamie's cubicle. operations for camera. Look ...
„ The players: [shows Jamie the list]
„ Jamie, Ed
Jamie, „ determineType() tells me the type of
members of the SafeHome software camera.
engineering team who are working on „ translateLocation() allows me to move
the surveillance function. the camera around the floor plan.
„ displayID() gets the camera ID and
„ The conversation:
displays it near the camera icon.
„ Ed:: I have a first-
Ed first-cut design of the „ displayView() shows me the field of
camera component
component. view of the camera graphically
graphically.
„ displayZoom() shows me the
„ Jamie:: Wanna do a quick review?
Jamie
magnification of the camera graphically.
„ Ed:: I guess ... but really, I'd like
Ed „ Ed: I've designed each separately,
Ed:
your input on something
something. and they're pretty simple
„ (Jamie gestures for him to operations. So I thought
continue.)

CS350 Intro.
Intro. to
toSE
SE
Spring2008
Spring 2008 11
 it might be a good idea to combine „ Ed (mildly exasperated): So
all of the display operations into what? The whole thing will be less
just one that's called than 100 source lines, max. It'll be
displayCamera()--
di l C
displayCamera() ()--it'll
it'll show
h th
the ID
ID, easier
i tto implement,
i l t I think.
thi k
the view, and the zoom. „ Jamie:: And what if marketing
Jamie
Whaddaya think? decides to change the way that we
„ J i (grimacing):
Jamie ( i i ) Not N t sure representt theth view
i fifield?
ld?
that's such a good idea. „ Ed:: I'll just jump into the
Ed
„ Ed (frowning): Why? All of these displayCamera() op and make the
li l ops can cause h
little headaches.
d h mod.
d
„ Jamie:: The problem with
Jamie „ Jamie:: What about side effects?
Jamie
combining them is we lose „ Ed: Whaddaya mean?
cohesion. You know, the „ Jamie:: Well, say you make the
Jamie
displayCamera() op won't be change but inadvertently create a
single--minded.
single problem with the ID display.
p p y

CS350 Intro.
Intro. to
toSE
SE
Spring2008
Spring 2008 12
„ Ed: I wouldn't be that sloppy.
Ed: sloppy. „ Jamie:: Good decision.
Jamie
„ Jamie:: Maybe not, but what if
Jamie
some support person two years
from now has to make the mod.
He might not understand the op as
well as you do and, who knows,
h might
he i ht b
be sloppy.
l
„ Ed:: So you're against it?
Ed
„ Jamie:: You're the designer . . . it's
Jamie
your decision . . . just be sure you
understand the consequences of
low cohesion.
„ Ed (thinking a moment): Maybe
we'll go with separate display ops.

CS350 Intro.
Intro. to
toSE
SE
Spring2008
Spring 2008 13
 Coupling
„ Conventional view:
„ The degree to which a component is connected to
other components and to the external world
„ OO view:
„ 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

CS350 Intro. to SE
Spring 2008 14
 Component Level Design
Design--I
„ Step 1. Identify all design classes that correspond to
the problem domain.
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.
„ St 3a.
Step 3 Specify
S if message details
d t il when
h classes
l or
component collaborate.
„ Step 3b. Identify appropriate interfaces for each component.
„ Step 3c. Elaborate attributes and define data types and data
structures required to implement them.
„ Stepp 3d. Describe processing
p g flow ((activity
y diagram)
g ) within
each operation in detail.
CS350 Intro. to SE
Spring 2008 15
 Component--Level Design
Component Design--II
„ Step 4. Describe persistent data sources
(d t b
(databases and
d fil
files)) and
d id
identify
tif ththe classes
l
required to manage them.
„ Step 5. Develop and elaborate behavioral
representations (statechart) for a class or
component.
„ Step 6. Elaborate deployment diagrams to provide
additional implementation detail.
„ Step
p 7. Factor every y component-
component
p -level design
g
representation and always consider alternatives
CS350 Intro. to SE
alternatives..
Spring 2008 16
 Collaboration Diagram

:ProductionJob

1: buildJob ( WOnumber )
2: submitJob ( WOnumber )
[x>1] y:= f(WOnumber)

:WorkOrder

:JobQueue

CS350 Intro. to SE
Spring 2008 17
Processing Flow in
validat e at t ribut es

Activity Diagram input

p

accessPaperDB (weight )

ret urns baseCost perPage

paperCost perPage =
baseCost perPage

size
i = B paperCost perPage =
paperCost perPage * 1 . 2

size = 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

color is s t andard

ret urns
( paperCos t perPage )

CS350 Intro. to SE
Spring 2008 18
 b eh avio r w it h in t h e
st at e b u ild in g Jo b Dat a

Behavioral d at aIn p u t In co mp let e

buildingJobDat a

Representation ent r y/ readJobDat a ()

exit / displayJobDat a ( )
do/ checkConsist ency( )

in Statechart 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 r y/ 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

CS350 Intro. to SE j o b Su b mit t ed[ all au t h o rizat io n s acq u ired ] /

Spring 2008 p rin t Wo rkOrd er 19
 Object
j Constraint Language
g g (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
p OCL language
g g 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
ti (e.g.,
( arithmetic,
ith ti set-
sett-oriented)
i t d) th
thatt manipulates
i l t or
qualifies a property, and
„ (4) keywords (e.g., if, then, else, and, or, not, implies) that are used
t specify
to if conditional
diti l expressions.
i
CS350 Intro. to SE
Spring 2008 20
 OCL Example
context PrintJob::validate(upperCostBound :
Integer, custDeliveryReq :
Integer)
pre: upperCostBound > 0
and custDeliveryReq
y q>0
and self.jobAuthorization = 'no'
post: if self.totalJobCost <= upperCostBound
and self.deliveryDate <= custDeliveryReq
then
self.jobAuthorization = 'yes'
endif

CS350 Intro. to SE
Spring 2008 21
 Algorithm
g Design
g
„ the closest design
activity to coding open
„ the approach:
„ review the design walk to door;
description for the reach for knob;
component
„ use stepwise open door; repeat until door opens
turn knob clockwise;
refinement to walk through; if knob doesn't
doesn t turn
turn, then
develop algorithm close door. take key out;
„ use structured find correct key;
programming to insert in lock;
endif
implement pull/push door
procedural logic move out of way;
„ use ‘formal
‘formal methods’
methods’ end repeat
to prove logic

CS350 Intro. to SE
Spring 2008 22
 Algorithm
g Design
g Model
„ represents the algorithm at a level of
detail that can be reviewed for quality
„ options:
„ graphical (e.g. flowchart, box diagram)
„ pseudocode
d d ((e.g., PDL) ... choice of many
„ programming language

„ decision table
„ conduct walkthrough to assess quality

CS350 Intro. to SE
Spring 2008 23
 Structured Programming
for Procedural Design
uses a limited set of logical constructs:
sequence
conditional — if
if--then-
then-else, select-
select-case
l
loops — do
d -while,
do- h l repeat untill
leads to more readable, testable code
can be used in conjunction with ‘proof of
correctness’
important for achieving high quality,
but not enough

CS350 Intro. to SE
Spring 2008 24
 A Structured Procedural Design
add a condition Z,
a if true, exit the program

x1
b x2 c

x3 d

f e

x4

x5

CS350 Intro. to SE
Spring 2008 25
 Decision Table
Rule s

Condit ions 1 2 3 4 5 6

regular cust omer T T

silver cust omer T T

gold cust omer T T

special discount F T F T F T

R l s
Rule

no discount

apply 8 percent discount

apply 15 percent discount

apply addit ional x percent discount

CS350 Intro. to SE
Spring 2008 26
Program Design Language (PDL)
if condition x
then process a;
else p
process b;
;
endif
if-then-else PDL
„ E
Easy tto combine
bi withith source coded
„ Can be represented in great detail
„ M hi readable,
Machine d bl no need d ffor graphics
hi iinputt
„ Graphics can be generated from PDL
„ E bl d
Enables declaration
l ti off d data
t as wellll as
procedure
„ Easier to review and maintain
CS350 Intro. to SE
Spring 2008 27
CS350 Intro. to SE
Spring 2008 28