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

Chapter 8
Analysis Modeling
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.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
 Requirements Analysis
 Requirements analysis 
 specifies software’s operational characteristics
 indicates software's interface with other system elements 
 establishes constraints that software must meet
 Requirements analysis allows the software engineer 
(called an analyst or modeler in this role) to:
 elaborate on basic requirements established during earlier 
requirement engineering tasks
 build models that depict user scenarios, functional 
activities, problem classes and their relationships, system 
and class behavior, and the flow of data as it is 
transformed. 
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
 A Bridge
system
description

analysis
model

design
model

ANALYSIS MODEL: a representation of requirements in 
terms of text and diagrams depicting requirements for data, 
function and system behaviour in a way easy to understand 
and review for correctness, completeness and consistency
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
 Rules of Thumb
 The model should focus on requirements that are visible within the 
problem or business domain. The level of abstraction should be 
relatively high (focus on the “WHAT”, not “HOW”). 
 Each element of the analysis model should add to an overall 
understanding of software requirements and provide insight into 
the information domain, function and behavior of the system.
 Delay consideration of infrastructure and other non­functional 
models until design. 
 Minimize coupling throughout the system. 
 Be certain that the analysis model provides value to all 
stakeholders. 
 Keep the model as simple as it can be. 

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
 Domain Analysis
Software domain analysis is the identification, 
analysis, and specification of common requirements 
from a specific application domain, typically for reuse 
on multiple projects within that application domain . . .
[Object­oriented domain analysis is] the identification, 
analysis, and specification of common, reusable 
capabilities within a specific application domain, in 
terms of common objects, classes, subassemblies, and 
frameworks . . .
Donald Firesmith

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
 Domain Analysis
 Define the domain to be investigated.

 Collect a representative sample of applications 
in the domain.

 Analyze each application in the sample.

 Develop an analysis model for the objects. 

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
 Analysis Modeling Approaches
 STRUCTURED ANALYSIS considers data and 
processes transforming the data as separate entities. 
Data objects are modeled defining their attributes and 
relationships. Processes depict transformation of data 
objects as they flow through the system.

 OBJECT­ORIENTED ANALYSIS focuses on the 
definition of classes and the way they collaborate with 
one another to satisfy customer requirements. (UML and 
Unified Process are predominantly object­oriented)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
 Data Modeling
 Examines data objects independently of 
processing

 Focuses attention on the data domain

 Creates a model at the customer’s level of 
abstraction

 Indicates how data objects relate to one 
another
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
 What is a Data Object?
Object —something that is described by a set
of attributes (data items) and that will be 
manipulated within the software (system)
each  instance of an object (e.g., a book) 
can be identified uniquely (e.g., ISBN #) 
each plays a necessary role in the system
i.e., the system could not function without 
access to instances of the object
each is described by attributes that are 
themselves data items

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
 Typical Objects
external entities  (printer, user, sensor)
things  (e.g, reports, displays, signals) 
occurrences or events  (e.g., interrupt, alarm)
roles  (e.g., manager, engineer, salesperson)
organizational units  (e.g., division, team)
places  (e.g., manufacturing floor) 
structures  (e.g., employee record)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
 Data Objects and Attributes
A data object contains a set of attributes that 
act as an aspect, quality, characteristic, or 
descriptor of the object
object: automobile
attributes:
make
model
body type
price
options code

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
 What is a Relationship?
relationship —indicates “connectedness”; 
a "fact" that must be "remembered" 
by the system and cannot or is not computed 
or derived mechanically

 several instances of a relationship can exist
 objects can be related in many different ways

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12
 E­R Diagrams
One common form:
(0, m)
object1 relationship object 2
(1, 1)

attribute
Another common form:

object1 relationship
object 2
(0, m) (1, 1)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13
 Building an ERD

 Level 1—model all data objects (entities) and their 
“connections” to one another
 Level 2—model all entities and relationships
 Level 3—model all entities, relationships, and the 
attributes that provide further depth

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14
 The ERD: An Example
request
Customer places
for service
(1,1) (1,m)
(1,1)
standard generates (1,n) work
task table order
(1,1) (1,1) (1,1)
selected work (1,w) consists
from (1,w) tasks of

(1,i)
materials lists

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15
 Object­Oriented Concepts
 Must be understood to apply class ­ 
based elements of the analysis model

 Key concepts:
 Classes and objects
 Attributes and operations
 Encapsulation and instantiation
 Inheritance

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16
 Classes
• object­oriented thinking begins with the 
definition of a class, often defined as:
–  template
–  generalized description
–  “blueprint” ... describing a collection of 
similar items
• a metaclass (also called a superclass) 
establishes a hierarchy of classes
• once a class of items is defined, a 
specific instance of the class can be 
identified 

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17
 Building a Class
class name

attributes:

operations

attributes:
operations:

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18
 What is a Class?
occurrences roles
things organizational units
places
external entities
structures

class name

attributes:

operations:

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19
 Encapsulation/Hiding
The object encapsulates
both data and the logical
procedures required to
manipulate the data method  method 
# 1 # 2
data

method 
method  # 3
# 6

method  method 
# 5 # 4

Achieves “information hiding”

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20
 Class Hierarchy
PieceOfFurniture (superclass)

Table Chair Desk ”Chable"

subclasses of the

instances of Chair
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21
 Methods
(a.k.a. Operations, Services)
An executable procedure that is 
encapsulated in a class and is designed 
to operate on one or more data attributes 
that are defined as part of the class.
A method is invoked 
via message passing.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22
 Scenario­Based Modeling
“[Use­cases] are simply an aid to defining what exists 
outside the system (actors) and what should be 
performed by the system (use­cases).” Ivar Jacobson
(1) What should we write about?
(2) How much should we write about it?
(3) How detailed should we make our description? 
(4) How should we organize the description? 

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23
 Use­Case

 a scenario that describes a “thread of usage” 
for a system

 actors represent roles people or devices play 
as the system functions

 users can play a number of different roles in a 
given scenario

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24
 Developing a Use­Case
 What are the main tasks or functions that are performed 
by the actor?

 What system information will the the actor acquire, 
produce or change?

 Will the actor have to inform the system about changes 
in the external environment?

 What information does the actor desire from the system?

 Does the actor wish to be informed about unexpected 
changes?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25
 Use­Case Diagram
SafeHome

Access camera
surveillance via the cameras
Internet

Configure SafeHome
system parameters

homeowner

Set alarm

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26
 Activity Diagram
Supplements the use­case by  enter password

providing a diagrammatic 
and user ID

representation of procedural 
flow valid passwords/ ID invalid passwords/ ID

select major function prompt for reentry

ot her f unct ions
may also be
select ed
input t ries remain
select surveillance
no input
t ries remain

t humbnail views select a specif ic camera

select specific
select camera icon
camera - thumbnails

view camera output

in labelled window

prompt for
another view

exit t his f unct ion

see another camera

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 27
 Swimlane Diagrams
Allow the modeler to represent the flow of activities described by the use­case and at the 
same time indicate which actor (if there are multiple actors involved in a specific use­case) 
or analysis class has responsibility for the action described by an activity rectangle
h o m e o wn e r c a m e ra i n t e rf a c e

enter password
and user ID

valid passwo rd s/ ID
invalid
passwo rd s/ ID
select major function

o t h er f u n ct io n s prompt for reentry

may also b e
select ed

in pu t t ries
select surveillance remain

n o in p ut
t ries remain

t h u mb n ail views select a sp ecif ic camera

select specific
select camera icon
camera - thumbnails

generate video
output

view camera output prompt for

in labelled window another view

exit t h is
f u nct io n

see
an o t h er
camera

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 28
 Flow­Oriented Modeling
Represents how data objects are transformed at they 
move through the system
A data flow diagram (DFD) is the diagrammatic form 
that is used
Considered by many to be an ‘old school’ approach, flow­
oriented modeling continues to provide a view of the 
system that is unique—it should be used to supplement 
other analysis model elements

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 29
 The Flow Model
Every computer­based system is an 
information transform ....

computer
input based output
system

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 30
 Flow Modeling Notation

external entity

process

data flow

data store

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 31
 External Entity

A producer or consumer of data

Examples: a person, a device, a sensor
Another example: computer­based
system
Data must always originate somewhere
and must always be sent to something

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 32
 Process
A data transformer (changes input
to output)

Examples: compute taxes, determine area,
format report, display graph 
Data must always be processed in some 
way to achieve system function

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 33
 Data Flow

Data flows through a system, beginning

as input and be transformed into output.
base
compute
area
triangle
height area

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 34
 Data Stores
Data is often stored for later use.

sensor #
sensor #, type,
look-up location, age
sensor
report required data
type,
location, age
sensor number

sensor data

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 35
 Data Flow Diagramming:
Guidelines
 All icons must be labeled with meaningful 
names
 The DFD evolves through a number of 
levels of detail
 Always begin with a context level diagram 
(also called level 0)
 Always show external entities at level 0
 Always label data flow arrows
 Do not represent procedural logic

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 36
 Constructing a DFD — I

 Review the data model to isolate data objects 
and use a grammatical parse to determine 
“operations”
 Determine external entities (producers and 
consumers of data)
 Create a level 0 DFD

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 37
 Level 0 DFD Example

processing
user request requested
video
digital signal
video monitor
processor
video
source NTSC
video signal

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 38
 Constructing a DFD — II

 Write a narrative describing the transform

 Parse to determine next level transforms

 “Balance” the flow to maintain data flow 
continuity

 Develop a level 1 DFD

 Use a 1:5 (approx.) expansion ratio
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 39
 The Data Flow Hierarchy

a b
x P y level 0

a c p2
p1
f

d p4 5 b
p3 e g
level 1

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 40
 Flow Modeling Notes
 Each bubble is refined until it does just one thing

 The expansion ratio decreases as the number of 
levels increase

 Most systems require between 3 and 7 levels for 
an adequate flow model

 A single data flow item (arrow) may be expanded 
as levels increase (data dictionary provides 
information)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 41
 Process Specification (PSPEC)
bubble

PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 42
 DFDs: A Look Ahead

analysis model
Maps into
design model

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 43
 Control Flow Diagrams
 Represents “events” and the processes that manage 
events
 An “event” is a Boolean condition that can be 
ascertained by:
 listing all sensors that are "read" by the software.
 listing all interrupt conditions.
 listing all "switches" that are actuated by an operator.
 listing all data conditions.
 recalling the noun/verb parse that was applied to the processing 
narrative, review all "control items" as possible CSPEC 
inputs/outputs.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 44
 The Control 
Model
the control flow diagram is "superimposed" on the DFD 
and shows events that control the processes noted in 
the DFD
control flows—events and control items—are noted by 
dashed arrows
a vertical bar implies an input to or output from a control 
spec (CSPEC) — a separate specification that 
describes how control is handled
a dashed arrow entering a vertical bar is an input to the 
CSPEC

a dashed arrow leaving a process implies a data 
condition

a dashed arrow entering a process implies a control 
input read directly by the process
control flows do not physically activate/deactivate the 
processes—this is done via the CSPEC
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 45
 Control Flow Diagram
copies done
beeper on/off full
read 
operator 
input manage 
problem 
start copying light

empty
reload  create 
process user 
displays

perform 
problem 
diagnosis

display panel enabled

jammed

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 46
 Control Specification (CSPEC)
The CSPEC can be:
state diagram 
(sequential spec)

state transition table
combinatorial spec
decision tables 

activation tables

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 47
 Guidelines for Building a CSPEC
list all sensors that are "read" by the software
list all interrupt conditions
list all "switches" that are actuated by the operator
list all data conditions

recalling the noun­verb parse that was applied to the
software statement of scope, review all "control items"
as possible CSPEC inputs/outputs
describe the behavior of a system by identifying its 
states; identify how each state is reach and defines 
the transitions between states

focus on possible omissions ... a very common error in 
specifying control, e.g., ask: "Is there any other way I 
can get to this state or exit from it?"

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 48
 Class­Based Modeling
 Identify analysis classes by examining the 
problem statement

 Use a “grammatical parse” to isolate potential 
classes

 Identify the attributes of each class

 Identify operations that manipulate the attributes

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 49
 Analysis Classes
 External entities (e.g., other systems, devices, people) that produce or consume 
information to be used by a computer­based system.

 Things (e.g, reports, displays, letters, signals) that are part of the information domain 
for the problem.

 Occurrences or events (e.g., a property transfer or the completion of a series of robot 
movements) that occur within the context of system operation.

 Roles (e.g., manager, engineer, salesperson) played by people who interact with the 
system.

 Organizational units (e.g., division, group, team) that are relevant to an application.

 Places (e.g., manufacturing floor or loading dock) that establish the context of the 
problem and the overall function of the system.

 Structures (e.g., sensors, four­wheeled vehicles, or computers) that define a class of 
objects or related classes of objects.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 50
 Selecting Classes—Criteria

Retained information
Needed services
Multiple attributes
Common attributes
Common operations
Essential requirements

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 51
 Class Diagram
Class name
System
systemID

attributes
verificationPhoneNumber
systemStatus
delayTime
telephoneNumber
masterPassword
temporaryPassword
numberTries

program()
display()

operations
reset()
query()
modify()
call()

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 52
 Class Diagram
FloorPlan

type
name
outsideDimensions

determineType ()
positionFloorplan
scale( )
change color( )

is placed within

is part of

Camera Wall

type type
ID wallDimensions
location
fieldV iew
panA ngle
ZoomSetting
determineType ()
computeDimensions ( )
determineType ()
translateLocation ()
displayID()
displayV iew()
displayZoom()
is used to build is used to build

is used to build

WallSegment Window Door

type type type

startCoordinates startCoordinates startCoordinates
stopCoordinates stopCoordinates stopCoordinates
nextWallSement nextWindow nextDoor

determineType ( ) determineType ( ) determineType ()

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
draw( ) draw( ) draw()

are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 53
 CRC Modeling
(Class_Responsibility­Collaborator)

 Analysis classes have “responsibilities”
 Responsibilities are the attributes and operations encapsulated by 
the class

 Analysis classes collaborate with one another
  Collaborators are those classes that are required to provide a 
class with the information needed to complete a responsibility. 
 In general, a collaboration implies either a request for 
information or a request for some action.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 54
 CRC 
Modeling
Class:
Class:
Description:
Class:
Description:
Class:FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows Wall
shows position of video cameras Camera

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 55
 Class Types
 Entity classes, also called model or business classes, are extracted 
directly from the statement of the problem (e.g., FloorPlan and 
Sensor). 

 Boundary classes are used to create the interface (e.g., interactive 
screen or printed reports) that the user sees and interacts with as 
the software is used. 

 Controller classes manage a “unit of work” [UML03] from start to 
finish. That is, controller classes can be designed to manage 
 the creation or update of entity objects; 
 the instantiation of boundary objects as they obtain information from 
entity objects; 
 complex communication between sets of objects; 
 validation of data communicated between objects or between the user 
and the application. 

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 56
 Responsibilities
(Attributes and methods relevant to the class)

 System intelligence should be distributed across classes 
to best address the needs of the problem
 Each responsibility should be stated as generally as 
possible
 Information and the behavior related to it should reside 
within the same class
 Information about one thing should be localized with a 
single class, not distributed across multiple classes. 
 Responsibilities should be shared among related classes, 
when appropriate. 

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 57
 Collaborations
 Classes fulfill their responsibilities in one of two ways:
  A class can use its own operations to manipulate its own 
attributes, thereby fulfilling a particular responsibility, or 
  a class can collaborate with other classes.
 Collaborations identify relationships between classes
 Collaborations are identified by determining whether a class 
can fulfill each responsibility itself
 Three different generic relationships between classes [WIR90]: 
  the is­part­of relationship
  the has­knowledge­of relationship
  the depends­upon relationship

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 58
 Composite Aggregate Class
Player

PlayerHead PlayerBody PlayerArms PlayerLegs

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 59
 Reviewing the CRC Model
 All participants in the review (of the CRC model) are given a subset of the 
CRC model index cards. 
 Cards that collaborate should be separated (i.e., no reviewer should have two cards 
that collaborate).
 All use­case scenarios (and corresponding use­case diagrams) should be 
organized into categories.
 The review leader reads the use­case deliberately. 
 As the review leader comes to a named object, she passes a token to the person 
holding the corresponding class index card.
 When the token is passed, the holder of the class card is asked to describe the 
responsibilities noted on the card.
  The group determines whether one (or more) of the responsibilities satisfies the 
use­case requirement.
 If the responsibilities and collaborations noted on the index cards cannot 
accommodate the use­case, modifications are made to the cards.
  This may include the definition of new classes (and corresponding CRC index 
cards) or the specification of new or revised responsibilities or collaborations on 
existing cards.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 60
 Associations and Dependencies
 Two analysis classes are often related to one another in 
some fashion
  In UML these relationships are called associations
 Associations can be refined by indicating multiplicity (the term 
cardinality is used in data modeling
 In many instances, a client­server relationship exists 
between two analysis classes. 
 In such cases, a client­class depends on the server­class in some 
way and a dependency relationship is established

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 61
 Multiplicity
Wall

1 1 1

is used to build is used to build

1..* 0..* is used to build 0..*

WallSegment Window Door

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 62
 Dependencies

DisplayWindow Camera

<<access>>

{password}

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 63
 Analysis Packages
 Various elements of the analysis model (e.g., use­cases, 
analysis classes) are categorized in a manner that 
packages them as a grouping
 The plus sign preceding the analysis class name in each 
package indicates that the classes have public visibility 
and are therefore accessible from other packages.
 Other symbols can precede an element within a package. 
A minus sign indicates that an element is hidden from 
all other packages and a # symbol indicates that an 
element is accessible only to packages contained within a 
given package.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 64
 Analysis Packages
package name

Environment
+Tree
+Landscape
+Road
+Wall
+Bridge
+Building RulesOfTheGame
+VisualEffect
+Scene +RulesOfMovement
+ConstraintsOnAction

Characters

+Player
+Protagonist
+Antagonist
+SupportingRole

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 65
 Behavioral Modeling
 The behavioral model indicates how software will 
respond to external events or stimuli. To create the 
model, the analyst must perform the following 
steps:
 Evaluate all use­cases to fully understand the sequence of 
interaction within the system.
 Identify events that drive the interaction sequence and 
understand how these events relate to specific objects.
 Create a sequence for each use­case.
 Build a state diagram for the system.
 Review the behavioral model to verify accuracy and 
consistency.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 66
 State Representations
 In the context of behavioral modeling, two different 
characterizations of states must be considered: 
 the state of each class as the system performs its function and
 the state of the system as observed from the outside as the 
system performs its function
 The state of a class takes on both passive and active 
characteristics [CHA93]. 
 A passive state is simply the current status of all of an object’s 
attributes.
 The active state of an object indicates the current status of the 
object as it undergoes a continuing transformation or processing. 

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 67
State Diagram for the ControlPanel Class
t imer < lockedTime

t imer > lockedTime locked

password = incorrect
& numberOfTries < maxTries

reading comparing numberOfTries > maxTries

key hit
password
ent ered do: validatePassword
password = correct

select ing

act ivat ion successful

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 68
 The States of a System
 state—a set of observables that 
characterizes the behavior of a system at 
a given time
 state transition—the movement from one 
state to another
 event—an occurrence that causes the 
system to exhibit some predictable form 
of behavior
 action—process that occurs as a 
consequence of making a transition

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 69
 Behavioral Modeling

 Make a list of the different states of a system 
(How does the system behave?)
 Indicate how the system makes a transition 
from one state to another (How does the 
system change state?)
 indicate event
 indicate action
 Draw a state diagram or a sequence 
diagram

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 70
 Sequence Diagram
homeowner cont rol panel syst em sensors
sensors

syst em reading
A
ready
password ent ered

request lookup
comparing

result

password = correct
numberOfTries > maxTries request act ivat ion
locked

t imer > lockedTime

A

select ing

act ivat ion successful act ivat ion successful

Figure 8.27 Sequence diagram (partial) for SafeHome security function

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 71
 Writing the Software Specification
Everyone knew exactly 
what had to be done 
until someone wrote it 
down!

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 72
 Specification Guidelines
use a layered format that provides increasing detail 
as the "layers" deepen 
 
use consistent graphical notation and apply textual 
terms consistently (stay away from aliases) 
 
be sure to define all acronyms 
 
be sure to include a table of contents; ideally, 
include an index and/or a glossary 
 
write in a simple, unambiguous style (see "editing 
suggestions" on the following pages) 
 
always put yourself in the reader's position, "Would 
I be able to understand this if I wasn't intimately 
familiar with the system?"

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 73
 Specification Guidelines
Be on the lookout for persuasive connectors, ask why? 
     keys: certainly, therefore, clearly, obviously, it follows that ... 
 
Watch out for vague terms 
     keys: some, sometimes, often, usually,ordinarily, most, mostly ...  
 
When lists are given, but not completed, be sure all items are understood 
     keys: etc., and so forth, and so on, such as 
 
Be sure stated ranges don't contain unstated assumptions 
     e.g., Valid codes range from 10 to 100. Integer? Real? Hex? 
 
Beware of vague verbs such as  handled, rejected, processed, ... 
 
Beware "passive voice" statements  
     e.g., The parameters are initialized. By what? 
 
Beware "dangling" pronouns 
     e.g., The I/O module communicated with the data validation module and 
its contol flag is set. Whose control flag? 

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and 
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 74
 Specification Guidelines
When a term is explicitly defined in one place, try 
substituting the definition forother occurrences of the term 
 
When a structure is described in words, draw a picture 
 
When a structure is described with a picture, try to redraw 
the picture to emphasize different elements of the structure 
 
When symbolic equations are used, try expressing their 
meaning in words 
 
When a calculation is specified, work at least two 
examples  
 
Look for statements that imply certainty, then ask for proof  
       keys; always, every, all, none, never 
 
Search behind certainty statements—be sure restrictions 
or limitations are realistic 

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