8/3/2019 l2logical Data Flow Logical is at Ion v2

http://slidepdf.com/reader/full/l2logical-data-flow-logical-is-at-ion-v2 1/2

Logical Data Flow Diagrams

 

So far we have producing DFDs that illustrate the current system - these are known as 'Current 

 Physical Data Flow Diagrams' . A Current Physical Data Flow Diagram represents the currentsystem 'warts and all' . However, the current system may be:

•  badly structured because it was not developed from first principles;

• inefficient because the same data is held more than once;

• inefficient because the same processing may be performed more than once.

The Current Physical Data Flow Diagram acts as a foundation upon which we can build.

1. Logicalisation

Put simply, logicalisation is a tidying up process. A new Data Flow Diagram is produced which

shows the existing system with all its inefficiencies and duplications removed. New requirements

are also added. The result is a well organised and clear picture of how the system should be

rather than how it actually is. This is known as a 'Logical Data Flow Diagram' . In order to move

from a physical DFD to a logical DFD the following activities should take place:

• rationalize the data stores - remove duplication / redundancy;

• regroup processes, combine any duplicate processes;

• remove processes / data stores concerned with scheduling the existing system;

• remove / review the human / computer interface if the current system is a computer 

system;

• rename processes and flows - replace form names with logical data descriptions;

• ensure only required data is passed to a process (may have to create bypass data flows);

•  break down large physical data stores that may correspond to several entities in the data

model;

• re-levelling may be necessary

• cross-check to ensure that nothing has been missed.

1.1 Rationalize the Data Stores

This has two aspects: the removal of transient data stores and the replacement of physical stores

with entities. Transient data stores exist purely as a holding area for information moving fromone person or location to another. In a logical view they are not necessary, since physical

locations or separation of peoples jobs are not retained.

8/3/2019 l2logical Data Flow Logical is at Ion v2

http://slidepdf.com/reader/full/l2logical-data-flow-logical-is-at-ion-v2 2/2

Replace data stores with entities. For example, in Run-around, the tour list file and the tour file

can be combined into a single entity: TOUR. When replacing data stores by entities the physical

details are removed e.g. 'file', 'list' etc.

1.2 Regrouping Processes

Processes which are joined by flows in the physical DFD can be combined if all the data to begin

the second process is available from the first. The effect of this means it is unlikely that

 processes will be directly connected by data flows in the logical DFD. Where the same basic

 processing is found in two locations these can be combined. If a process merely reorganizes data

(e.g., sorting, merging etc.) or is present only due to the physical method of working (e.g.

reconciliation between sources of the same data) it can be omitted.

1.3 Rename Processes and Flows

Processes and flows should be given non-physical names. For example, rather than calling a flow

'sales report SR151' , something like 'sales variance details' would be more appropriate. This

does not necessarily imply a hard copy or a particular layout to the reader. References to physical

documents and ways of performing jobs should be removed.

1.4 Cross-Check for Completeness

The analyst should finally check that, in the enthusiasm to simplify the physical DFD, nothing

essential has been lost. The logical DFD must contain all the functionality and data of the

 physical DFD

1.5 Word of Warning

There is a growing trend amongst systems analysts to move straight to a logical DFD without

developing a physical DFD first. This can be dangerous as there is no starting point with which

the users can identify.