software engineering unit 4
DESCRIPTION
MaterialTRANSCRIPT
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 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.