Introduction
We’ll continue our discussion on process modeling. In the previous lecture, we talked about functional decomposition as a first step in process modeling. Given the complex process, we should try to decompose it into sub-processes or smaller processes which can be better understood in terms of what actions they do.
Data Flow Diagrams
We’ll now continue with the process modeling and look at another important tool called Data Flow Diagrams. Data Flow Diagrams are a very popular tool for describing functions which are required in a given system. And these functions are specified in terms of processors as well as the data used by these processes. So this is one important difference from function decomposition diagram where we do not show data explicitly whereas in the case of Data Flow Diagrams both the processes and the data which will flow among those processes would be shown. That’s why they are called Data Flow Diagrams.
We may do function decomposition diagrams before doing data flow diagram. However we may also do data flow diagrams directly but it is better to think about function decomposition beforehand and it would be a good practice to do function decomposition before, because this function decomposition would be anyway required when we do data flow diagrams. So having done it earlier before coming to data flow diagrams would always be more fruitful. Data flow diagrams have more content than function decomposition diagrams obviously because now we will be explicitly showing the flow of data.
Data flow diagrams are very simple pictorial tools. They represent the functional and the data flow in the form of a diagram. And therefore they are very easy to understand by all people, users as well as managements. So they have become very popular in the analysis phase for representing the functions performed by a particular application.
Data flow diagrams are also unambiguous and concise. They can describe processing both at the physical level as well as at the logical level. Remember that at physical level we describe the way things are done rather than what needs to be done. So we can have both data flow diagrams. In fact, usually when you’re studying the existing system, you are studying it at the physical level. Therefore if you represent these in the form of a data flow diagram, the diagram will be at the physical level representing both what is done and how it is done currently.
After doing this, you will move towards preparation of a logical level data flow diagram where we emphasize what needs to be done and not necessarily how it should be done because the how part is really the part to be addressed during the design phase.
DFDs facilitate top down development. In fact, that is the strength of the tool so that you can introduce more and more details as you do step-by-step decomposition of these diagrams. They permit outlining of preferences and scope. So when you are discussing different alternatives with the users or the management, you can clearly mark those alternatives on the data flow diagram itself so that the people can understand the scope of the application software that we are proposing. So it’s another use for data flow diagrams.
DFD Notations
Here is the notation that we use in diagramming the data flows. In the diagram, you show data flow through an arrow. Usually the arrow will be labeled with the kind of data which flows on that. Then we show the sources of data or the sources which use this information. These are generally the external entities and these entities are shown using either a rectangle like this, or it may be a double-edged rectangle. I am giving here two different representations and both are used in the industry. You can choose one of them. The one on the left is simpler to draw when we are doing the data flow diagrams by hand. So we will probably prefer this. But whereas when you use tools for doing data flow diagrams any one of them could be used by us. So sources and sinks of data and information typically are the users of this system. And these would be shown as external entities.
Then processes are either shown as a circle which is also called a bubble, or a rectangle with the rounded corners, and we label them with some number for easy reference. So process is shown. And then finally we also show data either through a pair of lines or by a small box which represents a collection of data. And that box may also be labeled with a number for ease of referencing.
So primarily the data flow diagram provides only four symbols. One is the arrow for flow of data. One is a rectangle that represents an external entity which would either supply some data to our application, or which will receive some results from our application. Then we have the processes represented as bubbles, and we have a data store which is represented by a pair of lines. So this is the simple rotation that we will use for drawing data flow diagrams.
Here is a simple example. So let’s begin by an example and you’ll also appreciate how simple they are to read and understand. Now in this we see two rectangles, both are labeled same, so it’s a single entity called a traveler. So traveler is a external entity which will be using this application which we have called as airline reservation. Now some data flows from this traveler and comes to a process called make reservation. Now that data would be the date and time and destination where the traveler wishes to go, and he wants to buy a ticket if it is available for this.
So the first process which handles this data is the make reservation process. Now if you look at this process, this process not only takes this input but it takes another input from a data source called flight database. This arrow, the direction of arrow indicates that the data is being taken by the process as the input of data. So we take two inputs here. One is from the traveler about his time, data and destination. The other is the flight database, and then we prepare a suitable reservation. The reservation is also recorded. We may have to consult the existing bookings and see whether there is a space available. And if available, we make a reservation.
After making the reservation, this process produces outputs for two other processes. So one output goes from make reservation to a process called prepare ticket. Now ideally we should be labeling all these arrows. The label of the arrow will indicate the data which is sent by make reservation to the prepare ticket. But from the context we can easily make out that in order to prepare the ticket we will have to obtain traveler’s data as well as the flight data so that a ticket can be made. And the ticket is an output of this process. The ticket goes to the traveler. So this is a physical output produced by our software for the traveler.
Pages: First |1 | ... | Next → | Last | View Full Transcript