Moving from Logical to Physical Process Models
Step
FIGURE 10-1
Steps to Create the Physical Data
Flow Diagram
367
Explanation
Add implementation references.
Using the existing logical DFD, add the way in which the
data stores, data flows, and processes will be
implemented to each component.
Draw a human–machine boundary.
Draw a line to separate the automated parts of the system
from the manual parts.
Add system-related data stores,
data flows, and processes.
Add system-related data stores, data flows, and processes
to the model (components that have little to do with the
business process).
Update the data elements in the
data flows.
Update the data flows to include system-related data
elements.
Update the metadata in the
CASE repository.
Update the metadata in the CASE repository to include
physical characteristics.
CASE = computer-aided software engineering; DFD = data flow diagram.
basic difference between the two models is that a physical DFD contains additional
details that describe how the system will be built. There are five steps to perform to
make the transition to the physical DFD (Figure 10-1).
Step 1: Add Implementation References The first step in creating a physical DFD
is to begin with the existing logical DFD and add references to the ways in which
the data stores, data flows, and processes will be implemented. Data stores on
physical DFDs will refer to files and/or database tables; processes, to programs
or human actions; and data flows, to the physical media for the data, such as
paper reports, bar code scanning, input screens, or computer reports. The names
for the various components on the physical DFD should contain references to
these implementation details. By definition, external entities on the DFD are outside of the scope of the system and therefore remain unchanged in the physical
diagram.
Figure 10-2 shows the physical DFD that was drawn to depict the physical
details for the original logical DFD from Figure 5-18. Notice how the logical data
store called Available Tunes that will store data in the Available Tunes table of a
mySQL database has been renamed “mySQL: Available Tunes Table” and the logical data flow Requested Tunes now includes “mySQL: Requested Tunes Record” to
show that this information will be in the form of a record from the Available Tunes
table. Can you identify other changes that were made to the physical model to communicate how other components will be implemented?
Step 2: Draw a Human-Machine Boundary The second step is to add a human–machine
boundary. Physical DFDs differentiate human and computer interaction by a
human-machine boundary, a line drawn on the model to separate human action
from automated processes. For example, the search and browse tunes processes
(i.e., processes 1.1–1.3) require the customer to interact with the Web by using an
interface driven by system programs and processes. The physical model, therefore,
contains a line separating the customer from the rest of the process to show exactly
what is done by a person as opposed to a “machine.” (See Figure 10-2.)
368
Chapter 10 Program Design
1.1
Web Site
Access URL
Load
Web Site
HTML: Customized
Web Content
HTML/PHP
MySQL Record:
Web Promotions
D3
MySQL: Targeted
Promotions Table
MySQL Record:
Customer
Favorites
D2
MySQL: Customer
Favorites Table
MySQL Record:
Requested
Tunes
D1
MySQL: Available
Tunes Table
D4
MySQL: Customer
Interest Table
Step 2
1.2
Search Request
Input Form
Matching
Tunes Report
Customer
Process
Search
Requests
HTML/PHP
.mp3/.wmv file:
Tune Sample
1.3
Selection
Form
Process
Tune
Selection
.mp3/.wmv file:
Tune Sample
MySQL Record:
New Interest
MySQL record:
New Favorite
HTML/PHP
MySQL Record:
Tune to Buy
D7
MySQL: Shopping
Cart Table
ASCII Record:
Tune to Buy
D8
ASCII: Tune to
Buy History File
Step 3
FIGURE 10-2
Physical DFD for Tune Source Process 1: Search and Browse Tunes (the How)
Every part of every process in the system may not be automated, so it is up to
the project team to determine where to draw a human-machine boundary and how
large to draw it. The project team will need to weigh the following criteria when
drawing the boundary: cost, efficiency, and integrity. First, a piece of the system
should be automated only if the cost of computerizing it is less than doing it manually. Next, the system should be more efficient with the mode that is selected. For
example, if the project team must decide whether to store a paper copy of a document or to save an electronic file of information in a central file server, the team
likely will find the latter option to be more efficient in terms of improving the users’
ability to access and update the information.
Finally, the team should consider the integrity of the information that is handled by the system. It may be cheaper for a clerk to record orders by phone and
deliver the order forms to the distribution area; however, errors could be made when
the clerk takes the order, and a form could be misplaced en route to distribution.
Instead, the project team may be more comfortable with an automated process that
accepts a customer’s order from the customer directly, using a Web form that is then
directly transmitted to the distribution system.