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 current system '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 from one person or location to another. In a logical view they are not necessary, since physical locations or separation of peoples jobs are not retained.

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.