DATA FLOW DIAGRAM

• Emphasises the flow of data in a system and ignores the

procedural aspects.
• DFDs model the system from a functional perspective.
• Tracking and documenting how the data associated with a
process is helpful to develop an overall understanding of
the system.
• Data flow diagrams may also be used in showing the data
exchange between a system and other systems in its
environment

• DFD is a prescription for construction

- processes represented by circles. It transforms input into

output. Ex. Compute- Tax, Validate Phne-no

- data flow, arrows between processes represent the flow of

information from one part of the system to another. It is data in
motion..bit, characters, messages, numbers. Data can be partial
or full
 A B C
P Q

- multiple input data streams and multiple data output streams

are possible

°if two adjacently placed inputs are both required then a * is

placed between these.
A

B * P

° if either of two adjacently placed inputs are required then a

ring-sum is placed between these.

+ Q
B

- data stores represented by parallel lines or open rectangle.

It is collection of data packets at rest.

Data Store Data Store

o Store exist because of user’s requirement or convenient

implementation.
o A flow from Data store can be single, partial or collection
of data packets.

o A flow to data store can be write, delete or update data

packets

- data terminators represented by closed rectangle are also

data stores but they are outside the System and can not be
changed by modeler
 STEPS IN BUILDING DATA FLOW DIAGRAMS
- choose meaningful name for processes, data flow, data
stores and data terminators

- number the processes, this is useful in drawing leveled

DFD

- Work from input to the output, output to the input,

or middle-out

- Only show the flow of control. Ignore initialisation and

termination assume the system never stops.

- Omit simple error paths from each transform to the outside

world

- Use the * and ring-sum operators as appropriate

- The data flow should be correct for the level of detail

concerned. Show more detail rather than less.

- draw DFD as many times as required till it satisfies user

and is technically correct, neat and clear

- Avoid over complex DFD ( not more than 6 processes on

one page
 - DFD should be internally consistent and consistent with
outside word ( every process should have input and output,
beware of read only and write only stores)

LEVELS OF DATA FLOW DIAGRAMS

- Complexity of circle determines number of levels

- Different parts of the system may have different number of

levels.

Levels should be consistent

Guideline

Flows coming into/going out of a circle at one level must

correspond to the flows into/out of an entire figure at the
next lower level which describes the circle
 LEVELS OF DATA FLOW DIAGRAMS

Data stores at different levels

Guideline

Show store at highest level where it is an interface between

circles. Then show at every level below, which further
describes the interface circle.

DS

level 1

DS
level 2

Development Heuristics

- At each level no more than 6 circles + related stores

- Process specification of each circle should fit in one page else

make another level
DATA FLOW DIAGRAMS

Fig 1: Leveling of DFD

Fig 2: 0 Level DFD for College Registration
System
Fig 3: 2 Level DFD for College Registration
System (only Registration Process 1.3)
Fig 4: 1 Level DFD for College Registration
System
THE YOURDON METHOD

THE CARTESIAN PARADIGM

Develop current physical model- model of the actual system

user is using. Here processes can be human, organizational unit
Develop current logical model- model of pure or essential
requirement carried out by the user’s current system
Develop new logical model- pure or essential requirement of
the new system
Develop new physical model.- is a model showing the
implementation constraints imposed by the user( determination
of automation boundary i.e. which functions will be automated
which will be manual

The whole is made up of its parts

Analysis is needed

Properties

- A Global function does not always exist

- Analyst Paralysis: First decomposition not apparent

 THE MODIFIED YOURDON METHOD

Aim: To remove analyst paralysis

- The Essential Model is the model of what the system must do

in order to satisfy user requirements

- The Implementation Model

The Essential Model

What moves across the interface

- outputs in response to stimuli

- inputs needed by the system

It consists of Environment Model and Behavioral Model
Environment Model – defines the boundary between the system
and rest of the word. It consists of three parts

Behavioral Model- describes the inside of the system to interact

successfully with rest of the environment. It consists of models
like ERD, DFF, State-transition diagram, data dictionary and
process specifications.
 THE MODIFIED YOURDON METHOD

THE ENVIRONMENT MODEL

 Statement of purpose of the system

It consists of brief, concise textual statement of the purpose
of the system intended for top management, user
management.

 Context diagram

• people, systems etc. with whom the system

interacts( external agent/ terminators)

• data received to be processed

• data produced by the system sent to the outside worl.d

• data stores shared by system and terminators. These

data stores are either created outside the system and used
by our system or created by our system and used by
outside world.

• The boundary between our system and outside world

 THE MODIFIED YOURDON METHOD

THE ENVIRONMENT MODEL

 Event list:

*Flow oriented event

customer places order
event occurrence upon data arrival
( corresponds to data flow in context diagram . However not
every data flow in context diagram triggers an event

*Temporal event
event occurrence at fixed time or date
Generate sales report every Monday at 0900 Hrs.
They are triggered by internal clock maintained by the syst.
They may need one or more dataflow in context diagram but
these data flow do not trigger temporal events.

*Control oriented event

has control flow with it
Events are internal to system and occur based on system status
When inventory level go below certain level, the event is
generated to place the order
Control event is associated with control flow in the system. It
can be regarded as binary dataflow which can be on or off and
its status can be changed.
THE MODIFIED YOURDON METHOD

THE BEHAVIOUR MODEL

 Classical Approach

top down from context diagram

*Analysis paralysis

-First decomposition not clear

basis of number of analysts!

as in an already existing system!!

 New Approach

event based

- define a process for each event in the event list having the
same response

- identify input/output for each process

- identify stores for every interface between processes

- connect input/output to each process and do consistency

checking
Note: if an event has multiple responses then there is one
process for each response

After the first-cut behaviour model has been built Refine it

- upward levelling

*group processes having closely related responses/dealing with

closely related responses

*if a group of processes uses a data store not used by any other
process group then make one process

-downward levelling

*if a process is not atomic then use functional decomposition

 Data flow analysis

- what processes make up the system

- what data are used in each process
- what data are stored
- what data enter and leave the system
 DATA DICTIONARY

- listing of all data items

- for user/analyst communication

Contains

*meaning of flows/stores

*composition of data packets/stores

*values and units of elementary pieces of information in

flows/stores

*details of relationships between stores

Conventions

** Comments

[] One of several choices

@ Key field of a store

| Choice

= Composed of
 + and

() optional

n{}m at least n, at most m

{}m zero or more, at most m

Example:

Example 1

tel no = (country code) + (area code) + number

country code = {digit} 3

area code = {digit} 5

number = 7 {digit} 8

Example 2

Product code = alpha + alphanum

alpha = 1 {letter} 1

alphanum = 0 (letter/digit} 6
Example 3

Customers = {customer}

Customer = @ customer name + address

+ phone number

customer name = courtesy title + first_name + (middle_ name)

+ last_ name

courtesy_ title= [Mr.| Mrs.| Miss.| Dr.| Prof.]

first_name = { legal_character}
middle_name = { legal_character}
last_name = { legal_character}
legal_character = [A-Z| a-z| 0-9| , |…..]

address= [shipping_ address | Billing_address|

shipping_ address + billing_address]
shipping_address = city_code + state_code + house_No.

Purchases = @ customer + 1{@ item_id + quantity_

purchased}

Weight = * patient weight upon admission to hospital *

* Units: Kg, range: 1—200*
Checks
• Every flow on DFD has been defined
 • all component of composite items have been defined
• all elements in data dictionary are referred in DFD
• notations are correct, no element is defined more than once

Order processing DFD

Checked and
Completed Signed Signed
Send to signed order
order form order form order form supplier + order
Order
notification
details + Complete Validate Record
blank order form order order
order form Adjust
Order available
Signed budget
details order form
Order
amount
+ account
details

Orders Budget
file file

Equipment procurement process

 Delivery
note
Checked Delivery
Equipment note
spec.
Specify spec. Accept Check
Validate Get cost
equipment delivery of delivered
specification estimates
required equipment items
Spec. +
supplier + Installation
Equipment estimate Order
instructions
spec. Supplier list notification
Place
Supplier Find Choose Install
equipment
database suppliers supplier Order equipment
order
details plus
blank order Installation
form acceptance

Accept
delivered
Checked and
equipment
signed order form

Equipment
details

Equipment
database