DFD Example

Developing DFDs: An Example

To illustrate how DFDs are used to model the logic of data flows in information systems, we will present and work through an example.

Consider Hoosier Burger, a fictional restaurant in Bloomington, Indiana, owned by Bob and Thelma Mellankamp. Some are convinced that its hamburgers are the best in Bloomington, maybe even in Southern Indiana. Many people, especially Indiana University students and faculty, frequently eat at Hoosier Burger. The restaurant uses an information system that takes customer orders, sends the orders to the kitchen, monitors goods sold and inventory, and generates reports for management.

The information system is depicted as a data flow diagram in Figure 7-4.

• The highest-level view of this system, shown in the figure, is called a context diagram.
• This context diagram contains only one process, no data stores, four data flows, and three sources/sinks.
• The single PROCESS, labeled 0, represents the entire system; all context diagrams have only one process, labeled 0.
• The SOURCES/SINKS represent the environmental boundaries of the system.
• Because the DATA STORES of the system are conceptually inside the one PROCESS, DATA STORES do not appear on a context diagram.

The analyst must determine which processes are represented by the single process in the context diagram.

As you can see in Figure 7-5, we have identified FOUR separate PROCESSES.

• The main PROCESSES represent the major functions of the system, and these major functions correspond to actions such as the following:

1. Capturing data from different sources (e.g., Process 1.0)

2. Maintaining data stores (e.g., Process 2.0 and 3.0)

3. Producing and distributing data to different sinks (e.g., Process 4.0)

4. High-level description of data transformation operations (e.g., Process 1.0)

• These major functions often correspond to the activities on the main system menu.

We see that the system begins with an order from customer, as was the case with the context diagram.

• In the first process, labeled 1.0, we see that the customer order is processed.
• The result is four STREAMS, or FLOWS of data:

1. the food order is transmitted to the kitchen

2. the customer order is transformed into a list of goods sold

3. the customer order is transformed into inventory data

4. the process generated a receipt for the customer.

• The SOURCES/SINKS are the same in the context diagram and in this diagram: the customer, the kitchen, and the restaurant’s manager.

This diagram is called a level-0 diagram[2]

. Each PROCESS has a number that ends in .0 (corresponding to the level number of the DFD).

Two of the data flows generated by the first process, Receive and Transform Customer Food Order, go to external entities, so we need no longer to worry about them.

• We are not concerned about what happens outside of our system.

Let’s trace the flow of the data presented in the other two data flows.

• First, the data labeled Goods Sold go to PROCESS 2.0, Update Goods Sold File.
• The output for this PROCESS is labeled Formatted Goods Sold Data.
• This output updates a DATA STORE labeled Goods Sold File.

• If the customer order was for TWO cheeseburgers, ONE order of fries, and a large soft drink, each of these categories of goods sold in the data store would be incremented appropriately.
• The Daily Goods Sold Amounts are then used as input to PROCESS 4.0, Produce Management Reports.

• Similarly, the remaining data flow generated by PROCESS 1.0, Inventory Data, serves as input for PROCESS 3.0, Update Inventory File.
• This process updates the Inventory File data store, based on the inventory that would have been used to create the customer order.

• For example, an order of TWO cheeseburgers would mean that Hoosier Burger now has two fewer hamburger patties, two fewer burger buns, and four fewer slices of American cheese.
• The Daily Inventory Depletion Amounts are then used as input to PROCESS 4.0.
• The data flow leaving PROCESS 4.0, Management Reports, goes to the sink Restaurant Manager.

Figure 7-5 illustrates several important concepts about information movement.

1. Consider the data flow Inventory Data moving from PROCESS 1.0 to PROCESS 3.0.

§ We know form this diagram that PROCESS 1.0 produces this data flow that PROCESS 3.0 receives it.

§ However, we do not know the timing of when this data flow is produced, how frequently it is produced, or what volume of data is sent.

§ Thus, this DFD hides many physical characteristics of the system it describes.

§ We do know, however, that this data flow is needed by PROCESS3.0 and that PROCESS 1.0 provides these needed data.

2. Also implied by the Inventory Data data flow is that whenever PROCESS 1.0 produces this flow, PROCESS 3.0 must be ready to accept it.

3. In contrast, consider the link between PROCESS 2.0 and PROCESS 4.0.

§ The output from PROCESS 2.0, Formatted Goods Sold Data, is placed in a data store and, later when PROCESS 4.0 needs such data; it reads Daily Goods Sold Amounts from this data store.

§ In this case, PROCESS 2.0 and 4.0 are decoupled by placing a buffer, a data store, between them.

§ Now, each of these processes can work at their own pace, and PROCESS 4.0 does not have to be ready to accept input at any time.

§ Further, the Goods Sold File becomes a data resource that other processes could potentially draw upon for data.

---

[1] An overview of an organizational system that shows the system boundaries, external entities that interact with the system, and the major information flows between the entities and the system.

[2] A data flow diagram that represents a system’s major processes, data flows, and data stores at a high level of detail.