Chapter 7 – Data Flow Diagrams

Conventions Used in Data Flow Diagrams

- When naming a high-level process, assign the process name of the whole system
e.g., inventory control system
- When naming a major subsystem, use a name such as inventory reporting
subsystem or internet customer fulfillment system
- When naming a detailed process, use verb-adjective-noun combination
o Compute, verify, prepare, print, add, etc.
o Example: preparing shipping invoice, send customer email, verify credit
card balance
- Process must have unique identifying number
Developing Data Flow Diagrams
 - Rules to follow
o DFD must have at least one process and no freestanding objects
connected to themselves
o Process must receive at least one data flow coming into the process and
create at least one data flow leaving the process
o Data store should be connected to at least one process
o External entities should not be connected to each other

Creating the Context Diagram

- Top down
o General to specific
- Initial should be an overview with basic inputs, general system, and outputs
o Bird’s-eye view

Drawing Diagram 0 (The Next Level)

- Explode diagram
- Inputs/outputs from first diagram remain constant in all subsequent diagrams
- Magnifying glass
- Up to 9 processes
- Number each item with an integer (working top-left to bottom-right)
 - Tips
o Start on the entity side
o Work backwards
o Examine data flow to/from data store
 What processes use the data?
o Analyze a well-defined process
 Connect input/output to data store
o Take note of unclear areas and come back later after analyzing

Creating Child Diagrams (more detailed levels)

- Can explode diagram 0 into more detailed child process

- - Vertical balancing
o Child diagram cannot produce output or receive input that the parent
process does not also produce or receive.
- Gets same number as parent process e.g., process 3 would be diagram 3
o Process on the child diagram would be 3.1, 3.2, etc.
- Data stores not shown on the parent process can be shown
o General process on the parent but specific ones on the child
- Non-exploded processes are considered primitive
Checking Diagram for Errors

- Forgetting to include a data flow or pointing an arrow in the wrong direction

- Connecting data stores and external entities directly to each other
- Incorrectly labeling processes or data flow
- Including more than nine processes on a DFD
- Omitting data flow
- Creating unbalanced decomposition (or explosion) in child diagrams
Incorrect

Correct
Logical and Physical Data Flow Diagrams

- Logical
o Focuses on business and how the business operates
o Describes the business events that take place and the data required and
produced by each event.
- Physical
 o How the system will be implemented, including the hardware, software,
files, and people involved in the system

- Analyze current system (current logical DFD) then add features that the new
system should include (proposed logical DFD)
- Best method for implementing (physical DFD)

- Good to create DFD for current system to understand how it works

 o Starting point for proposed

Developing Logical Data

- Developing Logical Data Flow Diagrams

o Construct current system first
- Advantages
o Better comms with users
o Stable systems
o Better understanding of the business by analysts
o Flexibility and maintenance
o Elimination of redundancies

Developing Physical Data Flow Diagrams

 - Shows how system will be constructed and most / all elements

- CRUD matrix can help list activities and the entities they are associated with
o Create, read, update, delete

Event Modeling and Data Flow Diagrams

- Create simple DFD fragment for each unique system event
- Events act as trigger and cause system to do something
- Event response table
Use Cases and Data Flow Diagrams

- Use the use case concept to create DFDs

- Each use case defines one activity and its trigger, input an output
 - Useful to create DFD fragments
- Make initial attempt to define uses cases without going into detail
o Creation of Diagram 0
- Document steps in each use case in form of biz rules that list/explain
human/system activities completed
o List in sequence

Partitioning Data Flow Diagrams

- Divided up a DFD
- How it should be divided into manual procedures and collections of computer
apps
- Six reasons
o Different user groups
 Physically separated groups
o Timing
 If processes execute at different times they cannot be grouped into
one program
 Ex: web pages that need to present large amounts of data may be
broken up into sep programs to display said data
o Similar tasks
 If two processes perform similar tasks, they may be grouped into
one program
o Efficiency
 May group several programs together
 Ex: Group of reports using the same large input files
o Consistency of data
 Ex: credit card company may take a “snapshot” and produce a
variety of reports at the same time so figures are consistent
o Security
 Privilege
 Keep the page that is used for secure login separate from the other
parts of a site
A Data Flow Diagram Example

- Use the below to help develop a DFD

Developing the List of Business Activities

- Develop list through interviews, investigation, and observation

- Identify external entities (customer, accounting, warehouse, etc.) and data flows
(AR report, customer billing statement, etc.).
- Can later be used to define processes, data flows, and data stores

Creating a Context-Level Data Flow Diagram

- Processes are not described in detail

- External entities are shown
- See example on next page
Drawing Diagram 0

- Look at activity list and make a list of as many processes and data stores as you
can find (can add more later)
- Draw diagram 0 if you have enough info
- Keep it high level
- See example on next page
 Creating a child diagram

- Level 1 diagram
- Processes are more detailed, illustrating the logic required to product the output
- Label them 1.1, 1.2, etc.
- List subprocesses first
o ADD CUSTOMER has 7 subprocesses

Creating a Physical Data Flow Diagram from the Logical DFD

- Opportunity to identify processes for scanning barcodes, displaying screens,

locating, and creating and updating files
- Sequence (order) of activities is important
- Describe processes in great detail
Partitioning the Physical DFD

- Reasons for partitioning

o Identifying distinct processes for different user groups, separating
processes that need to be performed at different times, grouping similar
tasks, grouping processes for efficiency, combining processes for
consistency, or separating them for security.
Partitioning Websites

- Improve how site is used

- Speed of processing
- Easier maintenance
- If different databases are involved, may make sense to partition them
- Having separate user forms makes it easier
- Think of selecting a flight where it asks the user to put in their trip info then show
flights instead of showing all available flights first
- Transactions can be kept secure
- See example on next page
Communicating Using Data Flow Diagrams

- Useful because you use original, unexploded DFDs early when ascertaining
information requirements
- Help understand data flow through the system
- Helps to use meaningful labels for all data components
o Do not make them generic