1

Chapter 11Component-Level Design

2

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.”

3

OO view of Component Design

A component contains a set of collaborating classes,

Basic design concept Begin with the analysis model Elaborate

Analysis classes Infrastructure classes

Example Print shop

4

OO Component

Prin t J o b

c o m p u t e J o b

in it ia t e J o b

i

il

i

i ii

l

pass J obt o Pr oduct ion( )

d e sig n c o m p o n e n t

n u m b e rO f P a g e s n u m b e rO f S id e s p a p e rT y p e m a g n if i c a t io n p ro d u c t io n F e a t u re s

P rin t J o b

c o m p u t e J o b Co st( ) p a ss J o b t o P rin t e r( )

a n a ly si s c la ss

5

Conventional view of Component Design

Component from conventional view processing logic the internal data structures implementing processing logic an interface that enables the component to be invoked

and data to be passed to it Basic design concept

Begin with the analysis model, usually DFD Transform DFD into structure chart Elaborate each module in structure chart

Control component Problem domain component

Example Print Shop

6

Structure Chart

7

Conventional Component

ComputePageCost

design component

accessCostsDB

getJ obData

elaborated module

PageCost

in: job size in: color=1, 2, 3, 4 in: pageSize = A, B, C, B out: BPC out: SF

in: numberPages in: numberDocs in: sides= 1, 2 in: color=1, 2, 3, 4 in: page size = A, B, C, B out: page cost

job size ( J S) =

numberPages * numberDocs;lookup base page cost (BPC) --> accessCostsDB ( J S, color) ;

lookup size factor ( SF) --> accessCostDB ( J S, color, size)

job complexity factor ( J CF) = 1 + [(sides-1)* sideCost + SF]pagecost = BPC * J CF

getJ obData (numberPages, numberDocs, sides, color, pageSize, pageCost)

accessCostsDB (jobSize, color, pageSize, BPC, SF)computePageCost()

8

Basic OO-Design Principles The Open-Closed Principle (OCP).

“A module [component] should be open for extension but closed for modification.

Example: Detector class for the SafeHome security function

9

Basic OO-Design Principles (cont.)

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. Example – FloorPlan class for the SafeHome

Sensor management may be different from and camera management

Need specific operations for surveillance interface

10

Basic OO-Design Principles (cont.)

Additional packaging principles The Release Reuse Equivalency Principle (REP). “The

granule of reuse is the granule of release.” component level or package level

The Common Closure Principle (CCP). “Classes that change together belong together.”

Class should be packaged cohesively The Common Reuse Principle (CRP). “Classes that

aren’t reused together should not be grouped together.”

11

Guidelines for OO-Component Design

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

For problem domain component: use meaningful name for all stakeholders viewing the

architectural model Example: class FloorPlan

For infrastructure component: Use implementation-specific name Example: manageList()

12

Guidelines for OO-Component Design (cont.)

Interfaces Interfaces provide important information about

communication and collaboration (as well as helping us to achieve the OCP)

Recommendation for simplified UML component diagram Use lollipop representation when diagrams grow

complex Interfaces should flow from the left-hand side of the

component box Show only those interfaces relevant to the component

13

Guidelines for OO-Component Design (cont.)

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)

Represent component interdependencies through interfaces

14

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: Statistics class

The most basic and important

15

Example–Layer Cohesion

16

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: violate information hiding Common: invoke global variable Control: A() invoke B() passing a flag Stamp: a class B is declared as type of operation in A Data: passing long strings of arguments Routine call Type use: a component A use data type defined in B Inclusion or import External

17

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. Example Step 3b. Identify appropriate interfaces for each

component. Check cohesion and apply refactoring. Step 3c. Elaborate attributes and define data types and

data structures required to implement them. Example Step 3d. Describe processing flow within each operation

in detail. Use pseudocode or UML activity diagram.

18

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 for a class or component. Use UML statechart diagram.

Step 6. Elaborate deployment diagrams to provide additional implementation detail. Specific hardware, operating system

Step 7. Factor every component-level design representation and always consider alternatives.

19

Collaboration Diagram

:ProductionJob

:WorkOrder

:JobQueue

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

20

Refactoring

PrintJ ob

computeJ ob

initiateJ ob

ProductionJ ob

buildJ ob

submitJ ob

WorkOrder

appropriate attributes

buildWorkOrder ()getJ obDescriiption

J obQueue

appropriate attributes

checkPriority ()

<<interface>> initiateJ ob

passJ obToProduction()

21

Attribute Type Defined

UML type declaration

paperWeight: string = ‘A’ {contains 1 of 4 values – A,

B, C, or D}

22

Activity Diagram

validate attributes input

accessPaperDB(weight)

returns baseCostperPage

size = B paperCostperPage = paperCostperPage *1 .2

size = C paperCostperPage = paperCostperPage *1 .4

size = D paperCostperPage = paperCostperPage *1 .6

color is custompaperCostperPage = paperCostperPage *1 .1 4

color is standard

paperCostperPage = baseCostperPage

returns( paperCostperPage )

computePaperCost(weight, size, color): numeric

23

Statechart

buildingJ obData

entry/ readJ obData() exit/displayJ obData() do/ checkConsistency() include/ dataInput

entry/ computeJ ob exit/ save totalJ obCost

formingJ ob

entry/ buildJ ob exit/ save WOnumber do/

computingJ obCost

submittingJ ob

entry/ submitJ ob exit/initiateJ ob do/ place on J obQueue

behavior within the state buildingJ obData

dataInputCompleted [all data items consistent]/ displayUserOptions

dataInputIncomplete

jobCostAccepted [customer is authorized]/ getElectronicSignature

jobSubmitted [all authorizations acquired]/ printWorkOrder

Transition form:Event-name (parameter-list)[guard-condition]/action expression

written in Object Constraint Lanaguage (OCL)

Example: for jobCostAccepted event

customer self.authorizationAuthority = ‘yes’

24

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.

25

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

26

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

27

Stepwise Refinement

openopen

walk to door;walk to door;reach for knob;reach for knob;

open door;open door;

walk through;walk through;close door.close door.

repeat until door opensrepeat until door opensturn knob clockwise;turn knob clockwise;if knob doesn't turn, thenif knob doesn't turn, then take key out;take key out; find correct key;find correct key; insert in lock;insert in lock;endifendifpull/push doorpull/push doormove out of way;move out of way;end repeatend repeat

28

Algorithm Design Model

represents the algorithm at a level of detail that can be reviewed for quality

options: graphical (e.g. flowchart, box diagram) pseudocode (e.g., PDL) ... choice of

many programming language decision table conduct walkthrough to assess quality

29

Structured Programmingfor Procedural Design

uses a limited set of logical constructs:uses a limited set of logical constructs: sequencesequence conditionalconditional — — if-then-else, select-caseif-then-else, select-case loopsloops — — do-while, repeat untildo-while, repeat until

leads to more readable, testable codeleads to more readable, testable code

important for achieving high quality, important for achieving high quality, but not enoughbut not enough

can be used in conjunction with ‘proof can be used in conjunction with ‘proof of correctness’of correctness’

30

A Structured Procedural Design

a

x1

x2b

3x

4

5

c

d

ef

g

x

x

add a condition Z, if true, exit the program

31

Decision Table

Conditions

regular customer

silver customer

gold customer

special discount

Rules

no discount

apply 8 percent discount

apply 15 percent discount

apply additional x percent discount

T

F

T

T

T

T

T

F

1 3 5 64

F

T T

T

2

Rules

32

Program Design Language (PDL)

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 procedure easier to maintain

33

component alarmManagement;The intent of this component is to manage control panel switches and input from sensors by type and to act on any alarm condition that is encountered. set default values for systemStatus (return value), all data items initialize all system ports and reset all hardware check controlPanelSwitches (cps) if cps = “test” then invoke alarm set to “on” if cps = “alarmOff” then invoke alarm set to “off” . . . default for cps = none reset all singalValues and switches do for all sensors invoke checkSensor procedure returning singalValue if signalValue > bound [alarmType] then phone.message = message [alarmType] set alarmBell to “on” for alarmTimeSeconds set system status = “alarmCondition” parbegin invoke alarm procedure with “on”, alarmTimeSeconds; invoke phone procedure set to alarmType, phoneNumber parend else skip endif enddoforend alarmManagement

component alarmManagement;The intent of this component is to manage control panel switches and input from sensors by type and to act on any alarm condition that is encountered. set default values for systemStatus (return value), all data items initialize all system ports and reset all hardware check controlPanelSwitches (cps) if cps = “test” then invoke alarm set to “on” if cps = “alarmOff” then invoke alarm set to “off” . . . default for cps = none reset all singalValues and switches do for all sensors invoke checkSensor procedure returning singalValue if signalValue > bound [alarmType] then phone.message = message [alarmType] set alarmBell to “on” for alarmTimeSeconds set system status = “alarmCondition” parbegin invoke alarm procedure with “on”, alarmTimeSeconds; invoke phone procedure set to alarmType, phoneNumber parend else skip endif enddoforend alarmManagement

Example PDL