software engineering: a practitioner’s approach, 6/e

8/14/2019 SoftwareEngineering:APractitionersApproach,6/e

1/34

These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005

Software Engineering: A Practitioners Approach, 6/eSoftware Engineering: A Practitioners Approach, 6/e

Chapter 9Chapter 9

Design EngineeringDesign Engineering

copyright 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use Only

May be reproduced ONLY for student use at the university level

when used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.


2/34


Design EngineeringDesign Engineering

Creativity rules - coming together ofCreativity rules - coming together ofcustomer requirements, businesscustomer requirements, businessneeds, technical considerationsneeds, technical considerations

Design Specs: representation of S/W,Design Specs: representation of S/W,with details about S/W datawith details about S/W datastructures, architecture, interfaces,structures, architecture, interfaces,components and deploymentcomponents and deployment


3/34


Analysis Model => Design ModelAnalysis Model => Design Model

Analysis Model

use-cases - text

use-case diagramsactivity diagrams

swim lane diagrams

data flow diagrams

control-flow diagramsprocessing narratives

flow-oriented

elements

behavioralelements

class-based

elements

scenario-based

elements

class diagramsanalysis packages

CRC modelscollaboration diagrams

state diagrams

sequence diagramsData/ Class Design

Architectural Design

Interface Design

Component-

Level Design

Design Model


4/34


Generic Task SetGeneric Task Set

Using the analysis model decide on the architectural styleUsing the analysis model decide on the architectural styleappropriate for the softwareappropriate for the software

Partition the analysis model into design subsystems andPartition the analysis model into design subsystems and

allocate these subsystem within the architecture:allocate these subsystem within the architecture: Ensure that each subsystem is functionally cohesiveEnsure that each subsystem is functionally cohesive

Design subsystem interfacesDesign subsystem interfaces

Allocate analysis classes or functions to each subsystemAllocate analysis classes or functions to each subsystem


5/34


Generic Task SetGeneric Task Set

Create a set of design classes or components:Create a set of design classes or components: Translate each analysis class description into a design classTranslate each analysis class description into a design class

Check each design class against quality criteriaCheck each design class against quality criteria

Consider inheritance issuesConsider inheritance issues

Define methods and messages for each design classDefine methods and messages for each design class

Evaluate and select design patterns for each design class or a subsystemEvaluate and select design patterns for each design class or a subsystem Review the design classes and revise if neededReview the design classes and revise if needed

Design interfaces to external systems or devicesDesign interfaces to external systems or devices


6/34


Generic Task SetGeneric Task Set Design the user interface:Design the user interface:

Review results of task analysisReview results of task analysis Specify action sequences based on user scenariosSpecify action sequences based on user scenarios

Create the behavioural model of the interfaceCreate the behavioural model of the interface

Define interface objects and control mechanismsDefine interface objects and control mechanisms

Review the interface design and revise, if neededReview the interface design and revise, if needed

Conduct component-level design:Conduct component-level design:

Specify all algorithms at a relatively low level of abstractionSpecify all algorithms at a relatively low level of abstraction

Refine the interface of each componentRefine the interface of each component

Define component-level data structuresDefine component-level data structures

Review each component and correct any errors foundReview each component and correct any errors found

Develop an operation modelDevelop an operation model


7/34


Design and QualityDesign and Quality

The design must implement all of the explicitThe design must implement all of the explicitrequirementsrequirements contained in the analysis model, andcontained in the analysis model, andit must accommodate all of the implicitit must accommodate all of the implicitrequirements desired by the customer.requirements desired by the customer.

The design must be a readable, understandableThe design must be a readable, understandable

guideguide for those who generate code and for thosefor those who generate code and for thosewho test and subsequently support the software.who test and subsequently support the software.

The design should provide a complete picture ofThe design should provide a complete picture ofthe softwarethe software, addressing the data, functional, and, addressing the data, functional, and

behavioral domains from an implementationbehavioral domains from an implementationperspective.perspective.


8/34


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

has been created using recognizable architectural styles or patterns,has been created using recognizable architectural styles or patterns,

is composed of components that exhibit good design characteristics andis composed of components that exhibit good design characteristics and can be implementedcan be implemented For smaller systems, design can sometimes be developed linearly.For smaller systems, design can sometimes be developed linearly.

A design should be modularA design should be modular; that is, the software should be logically partitioned into; that is, the software should be logically partitioned intoelements or subsystemselements or subsystems

A design should contain distinct representationsA design should contain distinct representations of data, architecture, interfaces, andof data, architecture, interfaces, andcomponents.components.

A design should lead to data structures that are appropriateA design should lead to data structures that are appropriate for the classes to befor the classes to beimplemented and are drawn from recognizable data patterns.implemented and are drawn from recognizable data patterns.

A design should lead to components that exhibit independent functionalA design should lead to components that exhibit independent functionalcharacteristicscharacteristics..

A design should lead to interfaces that reduce the complexityA design should lead to interfaces that reduce the complexity of connections betweenof connections betweencomponents and with the external environment.components and with the external environment.

A design should be represented using a notation that effectively communicates itsA design should be represented using a notation that effectively communicates itsmeaningmeaning..


9/34


Quality AttributesQuality Attributes

FunctionalityFunctionality - assessed by evaluating the feature set and- assessed by evaluating the feature set and

capabilities of a program, generality of functions delivered,capabilities of a program, generality of functions delivered,security of the overall systemsecurity of the overall system

UsabilityUsability - assessed by evaluating human factors- assessed by evaluating human factors(aesthetics, consistency, documentation)(aesthetics, consistency, documentation)

ReliabilityReliability - evaluated by measuring MTTF failures, ability- evaluated by measuring MTTF failures, abilityto recover from failure.to recover from failure.

PerformancePerformance - evaluated by measuring processing speed,- evaluated by measuring processing speed,response time, resource consumption, efficiency, etc.response time, resource consumption, efficiency, etc.

SupportabilitySupportability - extensibility, adaptability, serviceability,- extensibility, adaptability, serviceability,testability, compatibility, configurabilitytestability, compatibility, configurability


10/34

These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1

Fundamental ConceptsFundamental Concepts AbstractionAbstraction data, procedure, control data, procedure, control ArchitectureArchitecture the overall structure of the software the overall structure of the software PatternsPatterns conveys the essence of a proven design conveys the essence of a proven design

solutionsolution ModularityModularity partition of data and functionpartition of data and function

HidingHiding controlled interfaces controlled interfaces Functional independenceFunctional independence single-minded function single-minded function

and low couplingand low coupling RefinementRefinement elaboration of detail for all abstractions elaboration of detail for all abstractions RefactoringRefactoring a reorganization technique that a reorganization technique that

simplifies the designsimplifies the design


11/34


Data AbstractionData Abstraction

doordoor

implemented as a data structure

manufacturermanufacturermodel numbermodel numbertypetypeswing directionswing directioninsertsinsertslightslights

typetypenumbernumber

weightweightopening mechanismopening mechanism


12/34


Procedural AbstractionProcedural Abstraction

openopen

implemented with a "knowledge" of the

object that is associated with enter

details of enterdetails of enteralgorithmalgorithm


13/34


ArchitectureArchitectureThe overall structure of the software and the ways inThe overall structure of the software and the ways inwhich that structure provides conceptual integrity for awhich that structure provides conceptual integrity for asystem. [SHA95a]system. [SHA95a]

Structural properties.Structural properties. This aspect of the architectural design representationThis aspect of the architectural design representationdefines the components of a system (e.g., modules, objects, filters) and thedefines the components of a system (e.g., modules, objects, filters) and themanner in which those components are packaged and interact with onemanner in which those components are packaged and interact with oneanother. For example, objects are packaged to encapsulate both data and theanother. For example, objects are packaged to encapsulate both data and the

processing that manipulates the data and interact via methodsprocessing that manipulates the data and interact via methodsExtra-functional properties.Extra-functional properties. The architectural design description shouldThe architectural design description shouldaddress how the design architecture achieves requirements for performance,address how the design architecture achieves requirements for performance,capacity, reliability, security, adaptability, and other system characteristics.capacity, reliability, security, adaptability, and other system characteristics.Families of related systems.Families of related systems. The architectural design should draw uponThe architectural design should draw uponrepeatable patterns that are commonly encountered in the design of families ofrepeatable patterns that are commonly encountered in the design of families ofsimilar systems. In essence, the design should have the ability to reusesimilar systems. In essence, the design should have the ability to reuse

architectural building blocks.architectural building blocks.


14/34


PatternsPatterns(i.e. named nuggets of insight)(i.e. named nuggets of insight)

Design Pattern TemplateDesign Pattern Template

Pattern namePattern name describes the essence of the pattern in a short but expressive describes the essence of the pattern in a short but expressive

namename

IntentIntent describes the pattern and what it does describes the pattern and what it does

Also-known-asAlso-known-as lists any synonyms for the pattern lists any synonyms for the pattern

MotivationMotivation provides an example of the problem provides an example of the problem

ApplicabilityApplicability notes specific design situations in which the pattern is applicable notes specific design situations in which the pattern is applicable

StructureStructure describes the classes that are required to implement the pattern describes the classes that are required to implement the patternParticipantsParticipants describes the responsibilities of the classes that are required to describes the responsibilities of the classes that are required to

implement the patternimplement the pattern

CollaborationsCollaborations describes how the participants collaborate to carry out their describes how the participants collaborate to carry out their

responsibilitiesresponsibilities

ConsequencesConsequences describes the design forces that affect the pattern and the describes the design forces that affect the pattern and the

potential trade-offs that must be considered when the pattern is implementedpotential trade-offs that must be considered when the pattern is implemented

Related patternsRelated patterns cross-references related design patterns cross-references related design patterns


15/34


ModularModular

DesignDesigneasier to build, easier to change, easier to fix ...


16/34


Modularity: Trade-offsModularity: Trade-offsWhat is the "right" number of modulesWhat 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

modulemoduleintegrationintegrationcostcost

module development costmodule development cost


17/34


Information HidingInformation Hiding

modulemodulecontrolledcontrolledinterfaceinterface

"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


18/34


Why Information Hiding?Why Information Hiding?

reduces the likelihood of side effectsreduces the likelihood of side effects limits the global impact of local designlimits the global impact of local design

decisionsdecisions emphasizes communication throughemphasizes communication through

controlled interfacescontrolled interfaces discourages the use of global datadiscourages the use of global data leads to encapsulationan attribute ofleads to encapsulationan attribute of

high quality designhigh quality design

results in higher quality softwareresults in higher quality software


19/34


Stepwise RefinementStepwise Refinementopen

walk to door;reach for knob;

open door;

walk through;close door.

repeat until door opens

turn knob clockwise;if knob doesn't turn, thentake key out;find correct key;insert in lock;

endifpull/push doormove out of way;

end repeat


20/34


Functional IndependenceFunctional Independence

COHESION - the degree to which amodule performs one and only onefunction.

COUPLING - the degree to which amodule is "connected" to othermodules in the system.


21/34


Sizing Modules: Two ViewsSizing Modules: Two Views

MODULE

What's

inside??How bigis it??


22/34


RefactoringRefactoring

Fowler [FOW99] defines refactoring in the followingmanner: "Refactoring is the process of changing a software system in

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

When software is refactored, the existing design is examinedfor: redundancy unused design elements inefficient or unnecessary algorithms poorly constructed or inappropriate data structures or any other design failure that can be corrected to yield a better

design.


23/34


OO Design ConceptsOO Design Concepts Design classesDesign classes

Entity classesEntity classes Boundary classesBoundary classes Controller classesController classes

InheritanceInheritanceall responsibilities of a superclass isall responsibilities of a superclass is

immediately inherited by all subclassesimmediately inherited by all subclasses

MessagesMessagesstimulate some behavior to occur in the receivingstimulate some behavior to occur in the receivingobjectobject

PolymorphismPolymorphisma characteristic that greatly reduces thea characteristic that greatly reduces the

effort required to extend the designeffort required to extend the design


24/34


Design ClassesDesign Classes Analysis classes are refined during design to becomeAnalysis classes are refined during design to become entityentity

classesclasses

Boundary classesBoundary classesare developed during design to create theare developed during design to create theinterface (e.g., interactive screen or printed reports) that the userinterface (e.g., interactive screen or printed reports) that the usersees and interacts with as the software is used.sees and interacts with as the software is used. Boundary classes are designed with the responsibility of managingBoundary classes are designed with the responsibility of managing

the way entity objects are represented to users.the way entity objects are represented to users.

Controller classeController classessare designed to manageare designed to manage

the creation or update of entity objects;the creation or update of entity objects; the instantiation of boundary objects as they obtain informationthe instantiation of boundary objects as they obtain information

from entity objects;from entity objects; complex communication between sets of objects;complex communication between sets of objects;

validation of data communicated between objects or between thevalidation of data communicated between objects or between theuser and the application.user and the application.


25/34


InheritanceInheritance

Design options:Design options: The 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 class

higher in the hierarchy (a superclass)contains most of thehigher in the hierarchy (a superclass)contains most of therequired attributes and operations. The new class inherits fromrequired attributes and operations. The new class inherits fromthe 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 requiredThe class hierarchy can be restructured so that the requiredattributes 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 anddifferent versions of attributes or operations are implementeddifferent versions of attributes or operations are implemented

for the new class.for the new class.


26/34


MessagesMessages

:SenderObject

:ReceiverObject

message ()


27/34


PolymorphismPolymorphism

case of graphtype:case of graphtype:

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 graph.All of the graphs become subclasses of a general class called graph.Using a concept called overloading [TAY90], each subclass definesUsing a concept called overloading [TAY90], each subclass definesan operation calledan operation called drawdraw. An object can send a. An object can send a drawdrawmessage tomessage toany one of the objects instantiated from any one of the subclasses.any one of the objects instantiated from any one of the subclasses.The object receiving the message will invoke its ownThe object receiving the message will invoke its own drawdrawoperationoperationto create the appropriate graph.to create the appropriate graph.

graphtype drawgraphtype draw

ConventionalConventional approach approach

h i d lTh D i M d l


28/34


The Design ModelThe Design Model

process dimension

architectureelements

interfaceelements

component-levelelements

deployment-levelelements

low

high

class diagramsanalysis packages

CRC models

collaboration diagrams

use-cases - text

use-case diagrams

activity diagrams

swim lane diagrams

collaboration diagrams data flow diagrams

control-flow diagrams

processing narratives

data flow diagrams

control-flow diagrams

processing narratives

state diagrams

sequence diagrams

state diagrams

sequence diagrams

design class realizations

subsystems



subsystems


refinements to:

deployment diagrams

class diagrams

analysis packages

CRC models


component diagramsdesign classes

activity diagrams

sequence diagrams

refinements to:

component diagrams

design classes

activity diagrams

sequence diagrams


subsystems


component diagrams

design classes

activity diagrams

sequence diagrams

analysis model

design model

Requirements:

constraints

interoperability

targets and

configuration

technical interfacedesign

Navigation design

GUI design

D i M d l ElD i M d l El t


29/34


Design Model ElementsDesign Model Elements Data elementsData elements

Data model --> data structuresData model --> data structures

Data model --> database architectureData model --> database architecture

Architectural elementsArchitectural elements Application domainApplication domain Analysis classes, their relationships, collaborations and behaviorsAnalysis classes, their relationships, collaborations and behaviors

are transformed into design realizationsare transformed into design realizations Patterns and styles (Chapter 10)Patterns and styles (Chapter 10)

Interface elementsInterface elements the user interface (UI)the user interface (UI) external interfaces to other systems, devices, networks or otherexternal interfaces to other systems, devices, networks or other

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

Component elementsComponent elements

Deployment elementsDeployment elements

I t f El tI t f El t


30/34


Interface ElementsInterface Elements

ControlPanel

LCDdisplay

LEDindicators

keyPadCharacteristics

speaker

wirelessInterface

readKeyStroke()

decodeKey()

displayStatus()

lightLEDs()

sendControlMsg()

Figure 9 .6 UML interface representation forControlPanel

KeyPad

readKeystroke()

decodeKey()

WirelessPDA

KeyPad

MobilePhone


31/34


Component ElementsComponent Elements

SensorManagementSensor

D l t El tD l t El t


32/34


Deployment ElementsDeployment Elements

Figure 9.8 UML deployment diagram forSafeHome

Personal computer

Security

homeManagement

Surveillance

communication

Control Panel CPI server

Security homeownerAccess

externalAccess


33/34


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

patterns that characterize a problem and corresponding patternspatterns that characterize a problem and corresponding patternsthat 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 designA description of a design pattern may also consider a set of designforces.forces.

Design forcesDesign forces describe non-functional requirements (e.g., ease ofdescribe non-functional requirements (e.g., ease ofmaintainability, portability) associated the software for which themaintainability, portability) associated the software for which thepattern is to be applied.pattern is to be applied.

TheThe pattern characteristicspattern characteristics (classes, responsibilities, and(classes, responsibilities, andcollaborations) indicate the attributes of the design that may becollaborations) indicate the attributes of the design that may be

adjusted to enable the pattern to accommodate a variety ofadjusted to enable the pattern to accommodate a variety ofproblems.problems.


34/34


FrameworksFrameworks

AA frameworkframework is not an architectural pattern, but rather ais not an architectural pattern, but rather askeleton with a collection of plug points (also calledskeleton with a collection of plug points (also calledhookshooks andand slotsslots) that enable it to be adapted to a specific) that enable it to be adapted to a specificproblem domain.problem domain.

Gamma et al note that:Gamma et al note that: Design patterns are more abstract than frameworks.Design patterns are more abstract than frameworks. Design patterns are smaller architectural elements thanDesign patterns are smaller architectural elements than

frameworksframeworks

Design patterns are less specialized than frameworksDesign patterns are less specialized than frameworks

software engineering: a practitioner’s approach, 6/e

Documents