Chapter 14

 Component-Level Design
Slide Set to accompany
Software Engineering: A Practitioner’s
Approach, 8/e
by Roger S. Pressman and Bruce R. Maxim

Slides copyright © 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 8/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 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: a component contains
processing 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 slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 2
OO a n a ly sis c la ss

Prin t Jo b

Component n u m b e rOf Pa g e s
n u m b e rOf Sid e s
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 Fe a t u re s
d e sig n c o m p o n e n t
c o m p u t e Jo b Co st( ) c o m p u t e Jo b
p a ssJo b t o Prin t e r( )

Prin t Jo b

in it ia t e Jo b

< < in t er f ace> >

e laborat e d de s ign c las s
co m p u t eJo b
Print J ob
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 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 ( )
These slides are designed to accompany Software Engineering: A passJobt o Pr oduct ion( )

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by

Roger Pressman. 3
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 slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 4
 The OCP in Action (pg 293)
 The scene: guys have come up with.
 Vinod's cubicle.  Shakira: Amaze me.
 The players:  Vinod (laughing): They call it a
 Vinod, Shakira doggie angst sensor.
members of the SafeHome software
engineering team.
 Shakira: Say what?
 The conversation:  Vinod: It's for people who leave
 Vinod: I just got a call from Doug 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 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 alarm mode that calls the owner on
going to believe what these his or her cell phone.
 Shakira: You're kidding me, right?
5

5
 Vinod: Nope. Doug wants to know  Shakira: Knowing Doug, he'll keep
how much time it's going to take to us focused and not deliver the
add it to the security function. doggie thing until the next release.
 Shakira (thinking a moment): Not  Vinod: That's not a bad thing, but
much ... look. [She shows Vinod can you implement now if he wants
Figure 11.4] We've isolated the you to?
actual sensor classes behind the  Shakira: Yeah, the way we designed
sensor interface. As long as we the interface lets me do it with no
have specs for the doggie sensor, hassle.
adding it should be a piece of cake.  Vinod: have you ever heard of the
Only thing I'll have to do is create an
open-closed principle?
appropriate component ... uh, class,
for it. No change to the Detector
 Shakira: Never heard of it
component at all.  Vinod (smiling): Not a problem
 Vinod: So I'll tell Doug it's no big
<<interface
deal >>
Sensor
read() Detecto
enable() r
disable()
test()

Window/ Smoke Motion Heat CO2

door sensor detector sensor sensor
sensor 6
Source: Martin, R., “Design Principles and Design Patterns,” downloaded from http://
www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

7
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 (as
well as helping us to achieve the OCP)
 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 slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 8
 Cohesion
 Conventional view:
 the “single-mindedness” of a module
 OO view:
 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 slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 9
 Cohesion
 OO view:
 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: all operations that access the same data
 Sequential: passing data from the first op to the following ops
 Procedural: similar to Sequential, not without data passing
 Temporal: ex. Error handling class, initialization class
 Utility: ex. Statistics class

10
 Cohesion in Action (pg 297)
 The scene:  Ed: We originally defined five
 Jamie's cubicle. operations for camera. Look ...
 The players: [shows Jamie the list]
 Jamie, Ed  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-cut design of the  displayView() shows me the field of
camera component. view of the camera graphically.
 displayZoom() shows me the
 Jamie: Wanna do a quick review?
magnification of the camera
 Ed: I guess ... but really, I'd like graphically.
your input on something.  Ed: I've designed each separately,
 (Jamie gestures for him to and they're pretty simple
continue.) operations. So I thought

11

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()--it'll show the ID, easier to implement, I think.
the view, and the zoom.  Jamie: And what if marketing
Whaddaya think? decides to change the way that we
 Jamie (grimacing): Not sure represent the view field?
that's such a good idea.  Ed: I'll just jump into the
 Ed (frowning): Why? All of these displayCamera() op and make the
little ops can cause headaches. mod.
 Jamie: The problem with  Jamie: What about side effects?
combining them is we lose  Ed: Whaddaya mean?
cohesion. You know, the  Jamie: Well, say you make the
displayCamera() op won't be
change but inadvertently create a
single-minded.
problem with the ID display.

12

12
 Ed: I wouldn't be that sloppy.  Jamie: Good decision.
 Jamie: Maybe not, but what if
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,
he might be sloppy.
 Ed: So you're against it?
 Jamie: You're the designer . . . it's
your decision . . . just be sure you
understand the consequences of
low cohesion.
 Ed (thinking a moment): Maybe
we'll go with separate display ops.

13

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: one component modifies data of another component
 Common: when components make use of a global variable
 Control: A() invokes B() and passes a control flag to B
 Routine call: one op invokes another
 Type use: class A uses a data type defined in class B
 Inclusion or import
 External coupling: when a component collaborates with infrastructure
ocmponents

14
 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.
 Ex. GUI components, OS components, object & data management
components, etc
 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.
 Step 3c. Elaborate attributes and define data types and data structures
required to implement them.
 Step 3d. Describe processing flow (activity diagram) within each
operation in detail.

15
 Component-Level Design-II
 Step 4. Describe persistent data sources (databases
and files) and identify the classes 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 7. Factor every component-level design
representation and always consider alternatives.

16
Collaboration Diagram
:ProductionJob

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

:WorkOrder

:JobQueue

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 17
 Refactoring (see
page3)
co mp uteJo b

PrintJo b
initiateJo b

Wo rkOrd er
ap p ro p riat e at t rib u t e s <<interface>>
g etJo b Descriip tio n b uild Jo b initiateJo b
b uild Wo rkOrd er ()
p assJ o b To Pro d u ct io n ( )
Pro d uctio nJo b

sub mitJo b
Jo b Queue
ap p ro p riat e at t rib u t e s

checkPrio rity ()
18
 va lida t e a t t ribut e s
input

Activity Diagram a c c e s s Pa pe rDB (we ight )

re t urns ba s e C os t pe rPa ge

pa pe rC os t pe rPa ge =
ba s e C os t pe rPa ge

s iz e = B pa pe rC os t pe rPa ge =
pa pe rC os t pe rPa ge *1 . 2

s iz e = C pa pe rC os t pe rPa ge =
pa pe rC os t pe rPa ge *1 . 4

s iz e = D pa pe rC os t pe rPa ge =
pa pe rC os t pe rPa ge *1 . 6

c olor is c us t om
pa pe rC os t pe rPa ge =
pa pe rC os t pe rPa ge *1 . 1 4

c olor is s t a nda rd

re t urns
( pa pe rC os t pe rPa ge )

19
 b eh avio r w it h in t h e
st at e b u ild in g Jo b Dat a

Statechar
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 ()

t 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 isp layUserOp 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 st Accep t ed [ cu st o mer is au t h o rized ] /

g et Elect ro n icSig n at u re

formingJ ob

e nt ry/ buildJ ob
e xit / s a ve WOnumbe r
do/

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 Su b mit t ed[ all au t h o rizat io n s acq u ired ] /

p rin t Wo rkOrd er 20
Designing Conventional
Components
 The design of processing logic is
governed by the basic principles of
algorithm design and structured
programming
 The design of data structures is
defined by the data model developed
for the system
 The design of interfaces is governed
by the collaborations that a
component must effect

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 21
Component-Based
Development
 When faced with the possibility of
reuse, the software team asks:
 Are commercial off-the-shelf (COTS)
components available to implement the
requirement?
 Are internally-developed reusable
components available to implement the
requirement?
 Are the interfaces for available components
compatible within the architecture of the
system to be built?
 At the same time, they are faced with
the following impediments to reuse ...
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 22
Impediments to
Reuse  Few companies and organizations have anything that even
slightly resembles a comprehensive software reusability
plan.
 Although an increasing number of software vendors
currently sell tools or components that provide direct
assistance for software reuse, the majority of software
developers do not use them.
 Relatively little training is available to help software
engineers and managers understand and apply reuse.
 Many software practitioners continue to believe that reuse
is “more trouble than it’s worth.”
 Many companies continue to encourage of software
development methodologies which do not facilitate reuse
 Few companies provide an incentives to produce reusable
program components.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 23
The CBSE
ProcessDomain Engineering

Reusable
Domain Software
Architecture Artifact
Analysis
Development Development

Repository
Domain Structural Reusable
model Model Artifacts/
Components

Software Engineering

System Specification
& Construction
Analysis
User Design
Requirements

Analysis Application
System
& Design
Spec Models Software

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 24
 Domain Engineering
1. Define the domain to be investigated.
2. Categorize the items extracted from the
domain.
3. Collect a representative sample of
applications in the domain.
4. Analyze each application in the sample.
5. Develop an analysis model for the objects.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 25
Identifying Reusable
Components
• Is component functionality required on future implementations?
• How common is the component's function within the domain?
• Is there duplication of the component's function within the
domain?
• Is the component hardware-dependent?
• Does the hardware remain unchanged between implementations?
• Can the hardware specifics be removed to another component?
• Is the design optimized enough for the next implementation?
• Can we parameterize a non-reusable component so that it becomes
reusable?
• Is the component reusable in many implementations with only
minor changes?
• Is reuse through modification feasible?
• Can a non-reusable component be decomposed to yield reusable
components?
• How valid is component decomposition for reuse?
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 26
Component-Based
SE a library of components must be
available
 components should have a
consistent structure
 a standard should exist, e.g.,
 OMG/CORBA
 Microsoft COM
 Sun JavaBeans

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 27
CBSE Activities
 Component qualification
 Component adaptation
 Component composition
 Component update

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 28
 Qualificati
on
Before a component can be used, you must consider:

• application programming interface (API)

• development and integration tools required by the
component
• run-time requirements including resource usage (e.g.,
memory or storage), timing or speed, and network protocol
• service requirements including operating system interfaces
and support from other components
• security features including access controls and authentication
protocol
• embedded design assumptions including the use of specific
numerical or non-numerical algorithms
• exception handling

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 29
 Adaptati
on
The implication of “easy integration” is:
(1) that consistent methods of resource
management have been implemented for all
components in the library;
(2) that common activities such as data
management exist for all components, and
(3) that interfaces within the architecture and
with the external environment have been
implemented in a consistent manner.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 30
 Compositi
on
 An infrastructure must be established to
bind components together
 Architectural ingredients for
composition include:
 Data exchange model
 Automation
 Structured storage
 Underlying object model

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 31
OMG/ CORBA
 The Object Management Group has published a common
object request broker architecture (OMG/CORBA).
 An object request broker (ORB) provides services that
enable reusable components (objects) to communicate with
other components, regardless of their location within a
system.
 Integration of CORBA components (without modification)
within a system is assured if an interface definition
language (IDL) interface is created for every component.
 Objects within the client application request one or more
services from the ORB server. Requests are made via an
IDL or dynamically at run time.
 An interface repository contains all necessary information
about the service’s request and response formats.
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 32
ORB Architecture
Interface Client
Repository

Dynamic Client ORB

Invocation IDL interface
Stubs

Server
LAN Objects
ORB Core

Server
ORB Object
interface IDL Adapter
Stubs Interface
Repository

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 33
Microsoft COM
 The component object model (COM) provides a
specification for using components produced by
various vendors within a single application running
under the Windows operating system.
 COM encompasses two elements:
 COM interfaces (implemented as COM objects)
 a set of mechanisms for registering and passing messages
between COM interfaces.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 34
Sun JavaBeans
 The JavaBeans component system is a portable,
platform independent CBSE infrastructure
developed using the Java programming language.
 The JavaBeans component system encompasses a
set of tools, called the Bean Development Kit
(BDK), that allows developers to
 analyze how existing Beans (components) work
 customize their behavior and appearance
 establish mechanisms for coordination and
communication
 develop custom Beans for use in a specific application
 test and evaluate Bean behavior.
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by
Roger Pressman. 35