Process Modeling With Physical Data Flow Diagram

Modeling a System

As system analyst, you constantly deal with unstructured problems. Analysis---at least good analysis---imposes structure on an unstructured problem. One way to understand a problem is to use models. Model
A model is a graphic representation of a system, to define requirements and designs. Most analysts draw physical models without even thinking about it. Physical Model Physical model (also called implementation models) show not only what a system is or does, but also how the system is physically implemented. This is especially useful when verifying models with end-user. As computer systems analysts, we may ultimately implement processes as programs, we need process models. Process Model A process model is a picture of the flow of data through a system and the processing performed on that data. These pictures are often easier to read than prose. Process modeling helps us grasp inputs, outputs, processing, and the relationships between processes. The term process modeling comes from the depiction of processes and how they interact or interface with one another. These interactions take the form of data flows between processes. For this reason, process models are also frequently called data flow models. Process modeling is very popular technique. The most popular process-modeling tool is the data flow diagram. This tools popularity is an outgrowth of a systems analysis methodology called Structured System Analysis and Design.

Data Flow Diagram Conventions And Guidelines

Data Flow diagram

A data flow diagram illustrates the flow of data through a system and the work---or processing---performed by that system. Physical DFDs show how the system is currently implemented. Physical Data Flow Diagram Language and Symbols Physical DFDs are quite easy to read and understand. There are two alternatives, but equivalent, symbol set. Both figures demonstrate the visual language of physical DFDs. The Gane-Sarson and DeMarco-Yourdon symbols are also reproduced below, respectively. Process or Activities A process sometime called activity is represented by a rounded rectangle (GaneSarson) or a circle, also called a bubble or a transform (DeMarco-Yourdon). Processes transform inputs into outputs. The details of the processing--- the logic or procedure--- are not shown. Processes on physical DFDs can represent activities performed by people, computers, or machines.

Process Description

Process Descriptio n

Gane-Sarsons Symbols
Internal or External Entities

DeMarco-Yourdons Symbols

The square (Gane-Sarson) or rectangle (DeMarco-Yourdon) depicts internal or external entities. These entities define the boundary of the system. They provide the net inputs to, and receive the net outputs from, the system. Internal/ external entity name Internal/ external entity name

Gane-Sarsons Symbols

DeMarco-Yourdons Symbols

Data Stores

Data stores are depicted as open-ended boxes. e.g. Physical examples of data stores include file cabinets, desk drawers, binder and books of data or reports, index card, in/out boxes, mail-boxes logs, and of course computer files and databases Data store name Data store name

Gane-Sarsons Symbols
Data Flows:

DeMarco-Yourdons Symbols

The named arrows depict data flows. Data flows represent inputs or outputs such as reports, forms documents, terminal displays, computer-to-computer data transmissions, letters and memos, data retrievals, file updates, phones calls, and other conversations.
Difference between DFD & Flowchart: DFD:

DFD stands for Data Flow Diagram. It refers to the step-by-step process of manipulation on data. Processes on a DFD can operate in parallel. Several processes may be working simultaneously.

Example: You may be balancing your check-book at the same time as your spouse is paying the bills. This is a key advantage over flowcharts, which tend to show only sequences of processes. In a realistic system, activities and processing overlap with one another. DFDs show the flow of data through a system. DFDs, unlike flowcharts, do not explicitly show looping and decision (if-thenelse) constructs. DFDs can shows processes that have dramatically different timing. Example: You make many deposits and withdrawals to your bank account before you balance your account.
Flowchart:

Processes on a Flowchart operate only in sequence. In a Flowchart processes cannot work simultaneously. Flowcharts show the sequence of steps in an algorithm. Flowcharts explicitly show looping and decision (if-then-else) constructs.

Mail: payment Creditors Mail: Bill 1 You Spouse: Pay bill Bank statement

Check

Withdrawal entry

computer listings: Balanced Statement

Computer listing: Previous statement

4 Check register(checkbook) Checkbook: Log entries withdrawal entry Deposit entry 3 You or Spouse Withdraw cash Mail: Bank statement and canceled checks You or spouse; balance checkbook account

4 Employee Paycheck You or spouse Deposit money into bank Deposit slip

Cash receipt deposit

Any other Source of income

Other income

Bank

Figure(a) :

Mail: Payment Creditors Mail: Bill 1 You or spouse Pay bill Bank statement Check Computer listings: balanced statement Withdrawal entry 4 You or spouse: balance checkbook account

Computer listings: Previous statement

Check register(checkbook)

Checkbook: Log entry

withdrawal entries

Deposit entry 3 You or spouse: Withdraw cash Cash receipt deposit Employee Paycheck 2 You or spouse: Deposit money into bank Mail: Bank statement and canceled Deposit slip

Any other source of income

Other income

Bank

Figure(b)

Simple Physical Data Flow Diagram: This is a simple physical data flow diagram for a personal finance system. It uses the Gane-Sarson symbol set, which is equivalent to the alternate symbols use in Figure (b). Figure(b) Simple Physical Data Flow Diagram: This is a simple physical data flow diagram for a personal finance system. It uses the DeMarco-Yourdon symbol set, which is equivalent to the alternate symbols use in Figure(a).
Detailed Explanation of DFD symbols And Convention:

The Internal or External Entity: Every system has a boundary. The first decision to be made in any project is to define the scope, sometimes called the context, of the system. Internal and external entities define the systems boundaries. These entities are sometimes called Sources 1- Of data 2- The net inputs to the system OR Destination 1- Of information, 2- The net outputs from the system. Internal and external entities are people organizations, and other systems with which your system interacts. Internal Entities: An office, document, or division, or similar organization unit within a company that, while not directly using the system, either provides inputs to the system or receives outputs from the system. These are internal entities. External Entities: Organization, agencies, or individuals that are outside your company but that provide inputs to or receive outputs from your system. These are external entities. Examples include customers, suppliers, government agencies, subcontractors, banks, consultants or consulting agencies, and the like. Another System: Another system---possibly, though not necessarily, computer-based----that is separate from your system but with which your system must interact. Thus, if your system must access files or outputs from another system, especially files and outputs whose contents and structure cannot be changed--- a very common constraintthen that other system and its files should appear in your physical DFDs as an external entity. Other systems may be either internal to your company. One of your own systems end-user or managers: In this case the end-user or manager is a source of an input(s) to or an output(s) from the system. This type of internal entity is common to most information systems projects. Most systems produce reports. Some of those reports, called external outputs, leave the system to go to people departments, and organizations other than your end-users. But other outputs, called internal outputs, are

produced specially for your own end-users and managers. These reports would be used for internal control. Labeling the external and internal entities: Label should be descriptive. If the entity represents a person, use the persons life. Names can be used; however titles are better since people frequently change position. If the entity represents a system, label it <name>system. Internal/ external entity name Duplicate entities: To avoid crossing data flow on a DFD, it is permissible to duplicate internal and external entities on DFDs. If internal or external entities are duplicated on or between pages of DFDs, put a line across the lower right corner of the symbol. This mark alerts the reader to expect additional occurrences of this same entity on the same page or other pages. The data flow Data flow are used to demonstrate: Addition to, Deletions from, Modifications to, and Data retrievals from the data stores. Remember! Data flows must be inputs to or outputs from processes. In any case, the key to defining a data flow is known composition. Occurrences of the data flow must contain data. Rules to label a data flow: 1. Label or name all data flow as noun clauses. If you cant name the data flow, it probably doesnt exist. For example, look at the figure below. What should we name the data flow in question? How about Get NEXT REQUISTION? That wont work. Why? Because GET NEXT REQUISTION is a verb clause---it describes a step, not data.
Production Shop floor Form 240X: Material Requisition

Warehouse Ticket to claim materials Check for Material availability

???????

INCORRECT

2. Try to describe the data elements that make up the data flow. If you cant name or describe those elements, then the data flow doesnt exist. e.g. REQUISITION , NUMBER , DATA , MATERIAL , TEQUESTED, and QUANTITY. Name should be meaningful: Physical data flow names should be descriptive and meaningful to your end-user, who will have to verify your understanding of the current system. Names should include any acronyms and from number that will help the end-users immediately recognize that data flow in the model. State of flow: In addition to focusing on nouns, data flow names should contain appropriate adjectives and adverbs to describe the status of flows as they move through system processes. Data should flow together: A data flow is described as a packet of data. The packet concept is critical. Data that should travel together should be shown as a single data flow, no matter how many documents ate physically involved. For example: Suppose the phone company sends you an itemized INVOICE of your monthly charges along with a PAYMENT CARD that must be returned with your PAYMENT. The INVOICE and PAYMENT CARD should be deposited as one data flow, not two. The PAYMENT CARD and PAYMENT are similarly shown as one data flow.

Phone company Mail: Invoice and Payment card Mail Invoice Mail Payment card Incorrect way to Show packets Correct way show packets

5
Pay phone bill

Payment card and payment

Data flow must begin and end at a process: Finally, all data flows must begin and/or end at a process, because data flows either initiate a process or result from a process!

Consequently, all of the data flows depicted on the left side of Figure below are illegal. The corrected flows are shown on the right side.

Figure(a) Common Mechanical Error: All data flows must begin and/or end at a process. All of the examples on the left side violate this rule. The key correction are shown on the right side of the figure(a). The process: Processes are work or actions that are performed by people, machines, or computers on incoming data flow to produce outgoing data flows. Processes can be performed by people, department, robots, machines, or computers (specifically, computer programs). The following naming conventions address the essence of the process. Naming a process: Process names depend on the level of detail you are trying to depict on the DFD. Some processes represent the entire system, one subsystem, or one function. Other processes represent detailed tasks. It depends on whether the physical DFD is depicting the big picture or a small portion of the total system. Process names should be chosen accordingly. Process names on the general DFDs will, of necessity, be equally general. Examples of general process names are listed bellow. Accounts Receivable System, Billing Subsystem, Credit Function. On the other hand, the processes on the detailed DFDs should be given more specific names consisting of a strong action verb followed by an object clause that describes what the work is performed on or for. Process names on physical DFDs should identify the processor: person(s), location(s), machine(s), or computer program(s). Include process that do nothing but rout data:

For physical DFDs, you also include processes that do nothing more that route data flows to their nest destination. Some processes may occur every time and some may occur optionally: A process can have many incoming and outgoing data flows. Some may occur every time the process is executed. Others may occur optionally, under certain conditions. The DFD does not show which data flows are mandatory and desirable or in what combinations they occur. These details are deferred until the policies and procedures for the processes have been specified. On the other hand, all processes must avoid the following errors, demonstrated in Figure below.
Employee Mail: End-of-month bank statements Form: Credit union membership application

3
Clerk: Generate employee bank statements Employee Account ID And address

1
Assistant manager: Create new member account Employee standing

Existing accounts

Member account (file cabinet)

Employee (file cabinet)

Modified account status (frozen)

2
Assistant Manager: Freeze Member account

Letter Member account frozen notification

Accounts receivable department

Common DFD Error: Process 1 has inputs but produces no outputs. This called a black hole. Process 2 produce outputs but receive no inputs. This is called the miracle. Process 3 has inputs and outputs; however, the inputs are not sufficient to produce the outputs. What is wrong with Process 1? The process has inputs but no outputs. We call this a black hole because data enters the process and disappears. If you identify a black hole, you probably just forgot the output. What is wrong with Process 2? The process has outputs but no inputs. Unless you are Merlin the Magician, this is miracle! In this case, the input data flows were likely forgotten. What is wrong with Process 3? The process is what we call a gray hole. The inputs to the process are insufficient to produce the output. Test Point: The inputs for any given process must contain all the data necessary to produce the outputs. This is the final test of any DFD. The data store: Data stores are inventories of data. As data is inputs, it is frequently stored for later use. Data stores are the memory of the system. Any place that data accumulates is a data store. Instructions: The term data should not be part of the name because it is implicit that a data store stores data. Additionally, names should imply both content and implementation media. For example, ORDER (IN/OUT BOX) refers to stored order forms that are awaiting processing. Name may also include appropriate adjectives or clauses to better describe the data store. Adjective can be used to distinguish between similar but distinct stores of subsets of data (for instance, PENDING ORDERS versus CLOSED, or CLOSED ORDER, or MAMBERS versus PAST MAMBERS). Avoid crossing: To avoid crossing data flow lines on a DFD, it is permissible to duplicate data stores. If data stores are duplicated on or between pages of DFDs, they should all be marked as indicated in the margin. This mark tells reader that can expect additional occurrences of this same data store on the same page or other pages. 1. Only processes may connect to data stores. Computerized data may interact with computerized data and vice versa. 2. Double-ended arrows: Double-ended arrows for data flows are discouraged on detailed DFDs. Data flow direction is interpreted as follows. a. Process uses the data: A data flow from a data store means that the process uses (not reads) that data. Name the flow to reflect the portion of the data required by the process.

b. Process updates the data: A data flow to a data store means that the process updates the data store. Updates may include any or all of the following: a. Adding or storing new records or form---for instance, adding a new customer to the CUSTOMERS data store---or adding a new entry to a log. b. Deleting or removing old records or forms---for instance, deleting inactive customers from a store. c. Changing existing records or forms---for instance, changing the credit rating, address, or balance of an existing customer. 3. Modify and delete: In computer programs, read and writes to files occur in pairs. You cant modify a record without first reading it. You cant delete a record without first locating it. 4. Separate data flow: some processes both use and update data stores. The key word is use. For example, calculation or decisions might be necessary before you update the stores. If so, as a general rule, use separate data flows for the use and the update.
Form: Order Form 50: Released order

Crack Place order

Form 50: New order Form 50: Order

Sales mgr: Respond to Bid on order

Order details

Order (in/out box)

Order details Updated order

Clerk: Modify Unfilled order Phone/mail: Order modification

Manager: Summarize Sales by Region and budget Order summary analysis report

Figure(a)

Figure(a)The signification of data flows to and from data stores: Be careful with data flows to and from data stores. The direction of the arrow may signify use of data, creation of data, deletion of data, or modification of data. Read the guidelines carefully to make sure you know the difference. DFDs should never show the reading of data for their own sake! Levels of DFD: There are three levels of DFDs. These are followings. Level 0: In this level we usually focus to show only the entire system process with the system name (only a single process) with the external interactions (input/output arrows) which is also known as source and destination etc. Here the system is black box to the viewers. Level 1: In this level we usually focus to show major processes in the system, with the particular related interactions (input/output arrows) to these processes. Here the system is white box to the designers a little bit. Level 2: In this level we show the sub processes of each process of our system. With the particular related interactions (input/output arrows) to these sub-processes as well. Here the system is complete white box to the designers.

1.1

1.2

1.3

1.2.1

1.2.2

1.2.3

The diagram illustrates how levels of DFDs are built up.

Example: Data flow diagram The example used here is the SafeHome software. SafeHome software enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through a keypad and function keys contained in the SafeHouse control panel shown bellow.

Control Panel

User command and data

display information

Control Panel display

SafeHome software

alarm type Alarm

sensor status Sensors

telephone number tones Telephone line

Level 0: Context-level DFD for SafeHome. Level 0: A Level 0 DFD for the system is shone above. The primary external entities (boxes) produce information for use by the system and consume information generated by the system. The label arrows represent data objects or data object type hierarchies. For example, user commands and data encompasses all configuration commands, all activation/deactivation commands, all miscellaneous interactions, and all data that are input to qualify or expand a command. Level 1: The level 0 is now expanded into Level 1 model. The context-Level process has been expanded into seven processes derived from an examination of the grammatical parse. Similarly, the information flow between processes at level 1 has been derived from the parse. It should be noted the information flow continuity is maintained between levels 0 and 1.

Control panel

User commands And data Configur e system

Configure Request

configuration data

Interact with user

Configuration information start stop configuration data

password

activatio n / deactivat ion system

a/d msg.

Process Passwor d

Valid id msg. Configuration Data sensors information

Display Message s and status

display information

Control Panel display

alarm type Sensors sensor status Monitor sensor

alarm

telephone number tones

Telephone line

Level 1: DFD for SafeHome.

Level 2: The processes represented at DFD level 1 can be further refined into lower levels. For example, the process monitor sensors can be refined into a level 2 DFD as shown below.
sensor information

Format For display

alarm data

configuration information sensor id type location configuration data alarm data Generate Alarm signal

Assess Against setup

telephone number

Sensor id, type Read sensors Dial phone

Sensor Status

telephone number tones

Level 2: DFD that refines the monitor sensors process