# 1) Checking the diagram for errors
There are several common errors made when drawing data flow diagrams:
- Forgetting to include a data flow or pointing an arrow in the wrong direction
This error usually occurs when the analyst has forgotten to include a data flow or has placed an arrow pointing in the wrong direction.
This figure contains only input because Gross Pay arrow is pointing in the wrong direction. This error also affects process 2, Calculate Withholding Amount, that is in addition missing a data flow representing input for next process and so on.

- Connecting data stores and external entities directly to each other.
This error is because data stores and entities may not be connected to each other, data stores and external entities must connect only with a process. Without the help of a program or a person moving the data, a file does not interface with another file.
EMPLOYEE MASTER cannot directly produce the check reconciliation file. External entities do not directly work with this file. Two external entities directly connected indicate that they wish to communicate with each other. This connection is not included on the data flow diagram unless the system is facilitating the communication.
- Incorrectly labeling processes or data flow.
Make sure that each object or data flow is properly labeled. A process should indicate the system name or use the verb-adjective-noun format. Each data flow should be described with a noun.
- Including more than nine processes on a data flow diagram.
Having too many processes creates a cluttered diagram that is confusing to read and hinders rather than enhances communication. Solution, group some of the processes that work together into a subsystem and place them in a child diagram.
- Omitting data flow.
Let’s take a linear flow diagram for example, in which each process has only one input and one output. Except in the case of very detailed child data flow diagrams, linear data flow is rare because its presence usually indicates that the diagram has missing data flow.
- Creating unbalanced decomposition (or explosion) in child diagrams.
Each child diagram should have the same input and the same output data flows as the parent process. An exception to this rule is minor output, such as error lines, which are included only on the child diagram.

# 2) Logical and Physical Data Flow Diagrams:
## - Logical
+ Focuses on the business and how the business operates
+ Not concerned with how the system will be constructed.
+ Described the business events that take place and the data required and produced by each event.

## - Physical
+ Shows how the system will be implemented.
+ Depicted the system.

## - Figure 7.7 Features common of logical and physical data flow diagrams
The chart in figure 7.7 contrasts the features of logical and physical models. Notice that the logical model reflects the business, whereas the physical model depicts the system.

## - Figure 7.8 The progression of models from logical to physical

## - Developing logical data flow diagrams:
Before you construct a physical data flow diagram you need to first construct a logical data flow diagram for the current system. Here are the advantages of using a logical model:
- Better communication with users.
- More stable systems.
- Better understanding of the business by analysts
- Flexibility and maintenance.
- Elimination of redundancy and easier creation of the physical model.

## - Developing physical data flow diagrams
There are total 6 advantages of physical data flow diagrams:
- Clarifying which processes are performed by humans and which are automated
- Describing processes in more detail
- Sequencing processes that have to be done in a particular order.
- Identifying temporary data stores.
- Specifying actual names of files and printouts.
- Adding controls to ensure the processes are done properly.

### + Figure 7.10 Physical data flow diagrams contain many items not found in logical data flow diagrams

Scripts: Physical data flow diagrams are often more complex than logical data flow diagrams simply because of the many data stores present in the system.

The acronym CRUD is used for Create, Read, Update, and Delete

A CRUD matrix shows which programs or processes add, read, update, or delete master file records.

Intermediate data stores often consist of transaction files used to store data between processes.
A physical data flow diagram may appear more linear that a logical model.

### Event Modeling and Data Flow Diagrams.
- A practical approach to creating physical DFD is to create a data flow diagram fragment for each unique system event.
- An input flow from an external entity is sometimes called a trigger because it starts the activities of a process. Which in turn use data or produce output.
- Events cause the system to do something and act as a trigger to the system.

#### Event response table:
- An event table is used to create a DFD by analyzing each event, and the data used and produced by the event.
- Every row in an event table represents a DFD fragment and is used to create a single process on a DFD.
##### Figure 7.12 An event response table for an Internet storefront
Figure 7.12 illustrates an example of an event response table for an Internet storefront business.

Events are usually summarized in an event response table.
A data flow diagram fragment is represented by a row in the table. Each DFD fragment is a single process on a data flow
diagram. All the fragments are then combined to form Diagram 0. The trigger and response columns become the input and output data flows, and the activity becomes the process.
##### Figure 7.13 Data flow diagrams for the first three rows of the Internet storefront event response table.
And Figure 7.13 illustrates data flow diagrams for the first three rows of the event response table.

### Use cases and data flow diagrams
- Each use case defines one activity and its trigger, input, and output.
- Allows the analyst to work with users to understand the nature of the processes and activities and then create a single DFD fragment.

## Partitioning Data Flow Diagrams
- Partitioning is the process of examining a data flow diagram and determining how it should be divided into collections of manual procedures and computer programs.

You should analyze each process to determine whether it should be a manual or automated procedure. Then you can group automated procedures into a series of computer programs.
- A dashed line is drawn around a process or group of processes that should be placed in a single computer program.

a) Reasons for partitioning DFDs:
1) Different user groups.
2) Timing.
3) Similar tasks.
4) Efficiency.
5) Consistency of data.
6) Security.

# 3) Partitioning Website
Scripts:
Partitioning is a very useful principle when designing a website. Website designers who use forms to collect data may divide a website into a series of web pages, which helps:

- Improves the way humans use the site
- Improves speed of processing
- Ease of maintaining the site
- Keep the transaction secure:
Each time data must be obtained from a data store or an external partner, a website designer might consider creating a unique Web from and DFD process to validate and process the data.

# 4) Communicating Using Data Flow Diagrams
- Use unexploded data flow diagrams early when ascertaining information requirements
- Meaningful labels for all data components

Sripts: Data flow diagrams are useful throughout the analysis and design process. You use original, unexploded data flow diagrams early when ascertaining information requirements.

In order to make the diagrams truly communicative to users and other members of the project team, meaningful labels for all data components are also required. Labels should not be generic because then they do not tell enough about the situation at hand
# 5) Summary:
Data flow diagrams are structured analysis and design tools that allow the analyst to comprehend the system and subsystems visually as a set of interrelated data flows.
#### Creating the logical DFD:
+ Context-level data flow diagram
+ Level 0 logical data flow diagram
+ Child diagram

Scripts: A systems analyst extracts data from early organizational narratives or stories told by user and uses a top-down approach to
+ first draw a context-level data flow diagram of the system within the larger picture
+ Then draw a level 0 logical data flow diagram
+ Next creates a child diagram for each of the processes in Diagram 0

#### Creating the physical DFD:
+ Create from the logical data flow diagram
+ Partitioned to facilitate programming

Scripts: The analyst then develops a physical data flow diagram from the logical dfd. Next he partitions it to facilitate programming. Each process is analyzed to determine whether it should be a manual or automated procedure.

#### Partitioning DFD:
Six consideration for partitioning data flow diagram are:
+ Whether processes are performed by different user groups
+ Processes execute at the same time
+ Processes perform similar tasks
+ Batch processes can be combined for efficient processing
+ Processes maybe combined into one program for consistency of data.
+ Process maybe partitioned into different programs for security reasons