Modeling

Slide 13
Chapter 12.5
Behavioral Modeling
Start from section 12.5 SEPA

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
Behavioral Modeling
events behavior
Outside
Application
world
2
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
3
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 transition diagram
4
State Transition Diagram
Notation
state
event causing transition

action that occurs
new state
5
State Transition Diagram
full and start
invoke manage-copying reading
operator
commands
full
invoke read-op-input
copies done
invoke read-op-input
making copies reloading paper

empty
invoke reload paper
jammed
invoke problem-diagnosis
not jammed
problem state invoke read-op-input
6
Control Flow Diagram
Paper feed status
(jammed, empty) Alarm
Start/stop Produce
Manage
user
Copying
displays
Reload
Operator
Input
Perform
Problem
Reload diagnosis
paper
Level 1 CFD for Full

photocopier software Repro fault
++
7
Notes on CFD…
 In reality, the shaded data flow arrows are not
shown as part of CFD
 The vertical bar representing the CSPEC
“window”
 Implies that each of the events flowing into the bar will cause
some process represented in the CFD to be activated
 States do not necessarily correspond to process on
a one-to-one basis
 Eg. Making copies in STD encompass both manage copying and
produce user displays process
++
8
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
9
Control Specification (CSPEC)
The CSPEC can be:
state transition diagram
(sequential spec)
state transition table combinatorial spec

decision tables
activation tables
10
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?"
11
Process Specification (PSPEC)
bubble
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
12
A Design Note
PSPEC one or more ”components"

in the software design
13
Creating Mini-Specs
Software
Specification
14
Real-Time Analysis
Methods
 each introduces its own notation, but all
 propose an approach for representing control and
separating it from data
 provide a mechanism for specifying events, states, and
distributed processing
 begin at the analysis level and work to derive processor
assignments, tasks and program architectures
15
Time continuous data flow
Monitored
temperature Input “continuous”
Output
Monitor “continuous”
And adjust
Temperature
level
Temperature
Set point
++
16
Real-Time Analysis
& Design Methods
 Gomaa, H., Software Design Methods for Concurrent and
Real-Time Systems, Addison-Wesley, 1995.
 Harel, D. et al, "STATEMATE: A Working Environment for
the Development of Complex Reactive Systems, IEEE Trans.
Software Engineering, vol. 16, no. 3, April, 1990, pp. 403-414.
 Hatley, D.J. and I.A. Pirbhai, Strategies for Real-Time System
Specification, Dorset House, 1987.
 Selic, B., G. Gullekson, and P. Ward, Real-Time Object-
Oriented Modeling, Wiley, 1994.
 Shumate, K. and M. Keller,, Software Specification and Design
—A Disciplined Approach For Real-Time Systems, Wiley
1992.
 Ward, P.T. and S.J. Mellor, Structured Development for
Real-Time Systems, 3 volumes, Yourdon Press, 1985, 1986.
17
Data & control flows
Process
Robot Movement
Parts status buffer commands alarm
Start/stop
Bit string flag
Process
Monitor activate
Fixture & Position
Operator commands
interface Process
Operator Robot
Operator settings commands
commands
Robot command file
Ward & Mellor Notation

++
18
DFD &
Absolute tank
CFD
pressure Converted
pressure
Monitor Check &
Fixture & Convert
Max Operator pressure
pressure interface above
pressure
PSPEC
If absolute tank pressure > max pressure
Then
Set above pressure to true
Else
Set above pressure to false
Begin conversion algorithm x-ola
Compute converted pressure
End
endif Hatley & Pirbhai Extension
++
19
The Data Dictionary
a quasi-formal grammar for describing the content
of data that the software will process and create
a notation for describing control data and the

values that control data can take, e.g., "on," or "off"
a repository that also contains "where-used" / "how

used" information
a notation that can be represented manually, but is

best developed using CASE tools
20
Building a Data Dictionary
Name: the primary name of the composite data item
Aliases: other names for the data item
Where used: data transforms (processes) that use the

composite data item
How used: the role of the data item (input, output,

temporary storage, etc.
Description: a notation for representing content (presented

on next slide)
Format: specific information about data types, pre-set

values (if known)
21
Data Dictionary Notation
Notation Meaning
= is composed of
+ and
[ ] either-or
n
{ } n repetitions of
( ... ) optional data
* ... text ...* delimits a comment

22
Data Dictionary Example
integrated
telephone number office system output
phone
system
Build the requirements dictionary:

Name: telephone number
Aliases: phone number, number
Where/How read-phone-number (input)

used: display-phone-number (output)
analyze-long-distance-calls (input)
Description: telephone no. = [ local extension | outside no. | 0 ]

outside no. = 9 + [ service code | domestic no. ]
service code = [ 211 | 411 | 611 | 911 ]
domestic no. = ( ( 0 ) + area code ) + local number
area code = *three numeral designator*
Format: alphanumeric data
23
Next…
24

Modeling

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modeling

Uploaded by

Copyright:

Available Formats

Slide 13

Start from section 12.5 SEPA

 make a list of the different states of a system

event causing transition

making copies reloading paper

Level 1 CFD for Full

a dashed arrow leaving a process implies a data

a dashed arrow entering a process implies a control

state transition table combinatorial spec

focus on possible omissions ... a very common error in

PSPEC one or more ”components"

Robot command file

Ward & Mellor Notation

a notation for describing control data and the

a repository that also contains "where-used" / "how

a notation that can be represented manually, but is

Aliases: other names for the data item

Where used: data transforms (processes) that use the

How used: the role of the data item (input, output,

Description: a notation for representing content (presented

Format: specific information about data types, pre-set

( ... ) optional data

* ... text ...* delimits a comment

Build the requirements dictionary:

Aliases: phone number, number

Where/How read-phone-number (input)

Description: telephone no. = [ local extension | outside no. | 0 ]

Format: alphanumeric data

You might also like