IEEE defines a data-flow diagram (also known as bubble chart and workflow diagram) as, 'a diagram that depicts data sources, data sinks, data storage and processes performed on data as nodes and logical flow of data as links between the nodes.' DFD allows the software development team to depict flow of data from one process to another.
The data flow diagram is a graphical representation of flow of data in an information system. It is capable of depicting incoming data flow, outgoing data flow and stored data. The DFD does not mention anything about how data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of control in program modules. DFDs depict flow of data in the system at various levels. DFD does not contain any control or branch elements.
Types of DFD
Data Flow Diagrams are either Logical or Physical.
• Logical DFD - This type of DFD concentrates on the system process, and flow of data in the system.For example in a Banking software system, how data is moved between different entities.
• Physical DFD - This type of DFD shows how the data flow is actually implemented in the system. It is more specific and close to the implementation.
DFD Components
DFD can represent Source, destination, storage and flow of data using the following set of components -
• Entities - Entities are source and destination of information data. Entities are represented by rectangles with their respective names.
• Process - Activities and action taken on the data are represented by Circle or Round-edged rectangles.
• Data Storage - There are two variants of data storage - it can either be represented as a rectangle with absence of both smaller sides or as an open-sided rectangle with only one side missing.
• Data Flow - Movement of data is shown by pointed arrows. Data movement is shown from the base of arrow as its source towards head of the arrow as destination.
There are various levels of DFD, which provide details about the input, processes, and output of a system. Note that the level of detail of process increases with increase in level(s). However, these levels do not describe the system's internal structure or behavior. These levels are listed below.
Level 0 DFD: This shows an overall view of the system. Level 0 DFD is also known as context diagram.
To understand various levels of DFD, let us consider an example of a banking system. This DFD represents how a 'user' entity interacts with a 'banking system' process and avails its services. The Level 0 DFD depicts the entire banking system as a single process. There are various tasks performed in a bank such as transaction processing, pass book entry, registration, demand draft creation, and online help. The data- flow indicates that these tasks are performed by both the user and the bank. When the user performs a transaction, the bank verifies whether the user is registered in the bank.
Level 1 DFD: This elaborates level 0 DFD and splits the process into a detailed form.
In Level 1 DFD, the 'user' entity is related to several processes in the bank, which include 'register', 'user support', and 'provide cash'. Transaction can be performed only if the user is already registered in the bank. Once the user is registered, he can perform a transaction by the processes, namely, 'deposit cheque', 'deposit cash' and 'withdraw cash'. Note that the line in the process symbol indicates the level of process and contains a unique identifier in the form of a number. If the user is performing transaction 'deposit cheque', the user needs to provide a cheque to the bank. The user's information such as name, address, and account number is stored in 'user-detail' data store, which is a database. If cash is to be deposited and withdrawn, then the information about the deposited cash is stored in 'cash-detail' data store. The user can get a demand draft created by providing cash to the bank. It is not necessary for the user to be registered in that bank to have a demand draft. The details of amount of cash and date are stored in 'DD-detail' data store. Once the demand draft is prepared its receipt is provided to the user. The 'user support' process helps users by providing answers to their queries related to the services available in the bank.
Level 2 DFD: This elaborates level 1 DFD and displays the process(s) in a detailed form.
In Level 2 DFD for any process of a banking system that has detailed tasks to perform. For instance, Level2 DFD can be prepared to deposit a cheque, deposit cash, withdraw cash, provide user support, and to create a demand draft. However, it is important to maintain the continuity of information between the previous levels (Level0 and Level1) and Level2 DFD. As mentioned earlier, the DFD is refined until each process performs a simple function, which is easy to implement.
Letus consider the 'withdraw cash' process to illustrate Level2 DFD. The information collected from Level1 DFD acts as an input to Level 2 DFD. To withdraw cash, the bank checks the status of balance in the user's account (as shown by 'check account status' process) and then allots a token (shown as 'allot token' process). After the user withdraws cash, the balance in user's account is updated in the 'user-detail' data store and a statement is provided to the user.
Level 3 DFD: This elaborates level 2 DFD and displays the process(s) in a detailed form
If a particular process of Level2 DFD requires elaboration, then this level is further refined into Level3 DFD. Let us consider the process 'check account status' to illustrate Level3 DFD. To check the account status, the bank fetches the account detail (shown as 'fetch account detail' process) from the 'account-detail' data store. After fetching the details, the balance is read (shown as 'read balance' process) from the user's account. Note that the requirements engineering process of DFDs continues until each process performs a function that can be easily implemented as an individual program component.
No comments:
Post a Comment