1

Software Engineering: A Practitioner’s Software Engineering: A Practitioner’s Approach, 6/eApproach, 6/e

Chapter 9: 9.4-9.6Chapter 9: 9.4-9.6Design EngineeringDesign Engineering

copyright © 1996, 2001, 2005R.S. Pressman & Associates, Inc.

For University Use OnlyMay 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

The Design ModelThe Design Model

process dimension

architecture elements

interface elements

component-level elements

deployment-level elements

low

high

class diagrams analysis 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 collaboration diagrams

design class realizations subsystems collaboration diagrams

refinements to:

deployment diagrams

class diagrams analysis packages CRC models collaboration diagrams

component diagrams design classes activity diagrams sequence diagrams

refinements to:component diagrams design classes activity diagrams sequence diagrams

design class realizations subsystems collaboration diagrams component diagrams design classes activity diagrams sequence diagrams

analysis model

design model

Requirements: constraints interoperability targets and configuration

technical interface design Navigation design GUI design

3

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 behaviors Analysis 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 other external 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

4

Interface ElementsInterface Elements

ControlPanel

LCDdisplay LEDindicators keyPadCharacteristics speaker wirelessInterface

readKeyStroke() decodeKey() displayStatus() lightLEDs() sendControlMsg()

Figure 9.6 UML interface representation for ControlPanel

KeyPad

readKeystroke() decodeKey()

<<interface>>

WirelessPDA

KeyPad

MobilePhone

5

Component ElementsComponent Elements

SensorManagementSensor

6

Deployment ElementsDeployment Elements

Figure 9.8 UML deployment diagram for SafeHome

Personal computer

Security

homeManagement

Surveillance

communication

Control Panel CPI server

Security homeownerAccess

externalAccess

7

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 A description of a design pattern may also consider a set of design forces. design forces.

Design forcesDesign forces describe non-functional requirements (e.g., ease of describe non-functional requirements (e.g., ease of maintainability, portability) associated the software for which the maintainability, portability) associated the software for which 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 be collaborations) indicate the attributes of the design that may be adjusted to enable the pattern to accommodate a variety of adjusted to enable the pattern to accommodate a variety of problems.problems.

8

FrameworksFrameworks A A framework framework is not an architectural pattern, but is not an architectural pattern, but

rather a skeleton with a collection of “plug rather a skeleton with a collection of “plug points” (also called points” (also called hookshooks and and slotsslots) that enable ) that enable it to be adapted to a specific problem domain. it to be adapted to a specific 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 than Design patterns are smaller architectural elements than

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