BUDGET MONITORING SYSTEM
What is a DATA FLOW DIAGRAM?
"A network representation of a system. The system may be automated, manual, or mixed. The DFD portrays the system in terms of its component pieces, with all interfaces among the components indicated."
- Tom DeMarco
Hence DFDs:
focus on the movement of data between external entities and processes, and between processes and data stores
SYMBOLS USED IN DFD’S
DFDs are constructed using four major components:
1. External entities,
2. Data stores
3. Processes
4. Data flows
External entities represent the sources of data that enter the system or the recipients of data that leave the system. Examples are clerks who enter data into the system or customers who receive letters produced by the system.
Data stores represent stores of data within the system. Examples are files or databases or, in a manual system, paper files held in filing cabinets. They are drawn as open-ended rectangle with a unique identifier, a box at closed end and name of the store in the open section. Manual data stores are identified by the letter M followed by a number and identifiers for computerized stores are prefixed by a Data stores cannot be directly linked by data flows either each other or to external entities without an intervening Process to transform the data.
Process represents activities in which data is manipulated by being stored or retrieved or transformed in some way. They are shown as larger Rectangle with a numeric identifier in a box at the left corner. The location where the process takes place or the job role performing it is recorded in a box in the top right corner and is only used in diagrams of the current physical system. The name of the process is recorded in the remaining area at the bottom. Process names should be unambiguous and should convey as much meaning as possible without begin too long. Generalized verbs such as process or update are not usually helpful. Data flows represent the movement of data between components, for example a report produced by a process and sent to an external entity. They are shown as named arrows connecting the other components of the diagram.
Data flows are generally shown as one-way only. Data flows between external entities are shown as dotted lines. It may be necessary to draw the same external entity or data store more than once on the same DFD in order to make the diagram clear and to avoid too many crossing lines. An external entity, which appears more than once in the same diagram, is shown with diagonal line at the top left. Duplicate data stores are given an additional vertical line on the left side of their reference boxes.
We will now illustrate how a system is modeled using these symbols. A common way to begin is to model the whole system by one process. The data flow diagram that does this is known as the context diagram. Thus, the diagram below shows the context diagram of a Budget monitoring system.
The external entities are:
Departments
Management
Suppliers
The Data flow from departments is ‘requesting data’ and in return departments receive rejected request or delivery advice. Management receives ‘request for special approval’ to which it responds. It also sends ‘budget allocation’ data flow to the system and get ‘spending summary’ data flows. Suppliers receive ‘part order’ and return ‘supplier delivery advice’ data flows.
A model like that shown in the context diagram does not describe the system in detail. For more details, it is necessary to identify the major system processes and draw a DFD diagram made up of these processes and the data flows between them. From the figure below, we see that data flow ‘spending requests’ from departments goes to the ‘check funding’ process. This process check allocated budget and determines whether management can proceed with the request. Approved request goes to ‘classify expenditure’ where they are entered into departmental-accounts and type-accounts data stores. Finally, a ‘part order’ for parts originally specified in a ‘spending request’ is placed with suppliers. There are two other processes, ‘set up budget’ and ‘provide spending summary’.
CONCLUSION
We could expand each process in more detailed DFDs. However, we should stop. DFDs would become awkward and complex. Ideally, a DFD is self-explanatory, complete and unambiguous. We have tried to explain how systems are modeled by DFD. It may look simple but difficulties may arise once you get into details.
No comments:
Post a Comment