Download
Data Flow Model Presentation Transcript:
1.Data Flow Model
Captures the flow of data in a system.
It helps in developing an understanding of system’s functionality.
What are the different sources of data, what different transformations take place on data and what are final outputs generated by these transformations.
2.It describes data origination, transformations and consumption in a system.
Information is organized and spread at different levels of abstraction. Thus this technique becomes a tool for top down system analysis and requirements modeling.
3.The Notation
Process
What are different processes or work to be done in the system.
Transforms of data.
External Agent
External systems which are outside the boundary of this system. These are represented using the squares
4.Data Store
Where data is being stored for later retrieval.
Provides input to the process
Outputs of the processes may be going into these data stores.
Data Flow
Where the data is flowing.
Represents the movement of the data in a data flow diagram.
5.DFD versus Flow Charts
6.Data Flow Model – Bank Account Management System
7.Processes
1. Reconcile account balance
Deposit funds into an account
Pay a bill
Withdraw funds from an account
External agents
Bank
Creditor
Employer
Other income sources
Data stores
Monthly Account statement
Bank accounts
Account transactions
8.Data Flow Modeling
When data flow modeling is used to model a system’s functionality, following points need to be remembered:
Data flow model captures the transformation of data between processes/functions of a system. It does not represent the control flow information that is occurring in a system to invoke certain functionality.
A number of parallel activities are shown in this diagram where no specific sequence among these activities is depicted
9.Data Flow Modeling-I
In data flow models, only processes which we need to automate as they involve certain computation, processing or transformation of data that can be best implemented using an automated system.
For example, we may consider a mail desk in an office that receives mail and just forwards it to their respective addressees. In this example, as the mail desk does not process the mail, just forwards it, therefore it does not include any process that need to be automated. Hence, we shall not use data flow diagrams to model this process.
10.In nutshell, processes that just move or transfer data (do not perform any processing on that data), should not be described using data flow models.
Taking the same example, if we modify the scenario such that a mail desk clerk receives the mail, notes it down into a register and then delivers it to their respective addressees then a processing has got involved in this scenario. At least one process is there that can be automated. That is, the recording of mail information into the register. Now we can use a data flow model in which we shall use a data transformation that captures the detail of recording mail information into a register (or a data store). Thus with this addition, it makes sense to use data flow model to capture the details of this process.
11.Typical Processes
The following processes which are typically modeled using data flow diagrams :
Processes that take inputs and perform certain computations. For example, Calculate Commission is a process that takes a few inputs like transaction amount, transaction type, etc and calculates the commission on the deal.
Processes which are involved in some sort of decision-making. For example, in a point of sales application a process may be invoked that determines the availability of a product by evaluating existing stocks in the inventory.
12.Processes that sort data and present the results to users.
Processes that trigger some other function/process
For example, monthly billing that a utility company like WAPDA, PTCL generates. This is a trigger that invokes the billing application every month and it prepares and prints all the consumer bills.
13.Actions performed on the stored data. These are called CRUD operations and described in the next subsection
CRUD Operations
These are four operations as describes below
Create: creates data and stores it.
Read: retrieves the stored data for viewing.
Update: makes changes in an stored data.
Delete: deletes an already stored data permanently.
14.Adding Levels of Abstraction to Data Flow Modeling
As we have already described that in data flow modeling only those processes can be expressed that perform certain processing or transformation of information. Now the question arises how far these processes need to be expressed?
As a single process like CalculateCommission can be described in sufficient detail such that all of its minute activities can be captured in the data flow diagram.
15.However, if we start adding each bit of system functionality in a single data flow diagram, it would become an enormously large diagram to be drawn on a single piece of paper.
Moreover, requirement analysis is an ongoing activity in which knowledge expands as you dig out details of processes.
Therefore, it may not be possible for an analyst to know each bit of all the processes of the system from the very beginning.
Keeping the complexity of systems in view, data flow modeling technique has suggested spread information of a system in more then just one levels of abstraction.
Data Flow Model Presentation Transcript:
1.Data Flow Model
Captures the flow of data in a system.
It helps in developing an understanding of system’s functionality.
What are the different sources of data, what different transformations take place on data and what are final outputs generated by these transformations.
2.It describes data origination, transformations and consumption in a system.
Information is organized and spread at different levels of abstraction. Thus this technique becomes a tool for top down system analysis and requirements modeling.
3.The Notation
Process
What are different processes or work to be done in the system.
Transforms of data.
External Agent
External systems which are outside the boundary of this system. These are represented using the squares
4.Data Store
Where data is being stored for later retrieval.
Provides input to the process
Outputs of the processes may be going into these data stores.
Data Flow
Where the data is flowing.
Represents the movement of the data in a data flow diagram.
5.DFD versus Flow Charts
6.Data Flow Model – Bank Account Management System
7.Processes
1. Reconcile account balance
Deposit funds into an account
Pay a bill
Withdraw funds from an account
External agents
Bank
Creditor
Employer
Other income sources
Data stores
Monthly Account statement
Bank accounts
Account transactions
8.Data Flow Modeling
When data flow modeling is used to model a system’s functionality, following points need to be remembered:
Data flow model captures the transformation of data between processes/functions of a system. It does not represent the control flow information that is occurring in a system to invoke certain functionality.
A number of parallel activities are shown in this diagram where no specific sequence among these activities is depicted
9.Data Flow Modeling-I
In data flow models, only processes which we need to automate as they involve certain computation, processing or transformation of data that can be best implemented using an automated system.
For example, we may consider a mail desk in an office that receives mail and just forwards it to their respective addressees. In this example, as the mail desk does not process the mail, just forwards it, therefore it does not include any process that need to be automated. Hence, we shall not use data flow diagrams to model this process.
10.In nutshell, processes that just move or transfer data (do not perform any processing on that data), should not be described using data flow models.
Taking the same example, if we modify the scenario such that a mail desk clerk receives the mail, notes it down into a register and then delivers it to their respective addressees then a processing has got involved in this scenario. At least one process is there that can be automated. That is, the recording of mail information into the register. Now we can use a data flow model in which we shall use a data transformation that captures the detail of recording mail information into a register (or a data store). Thus with this addition, it makes sense to use data flow model to capture the details of this process.
11.Typical Processes
The following processes which are typically modeled using data flow diagrams :
Processes that take inputs and perform certain computations. For example, Calculate Commission is a process that takes a few inputs like transaction amount, transaction type, etc and calculates the commission on the deal.
Processes which are involved in some sort of decision-making. For example, in a point of sales application a process may be invoked that determines the availability of a product by evaluating existing stocks in the inventory.
12.Processes that sort data and present the results to users.
Processes that trigger some other function/process
For example, monthly billing that a utility company like WAPDA, PTCL generates. This is a trigger that invokes the billing application every month and it prepares and prints all the consumer bills.
13.Actions performed on the stored data. These are called CRUD operations and described in the next subsection
CRUD Operations
These are four operations as describes below
Create: creates data and stores it.
Read: retrieves the stored data for viewing.
Update: makes changes in an stored data.
Delete: deletes an already stored data permanently.
14.Adding Levels of Abstraction to Data Flow Modeling
As we have already described that in data flow modeling only those processes can be expressed that perform certain processing or transformation of information. Now the question arises how far these processes need to be expressed?
As a single process like CalculateCommission can be described in sufficient detail such that all of its minute activities can be captured in the data flow diagram.
15.However, if we start adding each bit of system functionality in a single data flow diagram, it would become an enormously large diagram to be drawn on a single piece of paper.
Moreover, requirement analysis is an ongoing activity in which knowledge expands as you dig out details of processes.
Therefore, it may not be possible for an analyst to know each bit of all the processes of the system from the very beginning.
Keeping the complexity of systems in view, data flow modeling technique has suggested spread information of a system in more then just one levels of abstraction.
No comments:
Post a Comment