How do we begin to construct Data Flow Diagrams (DFDs)?
Hope you have read our previous articles on Concept of Data Flow Diagrams and Symbols used in Data Flow Diagrams before starting to construct Data Flow Diagrams.
So here is a top-down process you need to follow to draw DFD in a easy way:
- Draw a bubble/circle to represent the process you are about to define.
- Ask yourself what thing(s) initiate the process: what is coming in? You will find it advantageous to be consistent in where you show process inputs. Try to model them to the left of the process. You will later be able to immediately define your process inputs when looking back at your DFD, especially when using them for system enhancements.
- Determine the process outputs, or what things are coming out, and model them to the right of the process as best you can.
- Establish all files, forms or other components that the process needs to complete its transformation. These are usually data stores that are utilized during processing. Model these items either above or below the process.
- Name and number the process by its result. For example, if a process produces invoices, label it “Create Invoices.” If the process accomplishes more than one event, label it by using the “and” conjunction. This method will allow you to determine whether the process is a functional primitive. Ultimately, the name of the process should be one that most closely associates the DFD with what the user does. Therefore, name it what the user calls it! The number of the process simply allows the analyst to identify it to the system and most important to establish the link to its children levels during functional decomposition.
Let us now apply this procedure to the example below:
Vendors send Mary invoices for payment. Mary stamps on the invoice the date received and matches the invoice with the original purchase order request. Invoices are placed in the Accounts Payable folder. Invoices that exceed thirty days are paid by check in two-week intervals
Step 1: Draw the bubble
A process bubble used in Data Flow Diagram
Figure 1: A process bubble.
Step 2: Determine the inputs
In this example we are receiving an invoice from a Vendor. The Vendor is considered a Terminator since it is a boundary of the input and the user cannot control when and how the invoice will arrive. The invoice itself is represented as a data flow coming from the Vendor terminator into the process as shown in Figure 2:
Vendor invoice (as entity) to process to DFD
Figure 2: Terminator sending invoice to the process.
Step 3: Determine the outputs of the process
In this case the output of the process is that the Vendor receives a check for payment as shown in Figure 3:
DFD with output to the Vendor through Process
Figure 3: DFD with output of check sent to vendor
Step 4: Determine the “processing” items required to complete the process
In this example, the user needs to:
- match the invoice to the original purchase order;
- create a new account payable for the invoice in a file; and
- Eventually retrieve the invoice from the Accounts Payable file for payment.
Note that in Figure 4 the Purchase Order file is accessed for input (or retrieval) and therefore is modeled with the arrow coming into the process.
The Accounts Payable file, on the other hand, shows a two-sided arrow because entries are created (inserted) and retrieved (read). In addition, arrows to and from data stores may or may not contain data flow names. For reasons that will be explained later in the chapter, the inclusion of such names is not recommended.
DFD with interfaceing data store
Figure 4: DFD with interfacing data stores.
Step 5: Name and number the process based on its output or its user definition.
Final named DFD
Figure 5: Final named DFD.
The process in Figure 5 is now a complete DFD that describes the event of the user. You may notice that the procedures for stamping the invoice with the receipt date and the specifics of retrieving purchase orders and accounts payable information are not explained. These other components will be defined using other modeling tools. Once again, the DFD reflects only data flow and boundary information of a process.
The DFD in Figure 5 can be leveled further to its functional primitive. The conjunction in the name of the process can sometimes help analysts to discover that there is actually more than one process within the event they are modeling.
Based on the procedure, the event really consists of two processes: Recording Vendor Invoices and Paying Vendor Invoices. Therefore, P1 can be leveled as shown in Figure 6.
Leveled DFD for Record and Pay Invoices process
Figure 6: Leveled DFD for Record and Pay Invoices process.
So, by this time I hope you are able to design DFD by using symbols used in DFD