What is a Entity?

Entity —something that is described by a set

of attributes (data items) and that will be
manipulated within the software (system)

each instance of an Entity (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

1
 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 2
 ERD Notation
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 3
 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 4
 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 5
 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 6
 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 7
 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 8
 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 9
 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 10
 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 11
 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 12
 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 13
 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

Any correspondence with a use case 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 14
 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 15
 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 16
 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 17
 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 18
 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 19
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: validat ePassw ord
password = correct

select ing

act iv at ion successful

Does this show passive states or active states?

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
 The States of a System
 state—a set of observable circum-stances 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 21