software engineering unit 4

33
2/5/2009 2/5/2009 s.sreenivasa Rao s.sreenivasa Rao 1 1 Chapter 9 Chapter 9 Design Engineering Design Engineering

Upload: harshita-gopu

Post on 23-Dec-2015

233 views

Category:

Documents


2 download

DESCRIPTION

Material

TRANSCRIPT

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 11

Chapter 9Chapter 9Design EngineeringDesign Engineering

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 22

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 33

Analysis Model Analysis Model --> Design Model> Design Model

Analysis Model

use-cases - text use-case diagrams activity diagrams swim lane diagrams

data flow diagrams control-flow diagrams processing narratives

f l ow- or i e nt e d e l e me nt s

be ha v i or a le l e me nt s

c l a ss- ba se de l e me nt s

sc e na r i o- ba se de l e me nt s

class diagrams analysis packages CRC models collaboration diagrams

state diagrams sequence diagrams

D a t a / Cla ss D e sig n

A rc h it e c t u ra l D e sign

In t e rf a c e D e sign

Co m p o n e n t - Le v e l D e sign

Design Model

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 44

Design and QualityDesign and Quality•• the design must implement all of the the design must implement all of the

–– explicit requirements contained in the analysis explicit requirements contained in the analysis model,model,

–– implicit requirements desired by the customer.implicit requirements desired by the customer.•• the design must be a readable, the design must be a readable,

understandable guideunderstandable guide for those whofor those who–– generate code generate code –– test test –– support the software.support the software.

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 55

•• the design should provide a complete picture of the design should provide a complete picture of the softwarethe software, addressing the data, functional, , addressing the data, functional, and behavioral domains from an implementation and behavioral domains from an implementation perspective.perspective.

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 66

Quality GuidelinesQuality Guidelines•• A design should exhibit an architectureA design should exhibit an architecture

–– (1) created using recognizable architectural styles or (1) created using recognizable architectural styles or patterns, patterns,

–– (2) composed of components with good design (2) composed of components with good design characteristics characteristics

–– (3) can be implemented in an evolutionary fashion(3) can be implemented in an evolutionary fashion•• For smaller systems, design can sometimes be developed linearlyFor smaller systems, design can sometimes be developed linearly..

•• A design should be modularA design should be modular; ; –– the software should be logically partitioned the software should be logically partitioned

into elements or subsystemsinto elements or subsystems

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 77

••A design should contain distinct A design should contain distinct representationsrepresentations of data, architecture, interfaces, and of data, architecture, interfaces, and components.components.

••A design should lead to data structures that A design should lead to data structures that areare

appropriate for the classes to be implemented appropriate for the classes to be implemented are drawn from recognizable data patternsare drawn from recognizable data patterns..

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 88

Quality Guidelines (cont.)Quality Guidelines (cont.)

•• A design should lead to A design should lead to –– components that exhibit independent components that exhibit independent

functional characteristics.functional characteristics.•• A design should lead toA design should lead to

–– interfaces that reduce the complexityinterfaces that reduce the complexity of of connections between components and with connections between components and with the external environment.the external environment.

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 99

•• A design should be derived using a repeatable A design should be derived using a repeatable methodmethod

that is driven by information obtained during software that is driven by information obtained during software requirements analysis.requirements analysis.

•• A design should be represented using A design should be represented using a notation that effectively communicates its meaning.a notation that effectively communicates its meaning.

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 1010

Fundamental ConceptsFundamental Concepts•• abstractionabstraction——data, procedure, controldata, procedure, control•• architecturearchitecture——the overall structure of the the overall structure of the

softwaresoftware•• patternspatterns——””conveys the essenceconveys the essence”” of a of a

proven design solutionproven design solution•• modularitymodularity——compartmentalization of compartmentalization of

data and functiondata and function•• Information hidingInformation hiding——controlled interfacescontrolled interfaces

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 1111

••Functional independenceFunctional independence——singlesingle--minded minded function and low couplingfunction and low coupling

••Refinement Refinement ——elaboration of detail for all elaboration of detail for all abstractionsabstractions

••RefactoringRefactoring ——a reorganization technique a reorganization technique that simplifies the designthat simplifies the design

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 1212

Data AbstractionData Abstractiondoordoor

implemented as a data structure

manufacturermanufacturermodel numbermodel numbertypetypeswing directionswing directioninsertsinsertslightslights

typetypenumbernumber

weightweightopening mechanismopening mechanism

Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 1313

Procedural AbstractionProcedural Abstractionopenopen

implemented with a "knowledge" of the object that is associated with enter

details of enter details of enter algorithmalgorithm

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 1414

ArchitectureArchitecture““The overall structure of the software and the ways in The overall structure of the software and the ways in which that structure provides conceptual integrity for a which that structure provides conceptual integrity for a system.system.”” [SHA95a][SHA95a]

Structural properties.Structural properties.••Defines the components of a system (e.g., modules, objects, filtDefines the components of a system (e.g., modules, objects, filters) anders) and••How the components are packaged and interact with one another. How the components are packaged and interact with one another.

ExtraExtra--functional properties.functional properties.•• How the design architecture achieves requirements for How the design architecture achieves requirements for

•• performance, capacity, reliability, security, adaptability, andperformance, capacity, reliability, security, adaptability, and other other system characteristics.system characteristics.

Families of related systems.Families of related systems.•• draw upon repeatable patterns that are commonly encountered in draw upon repeatable patterns that are commonly encountered in the design the design of families of similar systems.of families of similar systems.

•• The design should have the ability to reuse architectural buildThe design should have the ability to reuse architectural building blocks.ing blocks.

Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 1515

PatternsPatternsDesign Pattern enables a designer to Design Pattern enables a designer to determine whether the pattern :determine whether the pattern :

•• is applicable to the current workis applicable to the current work•• can be reused can be reused •• can serve as a guide for developing a can serve as a guide for developing a similar, but functionally or structurally similar, but functionally or structurally different pattern.different pattern.

Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 1616

Modular DesignModular Designeasier to build, easier to change, easier to fix ...

Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 1717

Modularity: TradeModularity: Trade--offsoffsWhat is the "right" number of modules What is the "right" number of modules for a specific software design?for a specific software design?

optimal numberoptimal numberof modulesof modules

cost ofcost ofsoftwaresoftware

number of modulesnumber of modules

modulemoduleintegrationintegration

costcost

module development cost module development cost

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 1818

Information HidingInformation Hidingmodulemodule

controlledcontrolledinterfaceinterface

"secret""secret"

•• algorithmalgorithm

•• data structuredata structure

•• details of external interfacedetails of external interface

•• resource allocation policyresource allocation policy

clientsclients

a specific design decisiona specific design decision

Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 1919

Why Information Hiding?Why Information Hiding?•• reduces the likelihood of reduces the likelihood of ““side effectsside effects””•• limits the global impact of local design limits the global impact of local design

decisionsdecisions•• emphasizes communication through controlled emphasizes communication through controlled

interfacesinterfaces•• discourages the use of global datadiscourages the use of global data•• leads to encapsulationleads to encapsulation——an attribute of high an attribute of high

quality designquality design•• results in higher quality softwareresults in higher quality software

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 2020

Functional IndependenceFunctional Independence

COHESION - the degree to which a module performs one and only one function. COUPLING - the degree to which a module is "connected" to other modules in the system.

Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 2121

Stepwise RefinementStepwise Refinementopen

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

Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 2222

RefactoringRefactoring•• Fowler [FOW99] defines Fowler [FOW99] defines refactoringrefactoring in the in the

following manner: following manner: –– ""RefactoringRefactoring is the process of changing a software is the process of changing a software

system in such a way that it does not alter the external system in such a way that it does not alter the external behavior of the code [design] yet improves its internal behavior of the code [design] yet improves its internal structure.structure.””

•• When software is When software is refactoredrefactored, the existing design is , the existing design is examined for examined for –– redundancyredundancy–– unused design elementsunused design elements–– inefficient or unnecessary algorithmsinefficient or unnecessary algorithms–– poorly constructed or inappropriate data structurespoorly constructed or inappropriate data structures–– or any other design failure that can be corrected to yield or any other design failure that can be corrected to yield

a better design.a better design.

Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 2323

OO Design ConceptsOO Design Concepts•• Design classesDesign classes

–– Entity classesEntity classes–– Boundary classesBoundary classes–– Controller classesController classes

•• InheritanceInheritance——all responsibilities of a all responsibilities of a superclasssuperclass is immediately inherited by all is immediately inherited by all subclassessubclasses

•• MessagesMessages——stimulate some behavior to occur stimulate some behavior to occur in the receiving objectin the receiving object

•• PolymorphismPolymorphism——a characteristic that greatly a characteristic that greatly reduces the effort required to extend the reduces the effort required to extend the designdesign

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 2424

A wellA well--formed design classformed design class

•• Complete and sufficientComplete and sufficient–– Encapsulation of attributes and methods that Encapsulation of attributes and methods that

are reasonably expectedare reasonably expected

•• PrimitivenessPrimitiveness–– Methods associated with a design class should Methods associated with a design class should

be focused on accomplishing one service for be focused on accomplishing one service for the classthe class

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 2525

•• High cohesionHigh cohesionA small, focused set of responsibilities And no A small, focused set of responsibilities And no other method to accomplish the same service other method to accomplish the same service singlesingle--mindedly applies attributes and mindedly applies attributes and methods to implement those responsibilitiesmethods to implement those responsibilities

••Low couplingLow couplingCollaboration is necessary, but should be kept Collaboration is necessary, but should be kept to an acceptable to an acceptable minimum.Methodsminimum.Methods only send only send messages to neighboring classesmessages to neighboring classes

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 2626

The Design ModelThe Design Model

process dimension

archit ect ure element s

int erface element s

component -level element s

deployment -level element s

low

high

class diagrams analysis packages CRC models collaborat ion diagrams

use-cases - t ext use-case diagrams act ivit y diagrams sw im lane diagrams collaborat ion diagrams dat a f low diagrams

cont rol- f low diagrams processing narrat ives

dat a f low diagrams cont rol- f low diagrams processing narrat ives

st at e diagrams sequence diagrams

st at e diagrams sequence diagrams

design class realizat ions subsyst ems collaborat ion diagrams

design class realizat ions subsyst ems collaborat ion diagrams

ref inement s t o:

deployment diagrams

class diagrams analysis packages CRC models collaborat ion diagrams

component diagrams design classes act ivit y diagrams sequence diagrams

ref inement s t o:component diagrams design classes act ivit y diagrams sequence diagrams

design class realizat ions subsyst ems collaborat ion diagrams component diagrams design classes act ivit y diagrams sequence diagrams

a na ly sis mode l

de sign mode l

Requirement s: const raint s int eroperabilit y t arget s and conf igurat ion

t echnical int erf ace design Navigat ion design GUI design

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 2727

Design Model ElementsDesign Model Elements•• Data elementsData elements•• Architectural elements Architectural elements (floor plan of a house)(floor plan of a house)

•• Interface elements Interface elements (detailed drawing for doors, windows, (detailed drawing for doors, windows, external utilities)external utilities)

•• Component elements Component elements (detailed drawing of each room, (detailed drawing of each room, wiring, place of switcheswiring, place of switches……))

•• Deployment elementsDeployment elements

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 2828

Design Model ElementsDesign Model Elements•• Data elementsData elements

–– Data model at component level Data model at component level ----> data structures> data structures–– Data model at architecture level Data model at architecture level ----> database architecture> database architecture

•• Architectural elements Architectural elements (floor plan of a house)(floor plan of a house)–– Application domainApplication domain–– Analysis classes, their relationships, collaborations and behaviAnalysis classes, their relationships, collaborations and behaviors are ors are

transformed into design realizationstransformed into design realizations–– Patterns and stylesPatterns and styles

•• Interface elements Interface elements (detailed drawing for doors, windows, external utilities)(detailed drawing for doors, windows, external utilities)–– the user interface (UI) the user interface (UI) –– external interfaces to other systems, devices, networks or otheexternal interfaces to other systems, devices, networks or other r

producers or consumers of informationproducers or consumers of information–– internal interfaces between various design componentsinternal interfaces between various design components. .

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 2929

•• Component elements Component elements (detailed drawing of (detailed drawing of each room, wiring, place of switcheseach room, wiring, place of switches……))–– Internal details of each software componentInternal details of each software component

•• Data structures, Data structures, •• algorithmic details, algorithmic details, •• interface to access component operation (behavior)interface to access component operation (behavior)

•• Deployment elementsDeployment elements–– How software functionality and subsystems will be How software functionality and subsystems will be

allocated within the physical computing allocated within the physical computing environmentenvironment

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 3030

Interface ElementsInterface Elements

Cont rolPanel

LCDdisplay LEDindicat ors keyPadCharact er ist ics speaker wirelessInt erf ace

readKeySt roke() decodeKey () displaySt at us() light LEDs() sendCont rolMsg()

Figure 9 .6 UML int erface represent at ion for Cont ro lPa ne l

KeyPad

readKeyst roke() decodeKey()

< < int erface> >

WirelessPDA

KeyPad

MobilePhone

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 3131

Component ElementsComponent Elements

SensorManagementSensor

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 3232

Deployment ElementsDeployment Elements

Figure 9 .8 UML deploym ent diagram for SafeHom e

Personal comput er

Security

homeManagement

Surveillance

communication

Cont rol Panel CPI server

Security homeownerAccess

externalAccess

2/5/20092/5/2009 s.sreenivasa Raos.sreenivasa Rao 3333

Design PatternsDesign Patterns•• The best designers in any field have an uncanny ability to see The best designers in any field have an uncanny ability to see

patterns that characterize a problem and corresponding patterns patterns that characterize a problem and corresponding patterns that can be combined to create a solutionthat can be combined to create a solution

•• A description of a design pattern may also consider a set of desA description of a design pattern may also consider a set of design ign forces. forces. –– Design forcesDesign forces describe nondescribe non--functional requirements (e.g., ease of functional requirements (e.g., ease of

maintainability, portability) associated the software for which maintainability, portability) associated the software for which the the pattern is to be applied. pattern is to be applied.

•• The The pattern characteristicspattern characteristics (classes, responsibilities, and (classes, responsibilities, and collaborations) indicate the attributes of the design that may bcollaborations) indicate the attributes of the design that may be e adjusted to enable the pattern to accommodate a variety of adjusted to enable the pattern to accommodate a variety of problems.problems.