Advantages of the Data Flow Diagram
System analyst in some extent, argue Data Flow Diagrams as this procedure takes long time of modeling. But what’s the alternative? The DFD offers the analyst with several distinct advantages. Some of them are shown there in list:
- Most fundamentally, it depicts flow and boundary. The essence of knowing boundary is first to understand the extent of the process prior to beginning to define something that may not be complete or accurate.
- The concept is typically known as top-down, but the effort can also be conceived as step-by-step. The analyst must first understand the boundary and flows prior to doing anything else. The steps following this will procedurally gather more detailed information until the specification is complete.
- Another important aspect of the DFD is that it represents a graphical display of the process and is therefore a usable document that can be shown to both users and programmers, serving the former as process verification and the latter as the schematic (blueprint) of the system from a technical perspective.
- It can be used in JAD(Joint Application Design) sessions and as part of the business specification documentation. Most important, it can be used for maintaining and enhancing a process.
- Using least numbers of Symbols make design of DFD a easy task.
Disadvantages of the DFD
Besides of those distinct advantages; there are some disadvantages as well. Some of them are listed below:
- The biggest drawback of the DFD is that it simply takes a long time to create: so long that the analyst may not receive support from management to complete it. This can be especially true when there is a lot of leveling to be performed. Therefore, many firms shy away from the DFD on the basis that it is not practical.
- The other disadvantage of the DFD is that it does not model time-dependent behavior well, that is, the DFD is based on very finite processes that typically have a very definable start and finish. This, of course, is not true of all processes, especially those that are event driven.
- The best solution to the time-consuming leveling dilemma is to avoid it as much as possible. That is, you should avoid starting at too high a summary level and try to get to the functional primitive as soon as you can. If in our example, for instance, the analyst had initially seen that the DFD had two processes instead of one, then the parent process could have been eliminated altogether.
This would have resulted in an initial functional primitive DFD at Level 1. The only way to achieve this efficiency on a consistent basis is through practice. Practice will eventually result in the development of your own analysis style or approach. The one-in, one-out principle of the logical equivalent is an excellent way of setting up each process. Using this method, every event description that satisfies one-in, one-out will become a separate functional primitive process. Using this procedure virtually eliminates leveling. Sometimes users will request to see a summary-level DFD. In these cases the functional primitives can be easily combined or “leveled-up.”
Moreover, you can see our article on ” How do we begin to construct Data Flow Diagrams (DFDs)?” for exploring your ideas of designing DFDs.