0% found this document useful (0 votes)
187 views

05 Data Flow Diagrams

Process-oriented approaches model systems using processes, data flows, and data stores. A process transforms inputs like data or events into outputs. Data flows represent the movement of data between processes and data stores. Data flow diagrams visually depict the flow of data in a system using common symbols like data stores, processes, sources and sinks, and data flows. These diagrams help understand and communicate how data moves through various processes in a system.
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
187 views

05 Data Flow Diagrams

Process-oriented approaches model systems using processes, data flows, and data stores. A process transforms inputs like data or events into outputs. Data flows represent the movement of data between processes and data stores. Data flow diagrams visually depict the flow of data in a system using common symbols like data stores, processes, sources and sinks, and data flows. These diagrams help understand and communicate how data moves through various processes in a system.
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 58

Process - Oriented Approach And Data

Flow Diagrams

1
Structuring Systems Requirements

• Process Modeling Process-Oriented Approach


• Data Modeling
Data-Oriented Approach
• Object Modeling
Object-Oriented Approach

2
Process-Oriented Approach
A business entity can be thought of as a system.

Environment

System

Input Output

3
System
• System: Turns data into information and includes:
– Hardware and system software
– Documentation and training materials
– Job roles associated with the system
– Controls to prevent theft or fraud
– The people who use the software to perform their jobs
• Figure 1-2 illustrates all the components of a system

4
System

5
System
• A system is an interrelated set of business
procedures used within one business unit
working together for a purpose
• A system has nine characteristics
• A system exists within an environment
• A boundary separates a system from its
environment

6
Characteristics of a System

7
Important System Concepts
• Decomposition
– The process of breaking down a system into smaller
components
– Allows the systems analyst to:
• Break a system into small, manageable subsystems
• Focus on one area at a time
• Concentrate on component pertinent to one group of
users
• Build different components at independent times

8
Important System Concepts
• Modularity
– Process of dividing a system into modules of a
relatively uniform size
– Modules simplify system design
• Coupling
– Subsystems that are dependent upon each other are
coupled

9
Process-Oriented Approach
• Three key components of an information system
• Data vs. Information
– Data
• Raw facts
– Information
• Information is data that has been organized and interpreted, and
possibly formatted, filtered, analyzed, and summarized
• Derived from data
• Organized in a manner that humans can understand

10
Process-Oriented Approach
• Data
– Understanding the source and use of data is key to
good system design
– Various techniques are used to describe data and
the relationship amongst data
• Data Flows
– Groups of data that move and flow through the
system
11
Process-Oriented Approach
• Data Flows (Continued)
– Include description of sources and destination for
each data flow
• Processing Logic
– Describe steps that transform data and events that
trigger the steps

12
Process-Oriented Approach

13
Process-Oriented Approach
• An Organization performs several
processes to accomplish its objectives
• These processes can be quite complex
for human beings to comprehend
• There is therefore a need to model
these processes Environment
System

Input Output

14
Process-Oriented Approach
• At a given point in time, a system has a state.
• A system goes from state to state.
• What causes the state of a system to change?
• A process
– A transaction Environment
– An authorization System

– A data entry Input Output

– A purchase
– A shipment
– A manufacturing task

15
Process-Oriented Approach
• Identifying and graphically modeling each process is
Process Modeling.
• A process can be thought of as a system and vice
versa.
• So a process has an input and an output.
• The input could be a data item or a tangible thing like a
piece of paper or machinery.
Environment
System

Input Output

16
Data Flow Diagrams
• We can represent physical or non-physical entities in
the system with data.
• As the data changes using some process, the state of
the system changes.
• The change and flow of data through processes can be
modeled using data flow diagrams.
Environment
System

Input Output

17
CUSTOMER 1.0 KITCHEN

Customer Order Receive and


Transform
Receipt Customer
Order Food Order

2.0 Goods
Sold 3.0
Update
Goods Sold Inventory Update
Formatted Data Inventory File Formatted
File
Goods Sold Inventory
Data Data

D2 Goods Sold File D1 Inventory File


4.0
Daily Goods
Sold Amounts Produce Daily Inventory Depletion Amounts
Management
Reports RESTAURANT
MANAGER 18
Management Reports
Few Observations
Data is not flowing all the time
Which implies sometimes Data is at rest
- (Data Store)
Something should cause data to move
- (Process)
Data comes into the system from somewhere
- (Source)
Data leaves the system and goes somewhere
- (Sink)
Data flows between Source/ Sink/ Data Store/
Process (Data Flows)
19
Data Flow Diagrams (DFDs)
Using Source/Sink, Process, Data Stores and Data Flows,
we can show the flow of data coming into the system,
within the system and going out of the system.
These symbols are due These symbols are due to
to Gane and Sarson DeMarco and Yourdan
Source / Sink

Process

Data Store

Data Flow 20
What is a source or a sink ?
• A Source provides the origin of data.
– e.g. Customer may provide Order data
– e.g. Employee may provide “Hours Worked” data
• A Sink provides destination of data
– e.g. Reports go to Manager
– e.g. Order data goes to Shipping dept
– e.g. Paycheck goes to Employee
• Sources and Sink are considered outside the system of
interest. They define the boundary of the system.
• Sources and sinks do not have direct access to data stores!!!!
• They have to be identified nevertheless, to understand
the context in which the system has to function.
21
What are Processes?
• A task or set of tasks performed on data by a
person, a machine, or a computer so that the
data are transformed, stored or distributed
• Input data flows are transformed by process and
become output data flows

22
What do Processes do ?
Processes
• capture data from sources
– e.g. the process of taking customer order
• produce/distribute data to sinks
– e.g. the process that generates management
reports
• maintain Data stores
– e.g. the process of updating inventory data
• High-level descriptions of data transformation
operations
– e.g. the process of calculating invoice total
23
What are Data Stores?
• Repository for data temporarily or permanently recorded within
the system
• Data at Rest is a Data Store
– e.g. The Inventory Master File
– e.g. The Customer Master File
– e.g. The Sales Transaction File
– e.g. The General Ledger File
• Data Stores may be on a variety of media such as
Hard Disk, CD, Notebook, Manila Folder
• Direction of data flow ‘to’ or ‘from’ data store designates whether
data is written into or read from data store

24
What are Data Flows?
• A data flow represents data being conveyed to or
from an external entity, a process, or data store
• Data in motion (while going from one point in a
system to another) is Data Flow
– e.g. data flows from Payroll Transaction Files to a
payroll check.
– e.g. data flows from Customer’s mouth to a Order
file
– e.g. data flows from several data stores onto a
report or a query

25
Another Sample DFD
CUSTOMER

Payment 1.0
Record
Receipt
Payment

2.0
3.0
Payment Data Make
Update Payment Data Bank
Customer Deposit
Master

D1 CUSTOMER MASTER BANK


Credit Data Deposit Data

26
Recap
• data flows from a source into the system
(input)
• It flows from the system out to a sink (output)
• While inside the system, data flows between
data stores, and that
• Processes cause data to flow between
source, data stores and sink.

How do we go about building a DFD?


27
Hierarchical Structure
• Data flow diagram is organized in a hierarchical
framework of levels
– Each successive level reveals further details of the
system
• Model of system begins with Context Level DFD
– Level 0 diagram
• Level 1 diagram
– Level 2, 3 ….

28
Start with the Context Diagram
• Highest-level view of the system
• Contain only one process labeled “0”
• No data stores (contained within the process)
• A data flow diagram (DFD) of the scope of an
organizational system that shows the system
boundaries, external entities that interact with
the system and the major information flows
between the entities and the system
29
Start with the Context Diagram
• Here is an example of a context diagram

Student Details

Registration Ackg. 0
Student
Student Registration
System

Enrollment Request

Enrollment Confirmation 30
Level-0 Diagram
• Context level “process” is exploded
• Represents a system’s major processes, data
flows, and data stores at a high level of detail
• Have same sources/sinks as context level
diagram
• Each process number ends in “ .0”

31
Next we Decompose
• You break up (or Decompose) the Context
Diagram to what is called a Level-0 Diagram

Validated Student Details


1.0
Student Details
Enrollment D1 Student Records
(Process)
Confirmation
Of
Enrollments
2.0
Enrollment Acknowledgment
Student Registration
Registration Request (Process)
Vacancies
Registration Confirmation

D3 Courses
D2 Registrations
Confirmed Registration 32
Decompose Further
• Each process can be decomposed further.
• Each process on level 0 diagram is exploded to deeper levels as
necessary
– inputs and outputs shown must be the same at successive
DFD levels
• Consistency of Levels
– The extent to which information contained on one level of a
set of nested DFDs is also included on other levels.
• If we decompose a process in a Level-0 Diagram,
we go to a Level-1 Diagram.
• Let’s look at an example.
33
Let us decompose the
Enrollment Process further
We will get a Level-1 Diagram
Acknowledgment
D1 Student Records
1.1
Student Student Query 1.3
Details Check if
already Produce
Accepted Student Details Ackg.
Enrolled
Receipt
1.2
Exception-
Validated
Already Validate Student Validated
Enrolled Student Details Student
Details
Details
Exception-
Invalid D1 Student Records
34
Decompose Further?

• Sure
• You will get a level-2 Diagram
• You decompose process 1.1 into three
parts

35
How far can we go with this
decomposition?
• It is really your decision
• But at some point, the process will be so
trivial that it need not be decomposed
any further
• Such a process is called a primitive
process
• Lowest level is called a primitive DFD
36
Rules of decomposition
• When decomposing you the inputs and
outputs should be conserved.
• I.e. A decomposed process must have
the same inputs and outputs as the pre-
decomposed process
• This is called Balancing a DFD

37
Balancing DFDs
• When decomposing a DFD, you must conserve inputs
to and outputs from a process at the next level of
decomposition
• This is called balancing
• Example: Hoosier Burgers
– In Figure, notice that there is one input to the system, the
customer order
– Three outputs:
• Customer receipt
• Food order
• Management reports
38
Balancing DFDs
• Example (Continued)
– Notice the figure. We
have the same inputs and
outputs
– No new inputs or outputs
have been introduced
– We can say that the
context diagram and level-
0 DFD are balanced

39
Balancing DFDs
• An unbalanced example
– In context diagram, we have one input to the system,
A and one output, B

40
Balancing DFDs

– Level 0 diagram has one additional data flow, C


– These DFDs are not balanced

41
Balancing DFDs
• We can split a data flow into separate data flows
on a lower level diagram

42
Rules for Data Flows
• Data flow has only one direction of flow between
symbols (unidirectional)
• Data is moved from Source (noun) and to a Sink
(noun) by a Process
• Data cannot go directly back into same process
it leaves

43
Rules for Data Stores
• Data in Data Store is moved by a Process
• Data cannot move directly from a source to a
data store
• Data cannot move directly from a data store to
sink
• Data cannot move directly from one data store to
another

44
Rules for Processes
• Each process must have a unique name
• Processes must have at least one input and one output
data flow
• At the lowest level DFD, every process should perform
only one well-defined function
– usually indicated by a single input and a single output
• Primitive Processes
– processes on the lowest level of the DFD

45
Rules of Sources/Sinks
• Data cannot move directly from a source to sink

46
Incorrect and correct DFDs
Miracle process
not allowed

Black hole process


not allowed

Data must be moved


from one data store
to another by a
process
47
Incorrect and correct DFDs
Data must be moved
from Source to a data
store by a process

Data must be moved


from a data store to a
sink by a process

Data must be moved


from Source to Sink
by a process
48
Incorrect and correct DFDs
Data flow is
unidirectional

A A
Fork not allowed if
outgoing dataflow are B A
different

B A
Join allowed only for
the same data.
A A

49
Incorrect and correct DFDs
A B
Data cannot flow
directly back to the A
A
same process. A

50
Four Different types of DFDs
• Current Physical
– Process label includes an identification of the technology
(people or systems) used to process the data
– Data flows and data stores are labeled with the actual name of
the physical media on which data flow or in which data are
stored
• Current Logical
– Attempt to show the essence of the system without regard to
the actual physical implementation. Physical aspects of system
are removed as much as possible
– Current system is reduced to data and processes that
transform them. In a Logical DFD, Data Stores, Data Flows
and Processes are independent of media.
51
Four Different types of DFDs
• New Logical
– Includes additional functions
– Obsolete functions are removed
– Inefficient data flows are reorganized
• New Physical
– Represents the physical implementation of the new
system

52
How are DFDs used?
DFDs are used as an aid for
understanding the existing system
They are then used to analysis to look for
improvements

Here is the sequence


Current Logical DFD

Current Physical DFD New Logical DFD

New Physical DFD


53
More Guidelines for Drawing DFDs
1. Completeness
– DFD must include all components necessary for
system
– Each component must be fully described in the
project dictionary or CASE repository
2. Consistency
– The extent to which information contained on one
level of a set of nested DFDs is also included on
other levels
54
Guidelines for Drawing DFDs
3. Timing
– Time is not represented well on DFDs
– Best to draw DFDs as if the system has never
started and will never stop.
4. Iterative Development
– Analyst should expect to redraw diagram several
times before reaching the closest approximation to
the system being modeled
55
Guidelines for Drawing DFDs
• Rules for stopping decomposition
– When each process has been reduced to a single
decision, calculation or database operation
– When each data store represents data about a single
entity
– When the system user does not care to see any
more detail

56
Guidelines for Drawing DFDs
• Rules for stopping decomposition (continued)
– When every data flow does not need to be split
further to show that data are handled in various ways
– When you believe that you have shown each
business form or transaction, on-line display and
report as a single data flow
– When you believe that there is a separate process
for each choice on all lowest-level menu options

57
Using DFDs as Analysis Tools
• Examine DFDs for:
– redundant data flows
– data that are captured but not used
– data that are updated identically in more than one location
– excessive processing steps
• Compare new with old logical DFD
– possible component reuse
• Gap Analysis
– The process of discovering discrepancies between two or more
sets of data flow diagrams or discrepancies within a single
DFD
• Inefficiencies in a system can often be identified through DFDs
58

You might also like