Component-Level Design based on Chapter 11 - Software Engineering: A Practitioner’s Approach, 6/e copyright © 1996, 2001, 2005 R.S.

Download Report

Transcript Component-Level Design based on Chapter 11 - Software Engineering: A Practitioner’s Approach, 6/e copyright © 1996, 2001, 2005 R.S.

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 l y si s c l a ss
Pri n t Jo b
What are the differences?
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
Interface=method?
< < 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 des ign 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
OO view: a component
contains a set of collaborating
classes
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
Conventional
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( )
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.
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 ewith
co st =Software
BPC * JCF Engineering:
conjunction
These courseware materials are to be used in
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:


OO view:


conventional
The degree to which a component is connected to other components and to the external
world
OO view: a component contains 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 alidat e at t ribut es
input
ac c es s PaperDB (weight )
ret urns bas eCos t perPage
paperCos t perPage =
bas eCos t perPage
s iz e = B
paperCos t perPage =
paperCos t perPage * 1 . 2
s iz e = C
paperCos t perPage =
paperCos t perPage * 1 . 4
s iz e = D
paperCos t perPage =
paperCos t perPage * 1 . 6
c olor is c us t om
 What is this about wrt.
Component-level design?
 What would be behavioral wrt.
Component-level design?
paperCos t perPage =
paperCos t perPage * 1 . 1 4
c olor 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
7
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
 What is this about wrt.
Component-level design?
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/
 How does this differ from AD wrt.
Component-level design?
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 ] /
These courseware materials are to be used in pconjunction
with Software Engineering: A Practitioner’s Approach, 6/e and are provided
rin t Wo rkOrd er
with 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
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
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;
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
12
Algorithm Design Model


represents the algorithm at a level of detail
that can be reviewed for quality
 At which level?
Component or Class?
options:

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,
if true, exit the program
a
x1
b
x2
x3
d
f
e
c
Can you add
something to
make this
“unstructured??
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
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
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
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


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
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
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
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