MIRPUR UNIVERSITY OF SCIENCE AND TECHNOLOGY (MUST), MIRPUR
DEPARTMENT OF COMPUTER SCIENCE & INFORMATION TECHNOLOGY
SOFTWAR ENGINEERING-I
BIT-2402
Lecture 10-11: Analysis Modeling structured
Approach
Samreen Ayaz
LECTURE CONTENTS
➢Analysis Modelling
➢Data Modelling and ERD
➢Flow Model DFD
➢Behavioral Modelling(STD)
➢Data Dictionary
➢Specification Guidelines
Subject Name
Software Engineering-I
33
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
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
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
Data Modeling
and
Entity Relationship (E-R)
Diagramming
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
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
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)
(e.g., division, team)
organizational units
places (e.g., manufacturing floor)
structures (e.g., employee record)
Data Objects and Attributes
A data object contains a set of attributes that
act as an aspect, quality, character-istic, or
descriptor of the object
object: automobile
attributes:
make
model
body type
price
options code
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
ERD Notation
One common form:
object 1
(0, m)
relationship
(1, 1)
object
2
attribute
Another common form:
relationship
object 1
(0, m)
object
(1, 1)
2
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
The ERD: An Example
Name
ID
Customer
(1,1)
places
(1,m)
request
for service
(1,1)
standard
task table
generates (1,n)
(1,1)
work
selected
(1,w) tasks
from
materials
(1,w)
(1,i)
work
order
(1,1)
consists
of
lists
(1,1)
Creating a Flow Model
The Flow Model
Every computer-based system is an
information transform ....
input
computer
based
system
output
Flow Modeling Notation
external entity
process
data flow
data store
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
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
Data Flow
Data flows through a system, beginning
as input and be transformed into output.
base
height
compute
triangle
area
area
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
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
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
Level 0 DFD Example
user
processing
request
digital
video
processor
video
source
NTSC
video signal
requested
video
signal
monitor
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
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
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)
DFDs: A Look Ahead
analysis model
Maps into
design model
Behavioral Modeling
and Process Specification
Behavioral Modeling
events
Outside
world
behavior
Application
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
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
State Transition Diagram:Notation
state
event causing transition
action that occurs
new state
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
problem state
not jammed
invoke read-op-input
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
Control Flow Diagram
copies done
beeper on/off
read
operator
input
start
empty
problem
light
manage
copying
reload
process
create
user
displays
perform
problem
diagnosis
display panel enabled
jammed
full
Control Specification (CSPEC)
The CSPEC can be:
state transition diagram
(sequential spec)
state transition table
decision tables
activation tables
combinatorial spec
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?"
Process Specification (PSPEC)
bubble
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
A Design Note
PSPEC
one or more ”components"
in the software design
Creating Mini-Specs
Software
Specification
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
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)
Data Dictionary Notation
Notation
Meaning
=
is composed of
+
and
[
]
n
either-or
{ }
n repetitions of
( ... )
optional data
* ... text ...*
delimits a comment
Data Dictionary Example
telephone number
integrated
office
phone
system
system output
Build the requirements dictionary:
Name:
telephone number
Aliases:
phone number, number
Where/How
used:
read-phone-number (input)
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
Writing the Software Specification
Everyone knew exactly
what had to be done
until someone wrote it
down!
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?"
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?
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
REFERENCE
• Software Engineering: A Practitioner’s Approach, 7/e by Roger
S. Pressman
Software Engineering-I
51
THANKS