Logical Data Flow Model Characteristics

A “logicalised” DFM has certain characteristics that make it more precise than the current DFM. The most visible is that all its data stores are shown as digitised, since they are now merged with the LDM which can only exist as a computing notion and has no meaning outside a database.

Other characteristics of a logical DFD include: the absence of references to locations, the almost total absence of processes triggered by other processes, and the appearance of people working in the organisation as external entities of the system.

Locations usually betray some temporal characteristic of the current system. Who does what where is of no ‘logical’ value and should therefore be distanced from the abstract view taken by the logical DFM. If locations remained part of the logical DFM, the value of the abstraction inherent in this model would be greatly diminished. Realising that locations represent physical characteristics of a system is a, not straightforward, step towards understanding how a good DFM can improve a system’s development.

A doubt all data flow modellers share is to know what level of detail needs to be represented in a DFM. This doubt is resolved when it is remembered that the DFM is good at identifying the events which the system will have to anticipate in order to capture the incoming data. Each DFD process need not be broken down further than needed to show which event it is a process for. It is therefore rarely necessary to show one event snowballing across the system triggering many processes in succession. For example, instead of

the following suffices

The final characteristic of a logical DFM is a recognition that certain users who appeared as locations in the current DFM may be actually contributing information to the system. If so, they have to be perceived as external entities of the system. Take for example the little salon of figure 5.7 and trace it back to its origin. The original customer card had a column for comments such as ‘good tipper’, ‘grumpy customer’ etc.. These comments, which incidentally may contravene the British Data Protection Act, come from the receptionist. If the computer system is to retain this ‘facility’, the logical DFM should be updated to look like the one of figure 5.10:

Figure 5.10 An update of figure 5.7, showing the receptionist as an external entity