Chapter 8
Analysis Modeling
Adapted by Dan Fleck from:
- Roger Pressman’s Slides
- http://www.informatics.sussex.ac.uk/users/lb203/se/SE04.pdf
- Jochen Rick’s slides from GA Institute of Technology
- http://webfuse.cqu.edu.au/Courses/aut2001/95169/
Extra_Examples/DFD_Example_1/
- System Analysis and Design slides edited by Yale Braunstein
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.
2
Analysis Phase: What is it?
system
description
analysis
model
design
model
Three objectives:
• To describe what the customer requires
• To establish a basis for the creation of a software design
• To define a set of requirements that can be validated once
the software is built
3
Analysis Modeling Approaches

Structural analysis:



The data: The model defines their attributes and
relationships.
The processes that transform the data: The
model shows how they transform the data objects
as they flow through the system.
Object-oriented analysis:


Focus: Classes and their inter-relationships
UML is predominantly object-oriented
But don’t be to dogmatic!
4
Elements of the Analysis Model
Scenario-based
elements
Use-case diagrams
Use cases - text
Activity Diagrams
Swim lane diagrams
Flow-oriented
elements
Data-flow diagrams
Control flow diagrams
Processing narratives
Analysis
Model
Class-based elements
Class diagrams
Analysis Packages
CRC Models
Collaboration Diagrams
Behavioral elements
State diagrams
Sequence diagrams
5
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
6
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
What are some typical data objects?
7
Typical Data 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)
8
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
How do data objects differ from OO classes or do they?
9
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
10
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
See http://www.smartdraw.com/tutorials/software/erd/tutorial_01.htm
for a tutorial on how to draw entity relationship diagrams.
11
The ERD: An Example
Customer
(1,1)
places
(1,m)
request
for service
(1,1)
standard
task table
generates
(1,1)
selected
from
work
(1,w) tasks
materials
(1,w)
(1,i)
(1,n)
work
order
(1,1)
(1,1)
consists
of
lists
12
The Flow Model
Every computer-based system is an
information transform ....
input
computer
based
system
output
13
Flow Modeling Notation
external entity
process
data flow
data store
14
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
15
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
16
Data Flow
Data flows through a system, beginning
as input and be transformed into output.
base
height
compute
triangle
area
area
17
Data Stores
Data is often stored for later use.
sensor #
report required
look-up
sensor
data
sensor number
sensor #, type,
location, age
type,
location, age
sensor data
18
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
19
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
20
Level 0 DFD Examples
user
processing
request
digital
video
processor
video
source
requested
video
signal
monitor
NTSC
video signal
21
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
22
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
23
Example DFD: Level 1
24
DFD: A practical example
Launched Dec. 11, 1998, the Climate Orbiter plunged too steeply
into the Martian atmosphere Sept. 23, 1999, and either burned up
or crashed. In an initial failure report released Oct. 15, 2000 the
review board blamed the navigation error on a communications
foul-up between NASA's Jet Propulsion Laboratory and prime
contractor Lockheed Martin.
Who was
responsible
for this task?
Transfer of Flight Control Data
This process
was missing
JPL-1
?
?
LM-1
Collect,
analyze,
generate flight
control data
Transfer data
Convert data
from Metric to
English
Control
spaceflight
Metric data
English data
25
J1
JPL store
LM1
LM store
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)
26
Activity Diagram
Supplements the use-case
by providing a diagrammatic
representation of procedural
flow
ent er password
and user ID
valid passwor ds/ ID
invalid passwor ds/ ID
select major f unct ion
How might we make this
better?
prompt f or reent ry
ot her f unct ions
m ay also be
select ed
input t r ies r em ain
selec t surveillance
no input
t r ies r em ain
t hum bnail views
select a specif ic cam er a
select specif ic
camera - t humbnails
select camera icon
view camera out put
in labelled window
prompt f or
anot her v iew
27
exit t his f unct ion
see anot her cam er a
Swimlane Diagrams
Allows 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
homeowner
c a m e ra
i n t e rf a c e
ent er pas sword
and us er ID
valid p asswo r d s/ ID
in valid
p asswo r d s/ ID
s elec t m ajor f unc t ion
o t h er f u n ct io n s
m ay also b e
select ed
prom pt f or reent ry
in p u t t r ies
r em ain
select s urveillanc e
n o in p u t
t r ies r em ain
t h u m b n ail views
select a sp ecif ic cam er a
s elec t s pecif ic
c am era - t hum bnails
selec t cam era ic on
generat e v ideo
out put
view c am era out put
in labelled window
prom pt f or
anot her v iew
exit t h is
f u n ct io n
see
an o t h er
cam er a
28
Activity Diagram Example
-
To show concurrent
activity, activity
diagrams allow
branches and joins.
-
You can also
reference or
include other
activity diagrams
29
Lets Try It

Lets create a swimlane activity diagram for
opening a Lemonade stand.
30
Elements of the Analysis Model
Scenario-based
elements
Use-case diagrams
Use cases - text
Activity Diagrams
Swim lane diagrams
Class-based elements
Class diagrams
Analysis Packages
CRC Models
Collaboration Diagrams
Onward to data flow diagrams!
Flow-oriented
elements
Data-flow diagrams
Control flow diagrams
Processing narratives
Analysis
Model
Behavioral elements
State diagrams
Sequence diagrams
31
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, floworiented modeling continues to provide a view of the
system that is unique—it should be used to supplement
other analysis model elements
32
Elements of the Analysis Model
Scenario-based
elements
Use-case diagrams
Use cases - text
Activity Diagrams
Swim lane diagrams
Flow-oriented
elements
Data-flow diagrams
Control flow diagrams
Processing narratives
Analysis
Model
Class-based elements
Class diagrams
Analysis Packages
CRC Models
Collaboration Diagrams
Oh behave!
Behavioral elements
State diagrams
Sequence diagrams
33
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.
34
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 35
processing.
State Diagram for the
ControlPanel Class
t imer < lockedTime
t imer > lockedTime
locked
password = incorrect
& numberOfTries < maxTries
comparing
reading
numberOfTries > maxTries
key hit
password
ent ered
do: validat ePassw ord
password = correct
select ing
act iv at ion successful
36
The States of a System




state—a set of observable
circumstances 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
37
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
38
State Diagram - Lets Try It!
You are designing
a traffic light
system for this
intersection.
North
West
Draw a state
diagram showing
the different
states and how
they transition.
East
South
39
Elements of the Analysis Model
Scenario-based
elements
Use-case diagrams
Use cases - text
Activity Diagrams
Swim lane diagrams
Flow-oriented
elements
Data-flow diagrams
Control flow diagrams
Processing narratives
Analysis
Model
Class-based elements
Class diagrams
Analysis Packages
CRC Models
Collaboration Diagrams
Onward to Class-based elements!
Behavioral elements
State diagrams
Sequence diagrams
40
Object Oriented Analysis (OOA)

The intent of OOA is to define all classes (and the
relationships and behavior associated with them)
that are relevant to the problem to be solved. For
that, a number of tasks must occur:
1.
2.
3.
4.
5.
Classes must be identified (i.e., attributes and methods)
A class hierarchy is defined
Object-to-object relationships should be represented
Object behavior must be modeled
Tasks 1 through 4 are reapplied iteratively
41
Object-Oriented Concepts

What are the basic object oriented
concepts?
42
Object-Oriented Concepts

What are the basic object oriented
concepts?




Classes and objects
Attributes and operations
Encapsulation and instantiation
Inheritance
43
Encapsulation/Hiding
The object encapsulates
both data and the logical
procedures required to
method
manipulate the data
method
#2
#1
data
method
#3
method
#6
method
#5
method
#4
Achieves “information hiding”
44
Scenario Based Modeling:
Use-Cases
“[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



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
for a given scenario
45
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
46
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 . . .
What is object oriented domain analysis then?
47
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
48
Grammatical Parsing

Write an informal description of the problem. The
customer requirements document is one such
description.

Underline all nouns in the description

Decide which of these are really objects which the
project requires and organize them in related
clusters
49
Grammatical Parsing
University Bank will be opening in Oxford, Mississippi, in January,
2000. We plan to use a full service automated teller machine (ATM)
system.The ATM system will interact with the customer through a
display screen, numeric and special input keys, a bankcard reader, a
deposit slot, and a receipt printer.Customers may make deposits,
withdrawals, and balance inquires using the ATM machine, but the
update to accounts will be handled through an interface to the
Accounts system.Customers will be assigned a Personal Identification
Number (PIN) and clearance level by the Security system. The PIN can
be verified prior to any transaction.In the future, we would also like to
support routine operations such as a change of address or phone
50
number using the ATM
Grammatical Parsing

University Bank will be opening in Oxford, Mississippi, in
January, 2000. We plan to use a full service automated teller
machine (ATM) system.The ATM system will interact with the
customer through a display screen, numeric and special
input keys, a bankcard reader, a deposit slot, and a receipt
printer.Customers may make deposits, withdrawals, and
balance inquires using the ATM machine, but the update to
accounts will be handled through an interface to the
Accounts system.Customers will be assigned a Personal
Identification Number (PIN) and clearance level by the
Security system. The PIN can be verified prior to any
transaction.In the future, we would also like to support routine
operations such as a change of address or phone number
using the ATM
51
Typical Classes (a reminder)







External entities - printer, user, sensor
Things - 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 or loading dock)
Structures (e.g., sensors, four-wheeled vehicles, or computers)
But, how do we select classes?
52
Selecting Classes—Criteria
retained information
needed services
multiple attributes
common attributes
common operations
essential requirements
53
CRC Modeling

See specific CRC slides
54
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.
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 nonfunctional 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.
55
Writing the Software Specification
Everyone knew exactly
what had to be done
until someone wrote it
down!
56
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?"
57
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?
58
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
59