DFDs do not show flow of control. This is a very important thing we must remember. DFDs also will generally not show one-time kind of things, like initializations. We do not show processes which initialize or create files, or create databases. They instead show processes which are running in a steady state. So data flow diagram can be imagined in terms of processes which are continuously executing. As soon as they receive the data, they produce their output and hand over that to the next process or update a data store or some such action takes place. So we do not generally show the one-time kind of activities but show processes in their steady state.
DFDs show only some important exceptions or errors. These are shown in order to introduce some specific business requirements to deal with that. So for example, if the inventory has fallen below a certain level, this may be treated as exception which is associated with some business rule that some reordering has to be done because our inventory has fallen very low. So such exceptions would be shown. But otherwise routine type of errors are generally not shown in the data flow diagram. So for example, we will not show things like the airline number which is given by the customer is wrong, or the destination that he has given, no such city exists in our database. Now we assume that such errors will naturally be handled by our software but they are routine type of errors where data validity has to be done. These are not shown as a part of data flow diagram so that we concentrate on main functions and main processes rather than get distracted by routine type of exceptions.
Processes must be independent of each other. So again here we refer to our thumb rule that cohesion and coupling are the guidelines we always use for any decomposition. So when we define sub-processes we should ensure that the new sub-processes that we have created are cohesive in terms of what they do and there is minimum interdependence between them. In fact, the only way the processes or sub-processes interact with each other is through data. So work of a process should depend only on its inputs and not on the state of another process. So processes are independent in that sense and this is an important point we must observe when we are doing the refinement. Only needed data should be input to the process. Now this is again an obvious requirement that a process should receive inputs which it needs for producing the outputs which are the responsibility of that process.
As we do refinement we must also ensure consistency at different levels of refinement. Here is an example where on the top we show a data flow diagram in which process F1 has been defined as having input A and producing output B. Now this process F1 itself may be fairly complex and this process may be now decomposed into different sub-processes. Now this is a process one, so we are decomposing it into 1.1, 1.2, 1.3, and 1.4 as four sub-processes with this kind of relationships among them. So this decomposition here shows that a complex process such as F1 gets decomposed into four processes which have been now named as 1.1, 1.2 and so on to indicate that they are part of process one here.
And in this case, the consistency among the levels require that the inputs here should match with the inputs in this process. So inputs and outputs must match. On the other hand, new data stores may be shown. So for example, here in this level of data flow diagram, we did not show the data store but when we decompose F1, a new data store might surface because it needs to supply some history data or pass data to one of the processes. So important point in refinement is that there must be consistency among levels in terms of inputs and outputs on level 1 should be same as the inputs and outputs at level 2.
A physical DFD indicates not only what needs to be done but it also shows how things are being done. So it shows some implementation details. Now these details will naturally depend on the environmental of the application. For example, you might show the names and locations of places where things are getting done, or how the data is actually stored. For example, the data may be stored in a library in terms of card indexes which are stacked in drawers. So this is a physical way but that will be shown in the physical data flow diagram. It’s how things are done at present. That is what you want to convey when you want to draw a physical data flow diagram.
You may also indicate the way the tasks are divided in terms of being assigned to different people. For example, two different persons may be dealing with undergraduate and post-graduate students. Now this is a present way of doing things. That’s why this may be shown in a physical data flow diagram. But when you analyze the physical data flow diagram in order to develop your application, you will notice that these are implementation details which are details about the existing scenarios. And you do not want to carry them further and bias your design and implementation subsequently. You would like to convert such a physical data flow diagram into a logical data flow diagram where such implementation details are filtered out.
This is, as we said earlier, useful for describing the existing system so that it can be readily validated with the users. This needs to be converted into a logical data flow diagram after we have validated and purpose of converting the logical data flow diagram is to remove these implementation biases so that we can now consider different ways of implementing what is required for the application.
One example of data flow diagram is to clearly show the boundaries of automation. So when you have a large data flow diagram like this, you can clearly mark the scope of the system that you propose to develop so that users clearly get the idea of what exactly they can expect from the software system, which functions and processes would be automated and how they would interface with the rest of the requirements or the rest of the environment of the user’s application. So boundaries can be conveniently marked on a data flow diagram.
Let us now take one example where we are addressing the payroll application. We will assume that we have already done the context diagram and we are now decomposing that first level of context diagram or the zero level DFD into the first level DFD where we have shown five sub-processes. We have numbered them as one up to five. We have identified employee as the external entity. And while doing the first level DFD we have identified a few data stores. If you look at the data stores and what data they contain, it will be clearly understood that such data would be required for a payroll application. We have a data store here which contains the data about employees. We have a data store here which gives details of taxation. So what tax rules are applicable. And here is a data store which contain the payments which have been made to the employees.