CS 8532: Adv. Software Eng. – Spring 2009 Dr. Hisham Haddad Chapter 11 CS 8532: Advanced Software...

CS 8532: Adv. Software Eng. – Spring 2009Dr. Hisham Haddad

Chapter 11

CS 8532: Advanced Software Engineering

Dr. Hisham Haddad

Class will

start momentarily.

Please Stand By …


Component-Level Design

Highlights of translating the design model into operational modules/components

Chapter 11


Component Design - 1What 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


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.


Component Design - 3What 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)


OOD View

OO AnalysisOO DesignImplementationOO TestingDeployment

ObjectRelationship

Modeling

ClassModeling

ObjectBehaviorModeling

OO AnalysisOO DesignImplementationOO TestingDeployment

Class Design

Sub-SystemDesign

MessageDesign

ResponsibilitiesDesign


Print Job

computeJob

initiateJob

numberOfPages numberOfSides paperType paperWeight paperSize paperColor magnification colorRequirements productionFeatures collationOptions bindingOptions coverStock bleed priority totalJobCost WOnumber

Print Job

computePageCost () computePaperCost () computeProdCost () computeTotalJobCost () buildWorkOrder() checkPriority() passJobto Production()

elaborated design class<<interface>> computeJob

computePageCost () computePaperCost () computeProdCost () computeTotalJobCost ()

<<interface>> initiateJob

buildWorkOrder() checkPriority() passJobto Production()

design component

numberOfPages numberOfSides paperType magnification productionFeatures

Print Job

computeJobCost() passJobtoPrinter()

analysis class

OO ComponentFigure 11.1, Page 295


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

Conventional Component

Figure 11.3, Page 297


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.


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.


Component-Level Design GuidelinesIn 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.


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.


Component-Level Design - 1Generic 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.


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.


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


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


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


Refinement

openopen

walk to door;reach for knob;

open door;

walk through;close door.

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


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.


Flow-Chart Notation

a

x1

x 2b

3x

4

5

c

d

ef

g

x

x


Decision Tables - 1

Good for representing procedural details of algorithms with complex combinations of conditions and alternative actions.

This notation translates conditionsand actions of a procedure/methodinto tabular format.

It helps verify logic and facilitatetesting.

Rules

Conditions 1 2 3 … n

Condition #1

Condition #2

Condition #3

. . .

Actions

Action #1

Action #2

Action #3

. . .


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


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

Actions

Min monthly charge X

Schedule A billing X X X

Schedule B billing X

Other Billing Formula X


Program Design Language - 1

- 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

if condition x then process a; else process b; endif

PDLif-then-else


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.


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.


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.


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!

CS 8532: Adv. Software Eng. – Spring 2009 Dr. Hisham Haddad Chapter 11 CS 8532: Advanced Software...

Documents

Transcript of CS 8532: Adv. Software Eng. – Spring 2009 Dr. Hisham Haddad Chapter 11 CS 8532: Advanced Software...