DFD

= Data Flow Diagram

- A graphical representation of a system or a portion of a system in the form of a

diagram illustrating external sources, flows, processes and data stores
- Data flow: ‘data in motion, moving from one place to another. A data flow could
represent data on a customer order form or a payroll check’ Hoffer et al (2002)
- DFDs describe an entire system from the viewpoint of the data that is processed by
the system
- Using DFDs
o We can identify the main processes and activities (subsystems)
o We can decompose each subsystem into constituent subsystems or
processes until we have a complete set of diagrams for the system which
cannot be decomposed further
o This set of non-decomposable diagrams is a model of the system

- Two types of DFDs:

o Physical Data Flow Diagrams
o Implementation-depended
o They show actual devices, departments, people, etc involved in the
system
o Logical Data Flow Diagrams
o Implementation-independed
o They show what takes place rather than how an activity is
accomplished
- WHAT the system does → Current Physical DFD
HOW it does it → Current Logical DFD
WHAT it should do → Required Logical DFD
HOW it should do it → Required Physical DFD
- Both DFD types support a top-down approach
o Analysts begin by developing a general understanding of the system
o And gradually explode components in greater detail
- A DFD models the process and functional view of a system
- DFDs depict information flow and the transformations that are applied as data move
from input to output
- DFDs include
o The processes themselves (the activities or functions of the system)
o The information or data flowing into, our and within the system
o The way information is stored in the system

Data flow diagram key

1
Source die geeft iets, de bron van iets
Sink is waar je iets laat toekomen
Cirkel = een entiteit

Data flow → gaat aangeven welke informatie door systeem vloeit

Voorbeeld Slide 9
Passenger: entiteit geeft iets en komt terecht in proces
→ geeft zowel informatie door als ontvangt
Data process → geeft informatie door aan data store

Data Flow Diagrams

- DFDs consist of 4 basic elements:

o Data flow
o Data store
o Process
o Source / sink
- We can also use
o A note (for convenience)
o A resource flow (for convenience)
o A process specification

Symbols used in DFDs

Processing step (process)

o Represents an activity that processes / transforms data (a set of activities
transforming input data to output data)
o The process plays a significant role in the business process
o Labeling processes is used to develop levels of DFDs that describe
increasingly detailed levels of a process
o Each process has an unique ID
o Diagram does not show who is performing a process
o If a process exists on a diagram it does not mean that it is always performed

2
Naming conventions:
o Verbal noun + object: preparing an invoice, accepting articles, calculating
monthly salaries, checking warehouse state
o Imperative verb + object: prepare invoice, accept articles, calculate monthly
salaries for a month, check warehouse state

Data flow
o Represents the flow of data / information from an External Entity, Process or
Data Store to an External Entity, Process or Data Store
o The name reflects the nature of the data / information used
o Does not show how data / information flows but rather which data /
information flows
o Use lower case

Data store
o A collection of data needed by the business process
o It is not the same as a database
o Types: file on a disk, table in a database, paper files, sheet of paper, book,
folder with files, other
o In data store we store data about a single object type
o Some Data Stores may only be temporary - that is, they exist only for as long
as the process needs them

Naming conventions:
o Noun in singular: client, invoice, commodity, student, group, employee, …
o Noun in plural: clients, invoices, commodities, students, groups, employees, …

3
Source or sink
o A source represents a “data source” outside the boundary of the process that
the DFD is modelling
o A sink is any destination for data that is outside the boundary of the process
that the DFD is modelling
o Is something or somebody (person, department, organization, another system)
being outside the system
o Is a sender or recipent of data
o Also called external entities
o Usually we do not know their behaviour – we do not need it
o What happens to the data - either before entering or after leaving the system -
is immaterial
o In DFD never use names for persons

Naming conventions:
o Noun in singular [capitals]: client, sales department, manager, supplier,
treasury office, bank, accountancy system, orders system

Resource flow
o Shows the flow of any physical material from its source to its destination
o Often called the physical flows
o Resource flows are usually restricted to early, high-level diagrams and are
used when a description of the physical flow of materials is considered to be
important to help the analysis
o [dubbele pijl]
o Alles wat echt fysisch is

4
Notes
o Are used to add a description on the diagram for an object
o Connect a note to any object using a note link

Complex DFDs

Decomposing Data Flow Diagrams

- Complex systems require a complete set of DFDs to describe all information flows
and processes
o Mulitlevel DFD
o Hierarchical structure
o Consists of a set of related diagrams
o Model levels:
o Context diagram
o First level diagram → hoofdprocessen tekenen
o Second level diagram
- The amount of processes in one diagram is limited to 10 (guideline: 7)

- Level 0 / Context Diagram

5
 o Shows the boundries for a system – context
o Contains:
o 1 process
o All external entities
o No data stores
Hier zijn de dataflows heel algemeen (voorbeeld)

- Level 1 contains:
o All external entities from the higher level
o All incoming flows of the higher level (and more)
o Data stores
o Some processes (numbered 1, 2, 3, ..., n)
→ Shows how the single process from context diagram is decomposed to detailed
processes – process decomposition

- Level N + 1
o All terminators from the higher level

6
 o All incoming and outgoing flows of the higher level
o Additional data stores when necessary
o More detailed processes (numbered N.1, N.2, N.3, …, N.n)

- Level 2 for process A

Guidelines For Drawing DFDs

- Identify input and output of the system (mostly information on documents) together
with their sources and recipients
- Identify the main processes which need input and produce output
- Draw the data flows and external entities, defined above, round the outside of the
page
- For each data flow on the diagram, identify and draw any associated data store with
their data flows
- Look for any intermediate processes. Add data flows and data stores, required by
those processes
- Check the diagram for consistency and completeness

Rules for Drawing DFDs

- Each process should have both input and output

- Each data store probably has both input and output
- Data flows cannot flow between data stores
- Data flows cannot flow between entities and data stores
- Diagrams must be balanced across levels
- A data flow cannot be output and input of the same process

7
- Flows connected with a process with opposite directions should not have the same
name (data not processed?)
- Data flows should not cross one another

- Data flows should not cross one another

→ Oplossen door een 'brug' te tekenen

- Each diagram has a name (title)

- Each object has a name
- Unique names for: processes, terminators, data stores
- Name of each object should precisely reflect its features
- Names of object usually do not point to specific occurrences of objects

Process specification

8
Example: The Sailboat Rental Company

- In the following example, a DFD will be created based on a few paragraphs about a
sailboat rental company’s method of renting boats.
- In this example, the information necessary to create the DFD is provided for us. In
Real Life, this information comes from extensive interviewing, document gathering,
and other research.
- Depending upon the system being studied, the number of people working on it, etc.,
the development of a detailed DFD can take anywhere from a few hours to several
months
- For each sailboat, a filing card is made up with technical information, the state of
the boat and the required level of ability to be safely sailed
- Each customer has his own filing card with his address, his unique customerID and
his skill level to sail boats
- To rent a boat customers give their customerID and the boatID of the desired boat
- The system checks that the boat is free and that the customer has the correct skill
level.
- A rental contract is signed by the customer
- The rental fee of the boat is paid immediately
- Before sailing out the customer gets a document with the state of the boat
- When the boat is brought back, the state of the boat is checked again. If necessary
the customer gets a damage report and an invoice to pay the damage
- If the invoice is not paid within one month, a reminder is sent
- The SRC management wants each quarter an overview of the number of times a
customer has rented a boat, the number of times each boat has been rented

- Customer gives:
o Customer details
o CustomerID-BoatID
o Rental free
o Damage report
- Management receives:
o Mangement reports
- Customer receives:
o CustomerID
o State of boat information / document state of boat
o Damage report information / damage report
o Payment information (data flow) / invoice (resource)

- Processes
o 1.0: Record Customer Info
o 2.0: Record Rent
o 3.0: Finish Rent
o 4.0: Check Invoices
o 5.0: Report Management
- Data stores
o Boat cards
o Customer cards
o Invoices

9
 o Contracts

Customer and manager zover mogelijk uit elkaar tekenen

→ Level 0 / context

10
Processen erbij tekenen
→ Level 1

Datastores tekenen
→ Level 2

Nummering van levels hebben niet altijd noodzakelijk een logische volgorde

What DFDs Do Not Do

- DFDs do not handle sequence

11
 o There is no notion of time in DFD
o It cannot be infered that process 2 always folows process 1
- DFDs do not handle priorities
o In a situation where 2 processes want to read from the same file at the same
time, which one wins? DFDs do not adress the problem
- DFDs do not define the structure of the data
o The structure of the data in the data stores is glossed over in DFDs and any
structure of the data in data flows is similarly ignored in DFDs
o The structure of the data is left of the data view of the system

Some common mistakes

Shortcomings of Process-Based Methods

- The focus of the developers was to understand the users' business and produce the
reports and screens they needed to see. DFDs are a great help in doing this
- What was less urgent, but in the long run more important, is the ability to make
changes to the system when the users' needs change. There is no such thing as a
stable business
- A simple change in the output is likely to cause a cascade of changes to all parts of
the program or system

Exercises

12
- What are the components of a DFD?
- What is wrong with the following process?

- What is wrong with the following process?

- What is wrong with the following DFDs?

- Is the DFD correct? What does it mean?

13
- Which DFDs are correct? Explain your answer

- What is wrong with the following DFD?

→ Antwoorden zelf op toledo zetten, zij antwoordt daar dan op (worden niet
rechtstreeks gegeven)

- What is the meaning of an unnamed data flow flowing in or out a data store?
- What kind of mistake do users sometimes make with interpreting the process
numbers?
- Suppose someone labels a process with the name of the person which executes
the process at this moment. Why is this an incorrect label?
- Is it necessary to partition all processes in a certain level in exactly the same
sublevels?

- Travelling salespersons try to sell vacuum cleaners from door to door

Whenever they sell one, they immediately receive the price in cash (€75)
They deposit the full amount on the firm’s bank account
At the end of each month the firm pays out a 25% commission
Draw a DFD

- An industrial firm issues a call for tender to several different IT companies

The firm wants to automate the accountancy department
Immediately after receiving a tender, confirmation of reception is sent
The cheapest bidder may deliver the system, the others receive a polite refusal
Payment takes place after delivering and acceptance testing
Draw a DFD

Process specification

14
- Complex DFDs are decomposed until the process cannot be decomposed further
- These processes are tasks that have to be implemented
o DFD modeling results in specifications for program units
- With process specification, we can formally describe (and define) the low level units
which make up the target system
o The notation used must be able to describe the step-by-step flow and logic
within the process
o The formal definition of the process / unit is usually in a format which is easily
(and often mechanically) translatable into program code
o Thus we can specify the (typically) small pieces of code, or units, which will
eventually be linked together to form the programs which will be the software
of the target system

- A DFD process tells us WHAT the process (activity) is (by its name in the box)
- The process description will deal with the HOW

15
- Pseudocode

- Pseudocode can include sequences, selections, and iterations

- Decision Trees and Decision Tables provide help with the selections and
appropriate actions

16
- Alternative format for a decision tree

- Decision tables
o 5 decisions → 25 rules = 32 rules

- Decision tables (rationalized)

17
18