Download Data Flow Diagram Tutorial and more Lecture notes Design in PDF only on Docsity!
Data Flow Diagram Tutorial
Objectives
After completion of study of this unit you should be able to:
• Describe the use of data flow diagrams
• Produce a data flow diagram from a given case study
including different levels
• Distinguish between the different categories of data flow
diagrams
1. Introduction
1.1 CASE tools
1.2 Development and purpose of Data Flow Diagrams
2. Components of Data Flow Diagrams
2.1 Components
2.2 Hints on drawing
2.3 Data flows
3. Developing Data Flow Diagrams
3.1 Introduction
3.2 Context diagram
3.3 Level 1 Data Flow Diagram
3.4 Lower levels of Data Flow Diagrams
3.5 Check list
4. Categories of Data Flow Diagrams
4.1 Physical
4.2 Logical
4.3 The relationship between logical and physical Data Flow
Diagrams
5. An example of the development of a Data Flow Diagram
6. Process models
7. Summary
8. Activities
9. Bibliography
10. Commentary on activities
1.2 Development and purpose of DFDs
Before attempting to construct an initial DFD it is necessary to gather and digest information that helps us to understand how data is processed in the current system. Fact-finding techniques are used for this purpose and are discussed in another Unit. As the DFD is constructed a systems analyst will often come across areas of doubt where the precise way to model the system is unclear. This is a natural part of the development and should not be regarded with alarm. In fact, it is expected and it is a consequence of attempting to model the current situation that questions will be asked to clarify the exact processes which are taking place. Sometimes the analyst will make an assumption and then check this with the user at a subsequent meeting. Results of interviews, documents, reports, questionnaires etc. will all play a part in helping the analyst to gain an insight into the current processes. Where a system is being developed form scratch the analyst will work with the user to develop the proposed DFDs. When all the information about the current system is gather it should be possible to construct the DFDs to show:
- the information that enters and leaves the system
- the people/roles/other systems who generate and/or receive that information
- the processes that occur in the system to manipulate the information
- the information that is stored in the system
- the boundary of the system indicating what is (and what is not) included As a staring point, it is sometimes useful to construct a document flow diagram. This diagram shows how ‘documents’ are passed around an organisation to fulfil the current requirements of the system under investigation. The term’ documents’ is interpreted very loosely and usually translates to information. Sometimes before beginning to produce the set of data flow diagrams a document flow diagram is generated. This helps to establish the system boundary so we can decide which parts of the system we are modelling and which parts we are not. The document flow diagram shows the different documents (or information sources in the system and how they flow from a source to a recipient. Below is an example of a document flow diagram shown below. Here ellipses represent either the source or recipient of the ‘documents’ and named arrows show the direction of transfer and the nature of the information being exchanged. This kind of diagram is a first step in understanding what information is in the system and how it is used to perform the required functions. Another useful feature of the construction of this type of diagram is that it enables a sensible discussion of where the system boundary should lie. In other words it is important to establish what is to be included in the proposed information system and what is not. To indicate this, a system boundary line is constructed on the document flow diagram.
The DFDs are used to:
- discuss with the user a diagrammatic interpretation of the processes in the system and clarify what is currently being performed
- determine what the new system should be able to do and what information is required for each different process that should be carried out
- check that the completed system conforms to its intended design
2. Components of Data Flow Diagrams
The components of a Data flow Diagram are always the same but there are different diagrammatic notations used. The notation used here is one adopted by a methodology known as SSADM (Structured Systems Analysis and Design Methods)
2.1 Components
Luckily there are only four different symbols that are normally used on a DFD. These elements are:
- External entities
- Processes
- Data stores
- Data flows
The process symbol has three parts as shown in Figure 2. Figure 2 Process Box The process identifier is allocated so that each process may be referred to uniquely. The sequence of the process identifiers is usually unimportant but they are frequently to be seen as 1., 2., 3., etc. The top right hand section of the box is used to describe where the process takes place or who is doing the process. Examples of process boxes are given in Figure 3. Figure 3 Examples of process boxes The significance of the asterisk in the bottom right hand corner is discussed in section 3.3, Lower levels of Data Flow Diagrams. Data stores Data stores are places where data may be stored. This information may be stored either temporarily or permanently by the user. In any system you will probably need to make some assumptions about which relevant data stores to include. How many data stores you place on a DFD somewhat depends on the case study and how far you go in being specific about the information stored in them. It is important to remember that unless we store information coming into our system it will be lost. The symbol for a data store is shown in Figure 4 and examples are given in Figure 5. Where/who Process identifier Process name
Figure 4 Symbol for a data store Figure 5 Examples of possible data stores As data stores represent a person, place or thing they are named with a noun. Each data store is given a unique identifier D1, D2 D3 etc. Data flows The previous three symbols may be interconnected with data flows. These represent the flow of data to or from a process. The symbol is an arrow and next to it a brief description of the data that is represented. There are some interconnections, though, that are not allowed. These are:
- Between a data store and another data store o This would imply that one data store could independently decide to send some of information to another data store. In practice this must involve a process.
- Between an external entity and a data store o This would mean that an external entity could read or write to the data stores having direct access. Again in practice this must involve a process. Also, it is unusual to show interconnections between external entities. We are not normally concerned with information exchanges between two external entities as they are outside our system and therefore of less interest to us. Figure 6 shows some examples of data flows. Figure 6 Examples of data flows Data store identifier Data store description Applicant’s name Employee record Payment Customer details
there must be some way of accumulating data in the data store in the first place so it is unlikely there will be no writing to the data store.
- Data may flow from o External entity to process and vice-versa o Process to process o Process to data store and vice-versa
- No logical order is implied by the choice of id for the process. In the example process id’s start at
- There is no significance to this. Drawing diagrams like this requires practice. You should not be unduly worried if your diagram does not look exactly like a colleague’s or a model answer. Systems analysis is very rarely done in isolation and you and your working partners and the user will come to some agreement about the final product.
3. Developing Data Flow Diagrams
Data flow diagrams usually occur in sets. The set consist of different levels. To start with a context diagram is drawn. This shows the people and/or systems that interact with the system under construction. By interaction we mean putting information in or taking information out of our system. This diagram gives an overview of the information going in and coming out of the system. The system is represented by a box. In this DFD (level 0 DFD) no processes or data stores are shown. Another diagram (level 1 DFD) is now developed which shows the processes taking place to convert the inputs shown in the context diagram to the outputs. In this DFD detail is given to show which processes are responsible for accepting the different inputs and producing the different outputs. Any process shown that is complicated by a number of data flows and requires further refinement is shown on another diagram (level 2 DFD) where sub-processes are shown together with any necessary extra data
stores. Figure 8 shows how these levels of detail are related to one another. Figure 8 Different levels of DFD Box represents whole system boundary Context diagram (level 0 DFD) Level 1 DFD Level 2 DFD
Note the following features:
- Every data flow on the context diagram, to or from an external entity, is also shown on the Level 1 DFD.
- Each process has a good strong verb describing what the process is doing with the information received.
- Some data stores appear more than once. This is indicated by a double vertical line on the left hand side of the symbol.
- Each process has access to the relevant information to be able to produce the required output
- Each process has at least one data flow input and one output.
- Information input to the system is always stored somewhere and so never lost
- At this stage the invoice data store has an input data flow but no output. This would indicate that the invoice data is never used. Later on in the development of this system we might define a process for checking the invoices have been paid and so this information in the invoice data store would then be used.
- One of the processes (process 8) has no asterisk in the bottom right hand corner although all the others do. This is explained in the next section.
3.3 Lower levels of Data Flow Diagrams
Process 8 in Figure 10 is chosen to be investigated in more detail. A level 2 DFD is constructed of this process in Figure 11. Figure 11 A Level 2 DFD corresponding to Process 8 from the level 1 DFD in Figure 10 Process boundary
The diagram above is a child diagram of process 8 shown in Figure 10. Whenever a process is shown at the lowest level of detail it is called an elementary process. In SSADM this is indicated by an asterisk in the bottom right hand corner of the process box. As process 8 on Figure 10 has a child diagram, the asterisk has been removed by the CASE tool. You should note:
- All the data flows into and out of process 8 on the level 1DFD also appear on the level 2 DFD
- The numbering of the processes shown on the level 2 DFD 8.1, 8.2 etc. indicates that they are sub-processes of process 8.
- The name of the process, ‘Manage products’, is shown in the level 2 process boundary title. Only those processes that merit being expanded need to have level 2 DFDs associated with them. It is also possible to have lower levels of DFD dependent on how complex a particular process is. Although this example hasn’t had need for it, it sometimes happens that new data stores may be developed in the level DFD. Also new data flows may be shown between the elements inside the process boundary.
3.4 Check list
There are many errors that may occur when drawing data flow diagrams. Here is a check list to help you avoid some of the major difficulties.
- External entities must be people or systems that send information to or accept information form the system to be engineered
- Data flows must always be labelled with the data they contain. Do not put verbs in the data flow description as this implies a process
- Parent and child diagrams should be consistent. Do not show a data flow coming from or to an external entity on a level 1 DFD that isn’t shown on the context diagram (and vice versa).
- Check the direction of data flows to and from data stores
- Make sure each process has at least one input and one output
- Each data store should have at least one input and one output on the DFDs somewhere
- Each process name should start with a verb
- Where a process has only two data flows (one input and one output) then check it. Usually a data flow has been omitted.
4. Categories of Data Flow Diagrams
Data flow diagrams may be categorised as either physical or logical. A logical diagram shows how the business operates but not how the system will be constructed. The logical diagram omits details of how the more physical aspects are implemented. The logical model is more to do with the business whilst the
- Questionnaires o Gaining an overview of the required system and problem areas to be resolved Having gathered together information relating to the system to be built we may represent it in a textual description, as given below. Example Case Study – Pizza Supreme A large pizza business makes pizzas and sells them. The pizzas are manufactured and kept in cold storage for not more than two weeks. The business is split into a number of functional units. There is Production Control, Manufacturing, Stores, Accounts, Sales, Shipping and Purchasing. Production Control are responsible for organising which pizzas to produce in what order and in what quantity. They need to schedule the production of the pizzas according to the current and expected sales orders together with the number of pizzas already in Stores. Manufacturing take the raw materials from the Stores and manufacture pizzas returning the completed goods to the Stores. Accounts deal with the payments for the pizzas when delivered to the customer and the payment to the suppliers of the raw materials. Sales deal with customer orders whilst Purchasing organise the buying of raw material from suppliers. Shipping manage the packing and delivery of the goods to the customer with a delivery note. When a sales order is received by sales they record what is being ordered and by whom. They also record the details of the expected date of delivery. Production Control access this information and make sure that, if required, pizzas are produced by Manufacturing and are ready in Stores for when the delivery needs to be made. After the delivery is made Accounts make sure that the customer receives an invoice and that payment for the invoice is received at which time a receipt is issued. Purchasing look at the current stock of raw materials and by using current stock levels, supplier turn around times and quantity to be ordered decide what needs to be ordered on a daily basis. Their aim is never to run out of an ingredient but to minimise the amount of raw material kept in stock. Sometimes a document flow diagram may be drawn to show the way in which information flows around the system. Here is one shown below.
Some of the details here have been assumed and would need to be checked with the user to make sure they are a true reflection of what is happening. By producing this diagram the analyst is gaining an understanding of how the current system is working in terms of the information that is being used and how it is being passed around the system. Here we assume the system to be produced will include all the functions provided by the different functional areas but the suppliers and customers are regarded as being outside the system. Form this document flow diagram we may construct a context diagram. This will show the information entering and leaving the system. It also shows which external entities are supplying or
and make sure you understand why all the data flows are as they are. Check the diagram against the check list given in section 3.4. You should find this raises at least one problem that will need to be resolved! Check the level DFD is consistent with the level 1 DFD (its parent diagram). This completes the example showing how Data Flow Diagrams may be constructed. We have produced an outline of the processes that are currently occurring in the physical system. We could now continue to generate a set of current logical DFD’s and from there build a set of required logical DFD’s. Of course the required processes differ from the current processes in so much as when a new system is produced it should try to solve any of the current problems with the old system and also take advantage of any new innovations that may now exist due to the introduction of new technology. Now try Activities 5 and 6
6. Process models
So far we have discussed the meaning, use and construction of Data Flow Diagrams. They are very useful for recording the processes and functions that exist in the old and planning the processes and functions that should exist in the new system. The diagrams on their own are insufficient to describe the processes. Behind the diagrams should be a textual description showing detail of all the elements that appear on the diagrams. These are logged into what is known as a data dictionary. Any proprietary CASE tool will have the facility to record these items in a data dictionary. The DFD’s together with the data dictionary definitions are known as a process model. As an example here are some definitions of a data flow, an external entity and a process.
