Part 3: Behavioral Modeling & Other Notation
ESE Module 3-3
Structured Analysis
Part 3: Behavioral Modeling & Other Notation
Whether we're talking about a child, an automobile,
or a software application, behavior is something that
we can observe. It's also something that occurs
because of an event. Say No to a small child and cry-
ing may be the behavioral state that you observe.
Depress the brake of a high performance automobile
and braking will be the state that results. Click a
mouse on read file in an on-line application, and
reading commences.
Therefore, when we model behavior, we must
represent two things: (1) the event that causes the
behavior to occur, and (2) the state that we observe
as a consequence of the event.
The analysis model that we create using struc-
tured analysis incorporates the behavioral model with
the data and functional models described in parts 1
and 2 of ESE Module 3-3. But to make the analysis
model more robust, we need additional information.
First, it would be useful to have a complete listing of all
attributes for all data objects that were described in
the data model. This is accomplished with the data
dictionary. Next, it is necessary to have a more com-
plete description of all process bubbles depicted in
the data flow (functional) model. The process specifi-
cation (PSPEC) provides the detail that we need.
Behavioral Modeling
It's common to confuse function and behavior.
Function tells us how software transforms information.
In essence, a functional description answers the ques-
tion; `What does the software do?" Behavior tells us
how an application reacts to some external event
(e.g.. a mouse click an interrupt). As it reacts, the soft-
ware will often invoke one or more functions (trans-
forming data), but the actual behavior is indepen-
dent of these functions and occurs as a consequence
of an event.
Readings
The following reading has been adapted from unpub-
lished materials developed by Dr. Pressman and dis-
cusses behavioral modeling.
Why is it important to model the behavior of a system and
how do we go about doing it? Reasonable questions that
have straightforward answers.
Why is it important? Behavioral modeling provides us
with a system view that cannot be captured by either the
data or the functional model. Both the data model and the
functional model are static views of the system. The behav-
ioral model is a more dynamic view that provides an indi-
cation of how the software reacts to changes in its environ-
ment. By providing a third view of the software, the behav-
ioral model enables the software engineer to better exam-
ine requirements and to uncover omissions or inconsisten-
cy more effectively.
How do we go about doing it? We begin by defining a
number of key terms:
State. A set of observable circumstances that characterize
the behavior of a system at a given time.
State transition. The movement from one state to another.
Event. An occurrence that causes state transition (i.e., that
causes the system to exhibit some predictable form of
behavior).
Action. A function (process) that is invoked as a conse-
quence of making a transition from one state to another.
With these ideas defined, we can describe a sequence
of steps for creating a behavioral model.
1. List all external events that the system recognizes.
2. Indicate the action that occurs as a consequence of
each event.
3. Group the actions into behavioral states (e.g., the
actions open, read, and close can all be grouped into a
reading state).
4. List all behavioral states.
The state transition diagram (STD) is the structured
analysis notation that is used to represent system behavior.
Figure 1 depicts the basic elements of the STD. A state is
represented as a labeled rectangle. An arrow connects two
states and represents a state transition. A ruled expression
labels each arrow (transition) and indicates the event caus-
ing the transition (top) and the action that occurs as a con-
sequence of the transition (bottom).
The state transition diagram is created using the list of
3-3p3.2 ·· Essential Software Engineering
events and behavioral states that were defined in the steps
described above. Beginning with the head state (the state
that the system is in when it is initiated), the software engi-
neer lists all events that are recognizable in that state, and
then draws and labels arrows emanating from the head
state. Each arrow represents (1) a transition to another state
(as yet not depicted), or (2) an event that does not cause a
transition. (Hence the arrow loops back into the state from
which the event was recognized.)
Since the occurrence on an event causes some action,
the bottom part of the ruled expression is completed for
each event arrow. Another named state is drawn at the
head of each arrow which represents a transition to another
slate. This process continues until the STD is completed.
Once the preliminary version of the STD has been
developed, it is reviewed to ensure that:
- all states have been defined and represented;
- each of the states can be reached through a sequence of
events;
- each of the states can be exited in some way;
- all events fielded in a particular state result in an
appropriate transition and action.
It is likely that the preliminary draft of the STD will require
some iteration as new events and states become apparent
and new transitions are understood.
Exercise 3-9.
Behavioral Modeling
Recall the electronic checkbook problem introduced
in ESE Module 3-2: Assume that you work for a con-
sumer products company that is about to build an
electronic checkbook, called ElectroChex. The prod-
uct, about the size and shape of a standard check-
book will print checks that you insert into a slot at the
end. The product stores up to 256 payee names, cat-
egorizes payments, allows you to enter numeric and
alpha information via a qwerty keyboard and has
communication capabilities to PCs.
1. List all external events that the system recognizes.
2. Indicate the action that occurs as a conse-
quence of each event.
3. Group the actions into behavioral states (e.g., the
actions open, read, and close can all be grouped
into a reading state).
4. List all behavioral states.
- Create a state transition diagram for the ElectroChex software.
Review your results with those produced by a colleague.
The Process Specification (PSPEC)
The models that we have described through ESE
Module 3-3 have been graphical in nature. That
makes them relatively easy to comprehend but
reduces the information bandwidth that is communi-
cated to others.
To understand fully the workings of the functional
model (the data flow diagram), we need to increase
the information bandwidth. This is accomplished with
the process specification, PSPEC.
The PSPEC. sometimes called a processing narra-
tive, is a natural language description of the inner
workings of each process transform (bubble) at the
lowest level of DFD refinement
Readings
The following excerpt has been adapted from
Software Engineering: A Pracfitioner's Approach and
presents a brief discussion of the PSPEC.
The process specification (PSPEC) is used to describe all flow
model processes that appear at the final level of refine-
ment. The content of the process specification can include
narrative text, a program design language (PDL) description
of the process algorithm, mathematical equations, tables,
diagrams or charts. Program design language (also called
pseudocode) is often used as a procedural design notation
and combines programming language constructs with nat-
ural language phrases.
By providing a PSPEC to accompany each bubble in
the flow model, the software engineer creates a mini-spec
that can serve as a first step in the creation of the Software
Requirements Specification and as a guide for design of the
program component that will implement the process.
To illustrate the use of the PSPEC, consider a software
application in which the dimensions of various geometric
objects are analyzed to identify the shape of the object.
Refinement of a context-level data flow diagram continues
until level 2 processes are derived. One of these, named
analyze triangle, is depicted in Figure 1.
The PSPEC for analyze triangle is first written as an
English language narrative as shown in the figure. If addi-
tional algorithmic detail is desired at this stage, a program
design language representation may also be included as
part of the PSPEC. However, many believe that the PDL
version should be postponed until design commences.
Structured Analysis: Behavioral Modeling & Other Notation .. 3-3p2.3
The Data Dictionary
The data dictionary provides us with content informa-
tion. Each data object described as part of the data
model has a set of attributes. These attributes repre-
sent the content of the object. The data dictionary is
an organized way of representing this information.
Readings
The following excerpt has been adapted from
Software Engineering: A Practitioner’s Approach and
presents a discussion of the data dictionary.
The data dictionary is a quasi-formal grammar for describ-
ing the content of objects defined during structured analy-
sis. This important modeling notation has been defined in
the following manner [1]:
The data dictionary is an organized listing of all data ele-
ments that are pertinent to the system, with precise, rigor-
ous definitions so that both user and system analyst will
have a common understanding of inputs, outputs, compo-
nents of stores and [even] intermediate calculations.
Today, the data dictionary is almost always implemented
as part of a CASE structured analysis and design tool.
Although the format of dictionaries varies from tool to tool,
most contain the following information:
- name--the primary name of the data or control item,
the data store or an external entity;
- alias--other names used for the first entry
where-used/how-used--a listing of the processes that use
the data or control item and how it is used (e.g., input to
the process, output from the process, as a store, as an exter-
nal entity);
- content description--a notation for representing content;
- supplementary information--other information about
data types, preset values (if known), restrictions or limita-
tion, etc.
Once a name and its aliases are entered into the data
dictionary, consistency in naming can be enforced. That is,
if an analysis team member decides to name a newly
derived data item xyz, but xyz is already in the dictionary,
the CASE tool supporting the dictionary posts a warning to
indicate duplicate names. This improves the consistency of
the analysis model and helps to reduce errors.
Where-used/how-used information is recorded auto-
matically from the flow models. When a dictionary entry is
created, the CASE tool scans DFDs and CFDs to determine
which processes use the data or control information and
how it is used. Although this may appear unimportant, it is
actually one of the most important benefits of the dictio-
nary. During analysis an almost continuous stream of
changes occurs. For large projects, it is often quite difficult
to determine the impact of a change. Many a software engi-
neer has asked, "Where is this data item used? What else
will have to change if we modify it? What will the overall
impact of the change be?" Because the data dictionary can
be treated as a database, the analyst can ask where-
used/how-used questions, and get answers to queries
noted above.
The notation used to develop a content description,
illustrated in Figure 12.32 SAPE, enables the analyst to represent composite datn in one of the three fundamental ways that it can be constructed:
1. as a sequence of data items;
2. as a selection from among a set of data items;
3. as a repented grouping of data items, or
4. as an optional data item
Each data item entry that is represented as part of a
sequence, selection or repetition may itself be another
composite data item that needs further refinement within
the dictionary.
To illustrate the use of the data dictionary and the con-
tent description notation, we consider a data item named
telephone number. But what exactly is a telephone num-
ber? It could be a 7-digit local number, a 4-digit extension,
or a 25-digit long distance carrier sequence. The data dic-
tionary provides us with a precise definition of telephone
number for the DFD in question. In addition it indicates
where and how this data item is used and any supplemen-
tary information that is relevant to it. The data dictionary
entry begins as follows:
name: telephone number
aliases: none
where-used/how-used:
assess against set-up (output)
dial phone (input)
description:
telephone number = [local extension | outside
number]
The content description may be read: telephone number is
composed of either a local extension (for use in a large fac-
tory) or an outside number. Local extension and outside
number represent composite data and must be refined fur-
ther in other content description statements. Continuing
the content description:
telephone number = [local extension | outside number]
local extension = [2001 | 2002 | ... | 2999]
outside number = 9 + [local number | long-distance number]
local number = prefix + access number
long-distance number = (1) + area code + local number
prefix = [795 | 799 | 874 | 877]
access number = * any four-number string *
The content description is expanded until all composite
data items have been represented as elementary items
(items that require no further expansion) or until all com-
posite items are represented in terms that would be well
known and unambiguous to all readers (e.g., area code is
generally understood to mean a three-digit number that
never starts with 0 or 1 and always has a 0 or 1 as the sec-
ond digit). It is also important to note that a specification of
elementary data often restricts a system. For example, the
definition of prefix indicates that only four branch
exchanges can be accessed locally.
The data dictionary defines information items unam-
biguously. Although we might assume that the telephone
number could accommodate a 25-digit long-distance carri-
er access number, the data dictionary content description
tells us that such numbers are not part of the data that may
be used.
For large computer-based systems, the data dictionary
grows rapidly in size and complexity. In fact, it is extreme-
ly difficult to maintain a dictionary manually. For this ma-
son, CASE tools should be used.
[1] Yourdon, E., Modem Structured Analysis, Prentice-Hall,
1989.
Exercise 3-10.
Data Dictionary
Read the following problem description and then per-
form the tasks required to build a data model and
data dictionary.
Problem Statement (Reproduced from Exercise 3-8 in
ESE Module 3-3, part 2): The Department of Public
Works for a large city has decided to develop a com-
puterized pothole tracking and repair system (PHTRS).
As potholes are reported, they are assigned an identi-
fying number, stored by street address, size (on a
scale of 1 to 10), location (middle, curb, etc.), district
(determined from street address), and repair priority
(determined from the size and location of the pot-
hole). Work order data associated with each pothole
includes pothole location and size, repair crew identi-
fying number, number of people on crew, equipment
assigned, hours applied to repair, hole status (work in
progress, repaired, temporary repair, not repaired),
amount of filler material used and cost of repair (com-
puted from hours applied, number of people, material
and equipment used). Finally, a damage file is creat-
ed to hold information about reported damage due
to the pothole and includes citizen's name, address,
phone number type of damage and dollar amount
of damage. PHTRS is an on-line system; queries are to
be made interactively. The user interacts with the sys-
tem using a city map (with appropriate zoom capabil-
ities) that enables pothole information to be entered
and displayed. For example, all streets in a five-block
section of the city can be displayed with each pot-
hole located.
1. Develop a data dictionary for PHTRS.
a. list all data objects
b. specify all attributes that compose a composite data item
c. using the data flow diagram developed in Exercise 3-8, develop a where-used/how-used list.
2. Review your data dictionary against the models developed in Exercise 3-8 for consistency.
3. Review your results with those produced by a colleague.
3-3p3.4 · Essential Software Engineering
Post-Test, Module 3-3, part 3
This post-test has been designed to help you assess
the degree to which you've absorbed the information
presented in this ESE module.
STDs, PSPECs and the Data Dictionary
1. A behavioral state can be described as:
a. a mathematical relationship
b. an externally observable mode of behavior
c. an externally observable function
- all of the above
2. A transition occurs when:
a. one event leads to another
b. one state leads to another
c. an event leads to a change of state
d. a state leads to a change in events
3. The ruled expression (labeled arrow in a state
transition diagram) indicates:
a. event and action
b. event and state
c. processing action and data
d. data
e. none of the above
4. Once the first draft of an STD has been devel-
oped, you should:
a. determine whether all states have been
specified
b. check to determine that each state can be
achieved and exited
c. determine when events and actions have
been properly specified
d. all of the above
e. none of the above
- The analysis model is made up of n views, where n
Is:
a. 1
b. 2