CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Chapter 11
CS 8532: Advanced Software Engineering
Dr. Hisham Haddad
Class
will
start
momentarily.
Please Stand By …
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Component-Level Design
Highlights of translating the design model into
operational modules/components
Chapter 11
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Component Design - 1
What is it?
Taking the architectural design (high-level abstractions) into a
lower-level procedural details (i.e., filling the operational details
of individual modules of a SD or class operations of an OOD).
It is called procedural design (object design in OOP)
What operational details?
- Sequence
- Condition Structures
- Repetition Structures
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Component Design - 2
Why needed?
- To bring the design model closer to the source code of the
implementation language (translation the design to operational
elements)
- Help verify correctness of previous layers of the design (data,
architectural, and interface of SD or object and message
design of an OOD).
- Reduce potential source code errors in the target code.
- Produce less complex source code that is efficient, readable,
testable, and maintainable.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Component Design - 3
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 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.
• Component-based development view: a component is an
already developed, proven, and tested operational software
module – i.e., available for reuse (Ch-30)
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
OOD View
OO Analysis
OO Design
Implementation
OO Testing
Deployment
Class
Modeling
Object
Relationship
Modeling
Object
Behavior
Modeling
OO Analysis
OO Design
Implementation
OO Testing
Deployment
Sub-System
Design
Message
Design
Class
Design
Responsibilities
Design
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
analysis class
Print Job
OO Component
numberOf Pages
numberOf Sides
paperType
magni f icat ion
produc t ionFeat ures
design component
computeJobCost()
passJobtoPrinter()
computeJob
Figure 11.1, Page 295
Print Job
ini t iateJob
<<int erf ace>>
comput eJob
comput ePageCost ()
comput ePaperCost ()
comput eProdCost ()
comput eTot alJobCost ()
<<int erf ace>>
init iat eJob
buildWorkOrder()
checkPr ior it y()
passJobto Product ion()
elaborated design class
Print Job
numberOf Pages
numberOf Sides
paperType
paperWeight
paper Size
paperColor
magnif icat ion
colorRequirement s
product ionFeat ures
collat ionOpt ions
bindingOpt ions
cover St ock
bleed
priorit y
totalJobCost
WOnumber
computePageCost ()
computePaperCost ()
computeProdCost ()
computeTotalJobCost ()
buildWorkOrder()
checkPriorit y()
passJobto Product ion()
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
design component
getJobData
ComputePageCost
Conventional
Component
Figure 11.3, Page 297
accessCostsDB
elaborated 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, num b erDocs,
sid es, co lo r, p ag eSize , p age Cost )
j o b size ( JS) =
acce ssCo st sDB (j o b Size , colo r, p age Size ,
BPC, SF)
co m p u t e Pag e Co st( )
n um b erPag es * nu m b e rDo cs;
loo ku p b ase p ag e co st ( BPC) -->
acce ssCo st sDB ( JS, co lor) ;
loo ku p size fact or ( SF) -->
acce ssCo st DB ( JS, colo r, size)
j o b co m p le xit y fact o r ( JCF) =
1 + [ ( sid e s-1) * side Co st + SF]
p ag eco st = BPC * JCF
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Component-Level Design Principles
• The Open-Closed Principle (OCP). A module/component should be
open for extension but closed for modification.
Use <interfaces> feature (see figure 11.4, page 299)
• The Liskov Substitution Principle (LSP). Subclasses should be
substitutable for their base classes.
Use <pre> and <post> conditions that base and derived classes
satisfy.
• Dependency Inversion Principle (DIP). Depend on abstractions. Do
not depend on concrete components. Abstraction facilitates
modifications easier than concrete modules.
Use abstraction more often.
• The Interface Segregation Principle (ISP). Many client-specific
interfaces are better than one general purpose interface.
Use specialized interfaces to serve different clients of a class.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Class Packaging Principles
• The Release Reuse Equivalency Principle (REP). The granule of
reuse is the granule of release.
Group related classes into packages so that they are managed
and controlled as new versions, rather than updating individual
classes.
• The Common Closure Principle (CCP). Classes that change
together belong together (Cohesion principle).
Group related classes into packages for effective change control
and release management.
• The Common Reuse Principle (CRP). Classes that aren’t reused
together should not be grouped together (easy to update).
Group related classes into packages so that un-related classes are
not changed and unnecessary integration testing is reduced.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Component-Level Design Guidelines
In addition to design Concepts and Principles (Ch-9):
• Components
- Naming convention: meaningful names for components and
operations derived from the architectural model.
• Interfaces
- Interfaces provide important information about communication
and collaboration (helps achieve the OCP)
• Dependencies and Inheritance
- Model dependencies from left to right and inheritance from
bottom (derived classes) to top (base classes) (for readability).
- Represent dependencies via interfaces rather than
component-to-component dependency.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Again, Cohesion and Coupling
Cohesion and coupling are essential to component-level design.
Conventional view: cohesion is 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.
Conventional view: coupling is the degree to which a component is
connected to other components and to the external world.
OO view: coupling is the a qualitative measure of the degree to
which classes are connected to one another.
See page 303 - 306.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Component-Level Design - 1
Generic Steps (for OOD):
1. Identify all design classes that correspond to the problem
domain (in the analysis and architectural models)
2. Identify all design classes that correspond to the infrastructure
domain (not part of the analysis or architectural models)
3. Elaborate all design classes that are not acquired as reusable
components.
–
–
–
Specify message details (interface) when classes or components
collaborate (from collaboration diagrams).
Elaborate the attributes and define data types and data
structures required to implement them.
Describe processing flow within each operation in detail.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Component-Level Design - 2
4. Describe persistent data sources (databases and files) and
identify the classes required to manage them.
5. Develop and elaborate behavioral representations for a class
or component (State/Statechart diagrams).
6. Elaborate deployment diagrams to provide additional
implementation detail on the key locations of components.
7. Factor every component-level design representation and
always consider alternatives (component internal
improvements)
Please see figures 11.6 – 11.9, and 9.7.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Object Constraint Language (OCL)
- Complements UML by allowing the use of formal grammar and
syntax to construct unambiguous statements about various
design model elements.
- Simplest OCL language statements are constructed in four
parts:
– Context: defines the limited situation in which the statement is
valid;
– Property: represents some characteristics of the context (e.g., if
the context is a class, a property can be an attribute)
– Operation: manipulates or qualifies a property
– Keywords: used to specify conditional expressions
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
OCL Example
OCL invariant statement:
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
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Algorithm Design
It is the closest design activity to coding.
Common 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 the logic
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Refinement
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
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Algorithm Design Model
Procedural design can be represented by different notations.
The goal is to represent the algorithm at a level of detail that can
be reviewed for correctness and quality, and is easy to translate
to source code.
Representation options:
-
Graphical notation (flowchart, box diagram) – page 316
Decision table notation
Pseudocode notation (PDL) <<choice of many>>
Programming language syntax
Conduct walkthroughs to assess quality.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Flow-Chart Notation
a
x1
b
x2
x3
d
f
e
x4
g
x5
c
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Decision Tables - 1
Good for representing procedural
details of algorithms with complex
combinations of conditions and
alternative actions.
Rules
Conditions
Condition #1
Condition #2
This notation translates conditions Condition #3
and actions of a procedure/method . . .
Actions
into tabular format.
It helps verify logic and facilitate
testing.
Action #1
Action #2
Action #3
...
1 2 3
…
n
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Decision Tables - 2
Example scenario: (see another example page 318)
“If the customer account is billed using fixed rate method, a minimum
monthly charge is assessed for consumption of less than 100 kwh.
Otherwise, computer billing applies schedule A rate structure.
However, if the account is billed using variable rate method, a
schedule A rate structure will apply to consumption below 100 kwh,
with additional consumption billed according to schedule B”
Actions: min charge, A rate, B rate, and others.
Conditions: fixed rate, less than 100 kwh,
variable rate, more than 100 kwh
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Decision Tables - 3
Rules
Conditions
1
2
3
4
5
Fixed rate account
T
T
F
F
F
Variable rate account
F
F
T
T
F
Consumption < 100 kwh
T
F
T
F
Consumption >= 100 kwh
F
T
F
T
X
X
X
Actions
Min monthly charge
Schedule A billing
Schedule B billing
Other Billing Formula
X
X
X
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Program Design Language - 1
if-then-else
-
if condition x
then process a;
else process b;
endif
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 procedures
Easier to maintain
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Program Design Language - 2
In addition, PDL can be
- a derivative of the high-level programming languages, such as
Ada PDL,
- a machine readable and processable,
- embedded with source code and therefore easier to maintain,
- represented in great detail, especially if the designer and coder
are different, and
- is easy to review.
See example of PDL syntax page 340.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Attributes of a Representation Notation - 1
Attributes to compare and assess a design notation:
- Modularity: Support for modular design.
- Simplicity: Simple to learn and easy to read and use.
- Editing: Support for design changes and software evolution.
- Machine readability: Can be read by computer-based
development systems.
- Structure enforcement: Support and enforce the use of
structured programming constructs.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Attributes of a Representation Notation - 2
- Automatic processing: Can be processed to generate useful
information about design correctness and quality.
- Data representation: Ability to represent global and local data
structures.
- Logic verification: Ability to verify design logic and improve
testing.
- Code-ability: Can be easily converted to source code.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Suggested Problems
Consider working the following problems from chapter 11,
page 322:
11.1, 11.2, 11.3, 11.7, 11.8, 11.10, 11.12, and 11.14.
NO submission is required. Work them for yourself!