DATA FLOW DIAGRAMS

1
DATA FLOW DIAGRAMS
2
Systems Analysis

• Focus is the logical view of the system, not the
  physical
• What the system is to accomplish, not how
• Tools
• data flow diagrams
• data dictionary
• process specification
• entity-relationship diagrams

3
Data Flow Diagram

• "a network representation of a system. The
  system may be automated, manual, or mixed. The
  DFD portrays the system in terms of its component
  pieces, with all interfaces among the components
  indicated."
• - Tom DeMarco
• hence DFDs
• focus on the movement of data between external
  entities and processes, and between processes and
  data stores

4
Example Data Flow Diagram
data store
process
data flow
external entity
5
Data Flow Diagrams are

• Used to perform structured analysis to determine
  logical requirements
• A graphical tool, useful for communicating with
  users, managers, and other IS personnel
• Useful for analyzing existing as well as proposed
  systems
• A relatively simple technique to learn and use

6
Why Conduct Process Modeling?

• Understand components of current logical or
  physical system for purpose of rebuilding in a
  different physical form/technology, possibly with
  some changed functionality
• Find inefficiencies in current system
• Re-engineer current system

7
Sources/Sinks(external entities)

• Any class of people, an organization, or another
  system which exists outside the system you are
  studying.
• Form the boundaries of the system.
• The system and external entities exchange data in
  the form of data flows.
• Must be named, titles preferred to names of
  individuals - use a noun

source/ sink
8
Data Flows

• data in motion
• marks movement of data through the system - a
  pipeline to carry data
• connects the processes, external entities and
  data stores
• Unidirectional
• originate OR end at a process (or both)
• name as specifically as possible - reflect the
  composition of the data - a noun
• do not show control flow! Control flow is easy
  to identify- a signal with only one byte -
  (on/off).
• HINT if you can't name it either it's control
  flow, doesn't exist or you need to get more
  information!

9
Processes

• transform incoming data flows into outgoing data
  flows
• represent with a bubble or rounded square
• name with a strong VERB/OBJECT combination
  examples
• create_exception_report
• validate_input_characters
• calculate_discount

process
10
Data Stores

• data at rest
• represents holding areas for collection of data,
  processes add or retrieve data from these stores
• name using a noun (do not use file)
• only processes are connected to data stores
• show net flow of data between data store and
  process. For instance, when access a DBMS, show
  only the result flow, not the request

data store
11
Data Flow Diagram Donts

• 1. BLACK HOLES
• 2. MIRACLES
• 3. Let it get too COMPLEX 7 2 processes
• 4. Leave things UNLABELED
• (corollary labels should have meaning)
• 5. Data stores that are SOURCES or
• SINKS
• 6. Data flows that are UNASSOCIATED with
• a PROCESS
• 7. Expect your diagram to be perfect the
• first time!

12
Data Flow Diagram Donts
13
Data Flow Diagram Donts
ds-1
A.1
A.2
data
4. Leave Things Unlabeled Corollary Labels
Should Have Meaning
14
Data Flow Diagram Donts
15
Data Flow Diagram Donts
6. Data Flows Unassociated With a Process
entity to entity
data store to entity - or reverse
data store to data store
16
Diagramming A System

• multiple DFDs are required to represent a system
• DFDs are created at increasing levels of detail

17
Different Types of DFDs

• Context diagram
• Level-0 diagram (system diagram)
• Level-n diagram
• Primitive diagram

18
Context Diagram

• defines the scope of the system by identifying
  the system boundary
• contains
• one process (which represents the entire system)
• all sources/sinks (external entities)
• data flows linking the process to the sources and
  sinks (external entities)

19
Example Context Diagram
student
course selections
Registration System
schedule
Registration details
business office
20
Constructing a Context Diagram

• identify and list sources/sinks (external
  entities)
• identify and list inputs to and outputs from
  sources/sinks (external entities)
• create context diagram

21
Level-0 Diagram

• describes the overall processing of the system
• show one process for each major processing step
  or functional requirement
• data flows from the context appear on system
  diagram also (level balancing)
• can show a single data store to represent all
  data in aggregate at this level
• can draw duplicate sources, sinks and data stores
  to increase legibility

22
Drawing a Level-0 Diagram

• list the major data stores
• list major business steps
• draw a segment for each business step
• assemble into single DFD
• re-organize until satisfied
• number processes

23
Functional Decomposition

• similar to a series of more detailed maps
• iterative process of breaking the description of
  a system into finer and finer detail to create a
  set of charts in which one process on a given
  chart is explained in greater detail on another
  chart
• referred to as exploding, partitioning, or
  leveling
• must use your judgment to decide what goes on
  each level
• show error and exception handling on lower levels
  (if at all)

24
Lower Level Diagrams

• explode the processes shown on the level-0
  diagram
• each process is represented by its own DFD
• balance data
• data flows on upper level appear on lower level,
  or
• data flows on upper level are broken into
  component pieces with components shown on lower
  level
• each lower level shows greater and greater detail
• follow numbering convention

25
Balancing DFDs

• conserve data from level to level - inputs and
  outputs on the higher level must appears
  somewhere on the lower level

26
Advanced Rules

• Composite data flow on one level can be split
  into its component data flows on the next level -
  but new data cannot be added and all data in the
  composite must be included in the sub-flows
• The inputs to a process must be sufficient to
  produce the outputs.
• Lowest level DFDs may add new data flows to
  represent exception handling, i.e., error
  messages
• May repeat data stores or sources/sink to avoid
  crossing lines

27
Additional Guidelines

• the inputs to a process are different from the
  outputs of that process
• objects in a set of DFDs have unique names
• do not change data flow names on lower levels
  unless you are decomposing a data flow into
  component pieces.
• never explode a single process into another
  single process. If you cannot partition the
  process, then the lower level DFD is not needed.
• expect to iterate, put down the DFD and go back
  to it a few times to create something
  satisfactory.

28
Other Questions about Lower level diagrams

• 1. How deep? (how many levels?)
• if the process has only one input or one output,
  probably cannot partition further
• can you describe the process in English in about
  1/2 page?
• 2. How broad? (how many processes on a level?)
• 7 two is a reasonable heuristic
• may temporarily place much of the system on a
  single diagram then re-draw into separate levels

29
Quality Guidelines

• Completeness
• all components included in project dictionary
• Consistency
• between levels balancing, leveling
• Timing considerations
• assume system never starts and never stops
• Iterative nature
• revisions are common
• Drawing primitives (lowest level)
• when to stop?