Chapter 9Chapter 9 Design Engineering - KAISTpswlab.kaist.ac.kr/courses/cs350-08/ch9.pdf ·...

Chapter 9Chapter 9Chapter 9Chapter 9Design EngineeringDesign Engineering

Moonzoo KimCS Division of EECS DeptCS Division of EECS Dept.

KAIST [email protected]

http://pswlab kaist ac kr/courses/CS350 07http://pswlab.kaist.ac.kr/courses/CS350-07

CS350 Intro. to SE Spring 2008 1

Roadmap of SEPA covered in CS350Roadmap of SEPA covered in CS350Roadmap of SEPA covered in CS350Roadmap of SEPA covered in CS350Ch 1 Ch 1 –– Ch 5Ch 5

1 I t t SE1 I t t SE

Ch 7Ch 7-- Ch 9Ch 97. Requirement 7. Requirement

Ch 10 Ch 10 –– Ch 14Ch 1410. Creating an 10. Creating an

1. Intro to SE1. Intro to SE2. A2. A Generic View Generic View of Processof Process

qqEngineeringEngineering

Req. eng tasksReq. eng tasksReq. elicitationReq. elicitationDeveloping useDeveloping use--

ggArchitectural Design Architectural Design 11. Modeling 11. Modeling ComponentComponent--Level Level

3. Process Models3. Process Models4. An Agile View 4. An Agile View of Processof Process

Developing useDeveloping use--casescasesBuilding the Building the analysis modelanalysis model

8 Building the8 Building the

ppDesignDesign12. Performing UI 12. Performing UI DesignDesign

5. SE Practice5. SE Practice6. System 6. System EngineeringEngineering

8. Building the 8. Building the Analysis ModelAnalysis Model9. Design 9. Design EngineeringEngineering

gg13. Testing 13. Testing Strategies Strategies 14 Testing Tactics14 Testing TacticsEngineeringEngineering

SafeHomeSafeHome ProjectProject-- UseUse--case diagramcase diagram

14. Testing Tactics14. Testing TacticsSafeHomeSafeHome ProjectProject-- Class diagramClass diagram

CRC cardsCRC cards


gg-- UseUse--casescases-- Activity diagramActivity diagram

-- CRC cards CRC cards -- Sequence diagramSequence diagram-- State diagram State diagram

Overview of Ch 9. Design EngineeringOverview of Ch 9. Design EngineeringOverview of Ch 9. Design EngineeringOverview of Ch 9. Design Engineering

9.1 Design within the Context of SE9.1 Design within the Context of SE 9.4 Design Model9.4 Design Model9.2 Design Process and Design 9.2 Design Process and Design QualityQuality9.3 Design Concepts 9.3 Design Concepts

ggData Design ElementsData Design ElementsArchitectural Design ElementsArchitectural Design ElementsInterface Design ElementsInterface Design Elements

AbstractionAbstractionArchitectureArchitecturePatternsPatternsM d l itM d l it

ComponentComponent--level Design level Design ElementsElementsDeploymentDeployment--level Design level Design ElementsElementsModularityModularity

Information HidingInformation HidingFunctional IndependenceFunctional IndependenceRefinementRefinement

ElementsElements9.5 Pattern9.5 Pattern--based SW Designbased SW Design

Describing a Design PatternDescribing a Design PatternUsing Patterns in DesignUsing Patterns in DesignRefinementRefinement

RefactoringRefactoringDesign ClassesDesign Classes

Using Patterns in DesignUsing Patterns in DesignFrameworksFrameworks


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

use-cases - textuse-case diagrams

data flow diagramscontrol flow diagrams

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

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

Com pone nt -Le v e l De sign

Analysis Model

use case diagramsactivity diagramsswim lane diagrams

control-flow diagramsprocessing narratives

In t e rf a c e De sign

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

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

class diagrams state diagrams

Arc hit e c t ura l De sign

ganalysis packagesCRC modelscollaboration diagrams

state dag a ssequence diagrams Da t a / Cla ss De sign

Design Model


Design Model

Design and QualityDesign and QualityDesign and QualityDesign and Quality

TheThe design must implement all of the explicitdesign must implement all of the explicitThe The design must implement all of the explicit design must implement all of the explicit requirementsrequirements contained in the analysis model, and it contained in the analysis model, and it must accommodate all of the implicit requirements must accommodate all of the implicit requirements desired by the customer.desired by the customer.The The design must be a readable, design must be a readable, understandableunderstandable guideguidefor those who generate code and for those who test andfor those who generate code and for those who test andfor those who generate code and for those who test and for those who generate code and for those who test and subsequently support the software.subsequently support the software.the design should provide a complete picture of thethe design should provide a complete picture of thethe design should provide a complete picture of the the design should provide a complete picture of the softwaresoftware, addressing the data, functional, and behavioral , addressing the data, functional, and behavioral domains from an domains from an implementationimplementation perspective.perspective.


pp p pp p

Quality GuidelinesQuality Guidelines1.1. A design should exhibit an architectureA design should exhibit an architecture whichwhich

1.1. has been created using recognizable has been created using recognizable architectural styles architectural styles or patterns, or patterns, 22 is composed of components that exhibitis composed of components that exhibit good design characteristicsgood design characteristics2.2. is composed of components that exhibit is composed of components that exhibit good design characteristics good design characteristics 3.3. can be implemented in an can be implemented in an evolutionary fashionevolutionary fashion

2.2. A design should be A design should be modularmodular33 A design should contain distinct representationsA design should contain distinct representations of data architectureof data architecture3.3. A design should contain distinct representations A design should contain distinct representations of data, architecture, of data, architecture,

interfaces, and components.interfaces, and components.4.4. A design should lead to data structures that are A design should lead to data structures that are

11 appropriate for the classes to be implementedappropriate for the classes to be implemented1.1. appropriate for the classes to be implemented appropriate for the classes to be implemented 2.2. drawn from recognizable data patterns.drawn from recognizable data patterns.

5.5. A design should lead to components that exhibit independent functional A design should lead to components that exhibit independent functional characteristics.characteristics.

6.6. A design should lead to interfaces that reduce the complexityA design should lead to interfaces that reduce the complexity of connections of connections between components and with the external environmentbetween components and with the external environment..

7.7. A design should be represented A design should be represented effectively effectively for communicating its meaning.for communicating its meaning.


Quality AttributesQuality Attributes –– FURPS [GRA87]FURPS [GRA87]Quality Attributes Quality Attributes FURPS [GRA87]FURPS [GRA87]

FunctionalityFunctionalityFunctionalityFunctionalityAssessed by evaluating feature set and capabilities of the Assessed by evaluating feature set and capabilities of the program and generality of the functions that are deliveredprogram and generality of the functions that are delivered

UsabilityUsabilityAssessed by considering Assessed by considering human factorshuman factors, overall aesthetics, overall aesthetics

R li bilitR li bilitReliabilityReliabilityPerformancePerformanceS t bilitS t bilitSupportabilitySupportability

MaintainabilityMaintainabilityCompatibility ease of configuration ease of installation etcCompatibility ease of configuration ease of installation etc


Compatibility, ease of configuration, ease of installation, etcCompatibility, ease of configuration, ease of installation, etc

Fundamental SW Design ConceptsFundamental SW Design ConceptsAbstractionAbstraction

data, proceduredata, procedureppPatternsPatterns

“conveys “conveys the essence” of a proven design solutionthe essence” of a proven design solutionModularityModularityModularityModularity

compartmentalization of data and functioncompartmentalization of data and functionHidingHiding

controlled interfacescontrolled interfacescontrolled interfacescontrolled interfacesFunctional independenceFunctional independence

singlesingle--minded function minded function (cohesion) (cohesion) and and low couplinglow couplingR fiR fiRefinementRefinement

elaboration of detail for all abstractionselaboration of detail for all abstractionsRefactoringRefactoring


a reorganization technique that simplifies the designa reorganization technique that simplifies the design

Data AbstractionData Abstractiondoordoor

manufacturermanufacturermodel numbermodel numbertypetypeswing directionswing directionswing directionswing directioninsertsinsertslightslights

typetypenumbernumbernumbernumber

weightweightopening mechanismopening mechanism

implemented as a data structure


Procedural AbstractionProcedural AbstractionProcedural AbstractionProcedural Abstraction

openopenpp

details of enter details of enter algorithmalgorithmalgorithmalgorithm

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


Design PatternsDesign PatternsDesign PatternsDesign PatternsThe best designers in any field have an The best designers in any field have an ability ability to see to see

patterns that characterize a problem patterns that characterize a problem p pp ppatterns that can be combined to create a solutionpatterns that can be combined to create a solution

A design pattern may also consider a set of design forces. A design pattern may also consider a set of design forces. D i fD i f d ibd ib f ti l i tf ti l i t ( f( fDesign forcesDesign forces describe describe nonnon--functional requirements functional requirements (e.g., ease of (e.g., ease of maintainability, portability) associated the software for which the pattern is to maintainability, portability) associated the software for which the pattern is to be applied. be applied.

ThTh tt h t i titt h t i ti ( l ibiliti d ll b ti )( l ibiliti d ll b ti )The The pattern characteristicspattern characteristics (classes, responsibilities, and collaborations) (classes, responsibilities, and collaborations) indicate the attributes of the design that may be indicate the attributes of the design that may be adjustedadjusted to enable the to enable the pattern to accommodate a variety of problems.pattern to accommodate a variety of problems.Levels of abstractionLevels of abstraction

Architectural patternsArchitectural patternsDesign patternsDesign patterns


Design patternsDesign patternsIdioms (coding patterns)Idioms (coding patterns)

Design Patterns TemplateDesign Patterns Templateg pg pPattern name Pattern name

describes the essence of the pattern in a short but expressive name describes the essence of the pattern in a short but expressive name IntentIntent

describes the pattern and what it doesdescribes the pattern and what it doesMotivationMotivation

id l f th blid l f th blprovides an example of the problem provides an example of the problem ApplicabilityApplicability

notes specific design situations in which the pattern is applicablenotes specific design situations in which the pattern is applicableStr ct reStr ct reStructureStructure

describes the classes that are required to implement the patterndescribes the classes that are required to implement the patternParticipantsParticipants

describes the responsibilities of the classes that are required to implementdescribes the responsibilities of the classes that are required to implementdescribes the responsibilities of the classes that are required to implement describes the responsibilities of the classes that are required to implement the patternthe pattern

CollaborationsCollaborationsdescribes how the participants collaborate to carry out their responsibilitiesdescribes how the participants collaborate to carry out their responsibilities


describes how the participants collaborate to carry out their responsibilitiesdescribes how the participants collaborate to carry out their responsibilitiesRelated patternsRelated patterns——crosscross--references related design patternsreferences related design patterns

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


Modularity: TradeModularity: Trade--offsoffsModularity: 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?

cost ofcost of

module development cost module development cost

cost ofcost ofsoftwaresoftware

modulemoduleintegrationintegrationgg

costcost

optimal numberoptimal numberof modulesof modules number of modulesnumber of modules


Information HidingInformation Hidinggg

modulemodulemodulemodulecontrolledcontrolledinterfaceinterface

• algorithm• algorithm

• data structure• data structure

• details of external interface• details of external interface

• resource allocation policy• resource allocation policy

lili "secret""secret"clientsclients

a specific design decisiona specific design decision


Wh I f ti Hidi ?Wh I f ti Hidi ?Why Information Hiding?Why Information Hiding?ReducesReduces the likelihood of “the likelihood of “side effectsside effects””Reduces Reduces the likelihood of the likelihood of side effectsside effectslimits the limits the global impact global impact of local design decisionsof local design decisionsE h iE h i i ti th hi ti th h t ll dt ll dEmphasizes Emphasizes communication through communication through controlled controlled interfacesinterfacesDiscourages Discourages the use of global datathe use of global dataLeads Leads to encapsulationto encapsulation——an attribute of high quality an attribute of high quality pp g q yg q ydesigndesignResultsResults in higher quality softwarein higher quality software


Results Results in higher quality softwarein higher quality software

Stepwise RefinementStepwise RefinementStepwise RefinementStepwise Refinementopen

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

open door;

walk through;

repeat until door opensturn knob clockwise;if knob doesn't turn, theng ;

close door.if knob doesn t turn, then

take key out;find correct key;insert in lock;

endifll/ h dpull/push door

move out of way;end repeat


RefactoringRefactoringRefactoringRefactoringFowler [FOW99] defines refactoring in the following manner:

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

When software is refactored, the existing design is examined for

d dredundancyunused design elementsinefficient or unnecessary algorithmspoorly constructed or inappropriate data structurespoorly constructed or inappropriate data structuresor any other design failure that can be corrected to yield a better design.


Functional IndependenceFunctional IndependenceFunctional IndependenceFunctional Independence

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


The Design ModelThe Design Modelhigh

a na ly sis mode l

class diagrams analysis packages CRC models collaborat ion diagrams

use-cases - t ext use-case diagrams act ivit y diagrams

dat a f low diagrams

class diagrams analysis packages CRC models

Requirement s: const raint s

int eroperabilit ysw im lane diagramscollaborat ion diagrams dat a f low diagrams

cont rol- f low diagrams processing narrat ives

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

st at e diagrams sequence diagrams

st at e diagrams sequence diagrams

collaborat ion diagrams t arget s and conf igurat ion

sequence diagrams

design class realizat ions subsyst ems collaborat ion diagrams component diagrams

design classes design class realizat ions subsyst ems

t echnical int erf ace design

ref inement s t o:

act ivit y diagrams sequence diagrams

ref inement s t o:

subsyst emscollaborat ion diagrams component diagrams design classes act ivit y diagrams sequence diagrams

de sign mode l

Navigat ion design GUI design

lowdesign class realizat ions subsyst ems collaborat ion diagrams

ref inement s t o:

deployment diagrams

component diagramsdesign classes act ivit y diagrams sequence diagrams

sequence diagrams


process dimension

archit ect ure element s

int erface element s

component -level element s

deployment -level element s

Design Model ElementsDesign Model ElementsData elementsData elements

a model of data and/or information that is represented at a high a model of data and/or information that is represented at a high level of abstraction (the customer/user’s view of data)level of abstraction (the customer/user’s view of data)( )( )Refined into more implementationRefined into more implementation--specific representationsspecific representations

Architectural elementsArchitectural elementsApplication domainApplication domainApplication domainApplication domainAnalysis classes, their relationships, collaborations and behaviors Analysis classes, their relationships, collaborations and behaviors are transformed into design realizationsare transformed into design realizationsPatterns and “styles” (Chapter 10)Patterns and “styles” (Chapter 10)Patterns and styles (Chapter 10)Patterns and styles (Chapter 10)

Interface elementsInterface elementsthe user interface (UI) the user interface (UI) external interfaces to other systems devices networks or otherexternal interfaces to other systems devices networks or otherexternal interfaces to other systems, devices, networks or other external interfaces to other systems, devices, networks or other producers or consumers of informationproducers or consumers of informationinternal interfaces between various design componentsinternal interfaces between various design components

Component elementsComponent elements


Component elementsComponent elementsDeployment elementsDeployment elements

Interface ElementsInterface Elements

WirelessPDA

MobilePhone

Cont rolPanel

LCDdisplay LEDindicat orsLEDindicat orskeyPadCharact erist ics speaker wirelessInt erf ace

readKeySt roke() decodeKey ()

KeyPad

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

KeyPad< < int erface> >

realization


KeyPad

readKeyst roke() decodeKey()

Component ElementsComponent ElementsComponent ElementsComponent Elements

- Local data structures

- Procedural algorithmsalgorithms

SensorManagementSensor


Deployment ElementsDeployment ElementsCont rol Panel CPI serv er

Security homeownerAccess

Personal comput er

externalAccess

Security Surveillance


homeManagement communication

Design PrinciplesDesign PrinciplesThe design process should not suffer from ‘tunnel vision.’ The design process should not suffer from ‘tunnel vision.’ The design should beThe design should be traceabletraceable to the analysis modelto the analysis modelThe design should be The design should be traceabletraceable to the analysis model. to the analysis model. The The design should exhibit design should exhibit uniformityuniformity and integration. and integration. The design should be structured to accommodateThe design should be structured to accommodate changechangeThe design should be structured to accommodate The design should be structured to accommodate changechange. . The design should be structured to degrade gently, even The design should be structured to degrade gently, even when aberrant data, when aberrant data, events are events are encountered. encountered. Design is not coding, coding is not design. Design is not coding, coding is not design. The design should be assessed for quality as it is being The design should be assessed for quality as it is being created not after the factcreated not after the factcreated, not after the fact. created, not after the fact. The design should be reviewed to minimize conceptual The design should be reviewed to minimize conceptual (semantic) errors.(semantic) errors.


(semantic) errors.(semantic) errors.From Davis [DAV95]

OO Design ConceptsOO Design ConceptsOO Design ConceptsOO Design ConceptsDesign classesDesign classes

Entity classesEntity classesBoundary classesBoundary classesController classesController classesController classesController classes

InheritanceInheritance——all responsibilities of a superclass is all responsibilities of a superclass is immediately inherited by all subclassesimmediately inherited by all subclassesimmediately inherited by all subclassesimmediately inherited by all subclassesMessagesMessages——stimulate some behavior to occur in the stimulate some behavior to occur in the receiving objectreceiving objectg jg jPolymorphismPolymorphism——a characteristic that greatly reduces a characteristic that greatly reduces the effort required to extend the designthe effort required to extend the design


InheritanceInheritanceInheritanceInheritance

Design options:Design options:g pg pThe class can be designed and built from scratch. That is, The class can be designed and built from scratch. That is, inheritance is not used.inheritance is not used.The class hierarchy can be searched to determine if a classThe class hierarchy can be searched to determine if a classThe class hierarchy can be searched to determine if a class The class hierarchy can be searched to determine if a class higher in the hierarchy (a superclass)contains most of the higher in the hierarchy (a superclass)contains most of the required attributes and operations. The new class inherits from required attributes and operations. The new class inherits from the superclass and additions may then be added, as required.the superclass and additions may then be added, as required.the superclass and additions may then be added, as required.the superclass and additions may then be added, as required.The class hierarchy can be restructured so that the required The class hierarchy can be restructured so that the required attributes and operations can be inherited by the new class.attributes and operations can be inherited by the new class.Characteristics of an existing class can be overridden andCharacteristics of an existing class can be overridden andCharacteristics of an existing class can be overridden and Characteristics of an existing class can be overridden and different versions of attributes or operations are implemented for different versions of attributes or operations are implemented for the new class.the new class.


MessagesMessagesgg

:SenderObject

:ReceiverObjectmessage (<parameters>)


PolymorphismPolymorphismPolymorphismPolymorphismcase of graphtype:case of graphtype:

Conventional approach …Conventional approach …

if graphtype = linegraph then DrawLineGraph (data);if graphtype = linegraph then DrawLineGraph (data);if graphtype = piechart then DrawPieChart (data);if graphtype = piechart then DrawPieChart (data);if graphtype = histogram then DrawHisto (data);if graphtype = histogram then DrawHisto (data);if graphtype = kiviat then DrawKiviat (data);if graphtype = kiviat then DrawKiviat (data);

end case;end case;

All of the graphs become subclasses of a general class called graphAll of the graphs become subclasses of a general class called graphAll of the graphs become subclasses of a general class called graph. All of the graphs become subclasses of a general class called graph. Using a concept called overloading [TAY90], each subclass defines an Using a concept called overloading [TAY90], each subclass defines an operation called operation called drawdraw. An object can send a . An object can send a drawdraw message to any one message to any one of the objects instantiated from any one of the subclasses. The object of the objects instantiated from any one of the subclasses. The object j y jj y jreceiving the message will invoke its own receiving the message will invoke its own drawdraw operation to create the operation to create the appropriate graph. appropriate graph.

graphtype drawgraphtype draw


graphtype drawgraphtype draw

Design ClassesDesign ClassesDesign ClassesDesign ClassesAnalysis classes are refined during design to become Analysis classes are refined during design to become entity classesentity classesB d lB d l d l d d i d i t t th i t fd l d d i d i t t th i t fBoundary classesBoundary classes are developed during design to create the interface are developed during design to create the interface (e.g., interactive screen or printed reports) that the user sees and (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used. interacts with as the software is used.

B d l d i d ith th ibilit f i thB d l d i d ith th ibilit f i thBoundary classes are designed with the responsibility of managing the way Boundary classes are designed with the responsibility of managing the way entity objects are represented to users. entity objects are represented to users.

Controller classeController classess are designed to manage are designed to manage th ti d t f tit bj tth ti d t f tit bj tthe creation or update of entity objects; the creation or update of entity objects; the instantiation of boundary objects as they obtain information from entity the instantiation of boundary objects as they obtain information from entity objects; objects; complex communication between sets of objects;complex communication between sets of objects;complex communication between sets of objects; complex communication between sets of objects; validation of data communicated between objects or between the user and validation of data communicated between objects or between the user and the application.the application.


Chapter 9Chapter 9 Design Engineering - KAISTpswlab.kaist.ac.kr/courses/cs350-08/ch9.pdf ·...

Documents

Transcript of Chapter 9Chapter 9 Design Engineering - KAISTpswlab.kaist.ac.kr/courses/cs350-08/ch9.pdf ·...