Data Flow Diagram
Data Flow Diagram
Data flow diagram (DFD) is a picture of the movement of data between external entities and the processes and data stores within a system DFDs are an excellent illustration of modeling as the bridge between specification and implementation.
Order Data Payment Invoice Manage Accounts Receivable 5.0 Accounting Data Accounts Receivable Data 4.0 Order Data
D2
Produce Reports
ACCOUNTING
DFD Symbols
Process
Data Flow
Data Store
Process
1.0
Grade Detail
Grade Report
Work or actions performed on data (inside the system) Labels should be verb phrases Receives input data and produces output
Rule 1: Process
Can have more than one outgoing data flow or more than one incoming data flow
1.0
Graded Work
Submitted Work
Student Grade
3.0
Gross Pay
Rule 2: Process
1.0
2.0
Order
Accepted Order
Verify Order Assemble Order
Inventory Change
Process: Correct/Incorrect?
5.0
Services Perfomed
Invoice
Create Invoice
Policy Number
Apply Insurance Premium
Payment Amount
2.1
Hours Worked
Pay Rate
Data Flow
Deposit
Is a path for data to move from one part of the IS to another Arrows depicting movement of data Can represent flow between process and data store by two separate arrows
2.1
Payment Detail Invoice Detail
Post Payment
D1
Accounts Receivable
Courses
Customer Payment
Class List
D2
Daily Payments
Daily Payment
Students
6.0
Prepare Deposit
Data Store
D1 Students
Is used in a DFD to represent data that the system stores Labels should be noun phrases
Must have at least one incoming and one outgoing data flow
Customer Payment
D1
Daily Payments
Daily Payment
1.0
Invoice
Verify Order
External entity that is origin or destination of data (outside the system) Is the singular form of a department, outside organization, other IS, or person Labels should be noun phrases
Source Entity that supplies data to the system Sink Entity that receives data from the system
Rule: Source/Sink
Bank Deposit
2.0
Prepare Deposit
Source/Sink: Correct/Incorrect?
CUSTOMER
PAYROLL DEPARTMENT
CUSTOMER
Payment
Paycheck
Payment
3.0
EMPLOYEE
Apply Payment
Accounts Receivable
YES
NO
A process to another process A process to an external entity A process to a data store An external entity to another external entity An external entity to a data store A data store to another data store
DF1
Level Of Details
Context Diagram
Top-level view of IS Shows the system boundaries, external entities that interact with the system, and major information flows between entities and the system. Example: Order system that a company uses to enter orders and apply payments against a customers balance
Order
CUSTOMER WAREHOUSE
Picking List
Completed Order
Order System
Commission
Bank Deposit
SALES REP
ACCOUNTING
BANK
Level-0 DFD
Shows the systems major processes, data flows, and data stores at a high level of abstraction When the Context Diagram is expanded into DFD level-0, all the connections that flow into and out of process 0 needs to be retained.
Order
CUSTOMER WAREHOUSE
Picking List
Order
system that a company uses to enter orders and apply payments against a customers balance
Commission
Completed Order
Order System
Bank Deposit
SALES REP
ACCOUNTING
BANK
Order
CUSTOMER
Order
Fill Order
system that a company uses to enter orders and apply payments against a customer s balance
Invoice 2.0 Payment Invoice Accounts Receivable Create Invoice Completed Order
D1
Payment Detail
Invoice Detail
3.0
SALES REP
BANK
ACCOUNTING
Levelled Diagram
Lower-Level Diagrams
Functional Decomposition
An
iterative process of breaking a system description down into finer and finer detail Uses a series of increasingly detailed DFDs to describe an IS
Balancing
The
conservation of inputs and outputs to a data flow process when that process is decomposed to a lower level Ensures that the input and output data flows of the parent DFD are maintained on the child DFD
Top-down strategy
Create
the high-level diagrams (Context Diagram), then low-level diagrams (Level-0 diagram), and so on the low-level diagrams, then higherlevel diagrams
Bottom-up strategy
Create
Data stores or external entities are connected directly to each other, in any combination.
Customer D1 Customer
Vendor
D2
Vendor Master
are:
Labels omitted from data flow or objects. Data flow labeled with a verb. Processes labeled with a noun.
The
data flow in and out of a parent process must be present on the child diagram.
Current Physical
There are two types of DFDs Physical and Logical DFDs In the early stages you'll build a current physical DFD. On these you'll be recording, warts and all, the ways things are presently (often known as the "As-is"). It will have all sorts of un-logical things to show and will reflect how things are done currently. There will likely be processes that exist purely because things are done manually. Data stores (such as stick pins or copy orders file etc.) will exists because of how things are
presently done.
Current Physical
shown as External Entities. Clerical and temporary data stores will likely feature heavily What you document on the DFD won't seem to be very logical (I've even found processes that aren't actually needed, but still are done because no one told the staff they were no longer needed!). Dataflow names will likely correspond to document names There are sure to be process to process flows Data flows between external entities will possibly feature
Logical data flow diagrams show how the business operates. They have processes that would exist regardless of the type of system implemented. In the current logical DFD variant, you start with the current physical and remove all aspects that are to do with "how" things are done presently you need to be showing only the "what" aspects.
current physical DFD Create a logical DFD of the current system. Next add all the data and processes not in the current system that must be present in the new system. Finally derive the physical data flow diagram for the new system.
communication with users. More stable systems, since the design is based on a business framework. Increased understanding of the business by analysts. The system will have increased flexibility and be easier to maintain. Elimination of redundancy.
which processes are manual and which are automated. Describing processes in greater detail. Sequencing processes in the order they must be executed.
data stores and transaction files. Specifying actual document and file names. Controls to ensure accuracy and completeness.
Exercise:
Precision Tools sells a line of high-quality woodworking tools. When customers place orders on the companys Web site, the system checks to see if the items are in stock, issues a status message to the customer, and generates a shipping order to the warehouse, which fills the order. When the order is shipped, the customer is billed. The system also produces various reports. Draw a context diagram for the order system Draw DFD diagram 0 for the order system
Status Message
Shipping Order
Invoice
Order System
Shipping Confirmation
Inventory Reports
ACCOUNTING
Entities
Data Flows
Customer Warehouse Accounting 1.0 Check Status 2.0 Issue Status Messages 3.0 Generate Shipping Order 4.0 Manage Accounts Receivable 5.0 Produce Reports D1 Pending Orders D2 Accounts Receivable
Processes
Data Stores
Order In-Stock Request 1.0 Order Data Status Data 2.0 Status Message Shipping Order 3.0 Order Data Invoice Shipping Confirmation 4.0 Payment Accounting Data Accounts Receivable Data 5.0 Order Data Inventory Reports
Order Data Payment Invoice Manage Accounts Receivable 5.0 Accounting Data Accounts Receivable Data 4.0 Order Data
D2
Produce Reports
ACCOUNTING