Process modeling was founded in the structured analysis and design methodologies in 1978. Process modeling focuses on the Process part of a system. Flowcharts are one type of process model. Data flow Diagrams and structure charts have contributed significantly to reduce the communication gap that often exists between non-technical system designers and builders.
A model is a representation of reality that can be built for existing systems as a way to better understand those systems or for proposed systems as a way to document business requirement or technical designs.
Logical models show what a system is or does. They are implementation-independent; that is, they depict the system independent of any technical implementation.
Physical models show not only what a system is or does but also how the system is physically and technically implemented. They are implementation-dependent because they reflect technology choices and the limitation of those technology choices.
System analysis activities tend to focus on the logical system models for the following reasons :
- Logical models remove biases that are the result of the way the current system is
- Logical models reduce the risk of missing business requirement because of preoccupied technical details. Such errors can be costly to correct after the system is implemented. By separating what the system must do from how the system will do it, we can better analyze the requirements for completeness, accuracy and consistency.
- Logical models allow us to communicate with end users in non-technical or less technical languages. Thus, we don’t lose requirements in the technical jargon of the computing discipline.
Process modeling is a technique for organizing and documenting the structure and flow of data through a system’s process, policies, and procedures to be implemented by a system’s processes.
A data flow diagram (DFD) is a tool that depicts the flow of data through a system and the work or processing performed by that systeni. Data flow diagrams are also called bubble charts, transformation graph, and process model.
Diagrammatic representation of data helps in two ways:
- It helps the analysts to analyze the system and to model system components.
- An analyst can communicate better with the user. It is easier for the user to understand and how the analyst has interpreted his/her problem after looking at DFD’s.
Components of DFD
Just like flowcharts, Data flow diagram use standard symbols to represent different components. Following are the components of data flow diagrams :
- Data flow
- Data stores
- External Entities.
Processes show what systems do. Each process has one or more data inputs and produces one or more data outputs. In order to obtain the relevant information from data, it has to be processed. Data may be represented in a single step or process or by a number of processes. Circles in a DFD represent processes. Each process has a unique name and number which appear inside the circle that represent the process.
External entities are outside the system, but they either supply input data into the system or use the system output. They are entities over which the designer has no control. They may be an organization’s customer or other bodies with which the system interacts.
External entities that supply data into the system are sometimes called sources. External entities that use system data are sometimes called sinks.
A file or data store is a repository of data. It contains data that is retained in the system.
Data is always stored on some physical medium. In case of manual systems, data is stored in paper file. In automated system, data is stored on mediums like hard disk, floppy disk or magnetic tapes etc. Process can enter data into a data store or retrieve data from the data store. Two parallel lines in the DFD represent each data store and each data store has a unique name.
Data stores form an essential part of the system and hence of DFD.
Data flows model the passage of data in the system and are represented by lines joining system components. The direction of the flow is indicated by an arrow and the line is labelled by the name of the data flow. Flow of data in the system can take place:
- Between two processes.
- From a data store to a process.
- From a process to a data store
- From a source to a process; and
- FroM a process to a sink.
If an organization works to improve a business process, it must first understand it. Process modeling tools are used to represent the key elements of a process so that it can be better understood.
Now let us illustrate how systems are modeled using these symbols. A common way to begin is to model the whole system by one process. The DFD that does this is known as the context diagram. It shows all the external entities that interact with the system and the data flows between these external entities and the system.
Figure above is an example of a context diagram. It models the ‘budget monitoring system’. This system interacts with three external entities: DEPARTMENTS, MANAGEMENT and SUPPLIERS. In figure, the main data flows from DEPARTMENTS are ‘spending request’. In response, DEPARTMENTS either receive `rejected request’ data flows or ‘delivery advice’ data flows. MANAGEMENT receives `request for special approval’ data flows to which it responds’. MANAGEMENT also sends ‘budget allocation’ data flows to the system and gets ‘spending summaries’ data flows. Suppliers receive ‘part order’ data flows and return ‘supplier delivery advice’ data flows.
Context diagram does not describe the system in detail. In order to identify the major system processes, a DFD that shows the major system processes is called top-level DFD. The top-level DFD shows the various processes that make up the system. Each process has a unique name and number.
Figure below shows the top-level DFD :
In this DFD we see that data flow ‘spending request’ from DEPARTMENTS goes to the ‘check funding’ process. This process looks up the allocated budget and determines whether special permission is needed from MANAGEMENT to proceed with the request. Approved request goes to the ‘classify expenditure’ process where they are entered into data stores, DEPARTMENTAL-ACCOUNTS and TYPE-ACCOUNTS. Finally, if required, a ‘part order’ for parts originally specified in a ‘spending request’ is placed with suppliers. There are also two other processes; one is to ‘set up budget’ and the other is to `provide spending summaries’.
Guidelines for Drawing Data Flow Diagram
Data flow diagram can easily become quite complex; therefore, it is often helpful to follow a set of general guidelines. Following rules should be kept in mind for designing a good DFD :
- Should have no crossing lines.
- Should not split into a number of data flows.
- Should have no any flowchart structure like decision, iteration etc.
- Do not include control or flow of control information.
- Do not try to put too much information in one data flow diagram.
- Data flows can only be from:
- External entity to process
- Process to external entity
- Process to process
- Process to stores
- Stores to process
- Naming conversion should be kept in mind:
- Name should be meaningful.
- Process name should be one single phrase and should not be general.
- Data flows should be named as one word.
Advantages of Using DFD’s
- Represent data flows.
- May be used at. high or low level of analysis.
- Provide good system documentation.