Supplementary Slides for
Software Engineering:
A Practitioner's Approach, 5/e
copyright © 1996, 2001
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.
This presentation, slides, or hardcopy may NOT be used for
short courses, industry seminars, or consulting purposes.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
1
Chapter 12
Analysis Modeling
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
2
Analysis Modeling
 Uses a combination of text and
diagrammatic forms to depict requirements
for data, function, and behavior that is easy
to understand and to review
 Commonly used method:
1. Structured Analysis
2. Object Oriented Analysis
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
3
Elements of Analysis Model
 Primary objectives of analysis model:
1. Describe what customer requires
2. Establish a basis for the creation of a software design
3. Define set of requirements that can be validated
 Structure:
DFD
ERD
DD
State
Transition
Diagram
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
4
Structure Cont’d…
Data Dictionary
 A repository that contains description of all data objects
consumed or produced by the system
Entity Relationship Diagram
 Depicts relationship between data objects
Data Flow Diagram
 Provide an indication of how data are transformed as they
move through the system
 Depict the functions (& sub-functions) that transform the
data flow
State Transition Diagram
 Indicates how system behaves as consequences of
external events
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
5
Analysis Modeling:
Where to Begin?
A statement of scope can be acquired
from:
 the FAST working document
 A set of use-cases
the statement of scope must be
“parsed” to extract data, function and
behavioral domain information
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
6
Statement of Scope
a relatively brief description of the
system to be built
 indicates data that are input and output and
basic functionality
 indicates conditional processing (at a high
level)
 implies certain constraints and limitations
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
7
Identifying Objects
and Operations
define “objects” by underlining all nouns
in the written statement of scope
 producers/consumers of data
 places where data are stored
 “composite” data items
define “operations” by double underlining
all active verbs
 processes relevant to the application
 data transformations
consider other “services” that will be
required by the objects
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
8
Data Modeling
and
Entity Relationship (E-R)
Diagramming
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
9
Why 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, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
10
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, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
11
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, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
12
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, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
13
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, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
14
ERD Notation
One common form:
object1
(0, m)
relationship
(1, 1)
object 2
attribute
Another common form:
relationship
object1
(0, m)
(1, 1)
object 2
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
15
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, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
16
The ERD: An Example
Customer
(1,1)
places
(1,m)
request
for service
(1,1)
standard
task table
generates (1,n)
(1,1)
work
selected
from (1,w) tasks
materials
(1,w)
(1,i)
work
order
(1,1)
(1,1)
consists
of
lists
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
17
Creating a Flow
Model
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
18
The Flow Model
Every computer-based system is an
information transform ....
input
computer
based
system
output
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
19
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, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
20
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, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
21
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, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
22
Data Flow
Data flows through a system, beginning
as input and be transformed into output.
base
height
compute
triangle
area
area
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
23
Data Stores
Data is often stored for later use.
sensor #
report required
sensor #, type,
location, age
look-up
sensor
data
sensor number
type,
location, age
sensor data
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
24
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, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
25
Constructing a DFD—I
review ERD to isolate data objects and
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, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
26
Level 0 DFD Example
user
processing
request
digital
video
processor
video
source
requested
video
signal
monitor
NTSC
video signal
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
27
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, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
28
The Data Flow Hierarchy
x
a
a
b
P
c
p2
level 1
p4
p3
level 0
f
p1
d
y
e
g
5
b
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
29
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, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
30
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, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
31