Data flow diagram is a well known approach to visualize the data processing in business analysis field. A data flow diagram is strong in illustrating the relationship of processes, data stores and external entities in business information system.
ZERO DIAGRAM
- Describe the process of the DFD
- Provide views on the overall system in which, showing the main function or process that is, the flow of data and entity eskternal
- At this level of data storage possible
- For processes that do not detailed again on the next level then added the symbol '*' or 'P' at the end of the process
- Input and output balance (balancing) between 0 to diagram context diagram should be maintained
The goal of zero diagram is to “break down” a system to “processes” that must be done ‘in person’. Or, if made in the sentence is: “What is the process that must be done in order to reach the system?.”
Thus, this diagram is the continuation of the context diagram, which “extend the circle,” and for (the number and content) and the terminator (the amount and content) data flow to and from the terminator should be fixed.
DETAILED DIAGRAM
Diagram is a detailed diagram of the process of decipher what is in a chart or diagram zero level above.
Numbering level in the DFD:
| Level Name | Diagram Name | Process Number |
| 0 | Context | |
| 1 | Diagram 0 | 1.0, 2.0, 3.0, … |
| 2 | Diagram 1.0 | 1.1, 1.2, 1.3, … |
| 3 | Diagram 1.1 | 1.1.1, 1.1.2, … |
EXTERNAL ENTITIES
Something that is outside the system, but it provides data into the system or providing data from the system, is represented with a notation box. External entity does not include part of the system. When the information system is designed for one section (department) then the other part that is still a relevant external entity.
Guidelines of external entities:- The name of the form of noun
- Terminal may not have the same name unless the object is the same (described twice, is intended to make the diagram more clear). If so, then the terminal should be a forward slash in the top left corner.
SPECIFICATION PROCESS
- Each process in the DFD must have a specification process.
- At the top level method is used to describe the process you can use with descriptive sentences.
- At a more detailed level, namely on the bottom (functional primitive) require a more structured specification.
- Specification process will be the guideline for the programmer to make this program (coding).
- Method used in the specification process: the process of disintegration in the form of a story, decision table, decision tree.
DATA FLOW
Flow data consist of a group of related data elements in a logical move from one process to another process.
- Depicted with a straight line connecting the components of the system.
- Flow data is shown with the direction arrows and the name on the flow of data that flows.
- Cash flow of data between processes, saving data, the unit outside, and shows data flow from data in the form of inputs to the system.
- Guidelines of the name:
1. Name of the flow of data that consists of some words associated with the flow lines connect.
2. No flow data for the same and the name should reflect its content
3. The flow of data that consists of several elements can be expressed with the group element
4. Avoid using the word 'data' and 'information' to give a name to the flow of data
5. Wherever possible the complete flow of data is written
6. Name of the flow of data into a process may not be the same as the name of the data flow out of the process
7. Data flow into or out of data storage does not need to be given a name if:
- Flow of data simple and easy to understand
- Flow of data describes all data items
8. There can be no flow of data from the terminal to the data storage, or vice versa because the terminal is not part of the system, the relationship with the terminal data storage must be through the process.
PROCESS
Logical process models omit any processes that do nothing more than move or route data , thus leaving the data unchanged.
Valid processes include those that:
· Perform computations (e.g., calculate grade point average)
· Make decisions (determine availability of ordered products)
· Sort, filter or otherwise summarize data (identify overdue invoices)
· Organize data into useful information (e.g., generate a report or answer a question)
· Trigger other processes (e.g., turn on the furnace or instruct a robot)
· Use stored data (create, read, update or delete a record)
Guidelines of the process:
- Name of the process consists of a verb and noun, which reflects the function of the process
- Do not use the process as part of the name of a bubble
- May not have some process that has the same name
- The process should be given a number. Order number wherever possible to follow the flow of the process or sequence, but the sequence number does not mean that the absolute is a process in chronological order
The Process Symbol
Processes transform or manipulate data. Each box has a unique number as identifier (top left) and a unique name (an imperative - e.g. 'do this' - statement in the main box area) The top line is used for the location of, or the people responsible for, the process.
Processes are 'black boxes' - we don't know what is in them until they are decomposed
Processes transform or manipulate input data to produce output data. Except in rare cases, you can't have one without the other.
DFD Levels
The Context and Top Level diagrams in the example start to describe 'Home Catalogue' type sales system. The two diagrams are just the first steps in creating a model of the system. (By model we mean a co-ordinated set of diagrams which describe the target system and provide answers to questions we need to ask about that system).As suggested the diagrams presented in the example will be reworked and amended many times - until all parties are satisfied. But the two diagrams by themselves are not enough; they only provide a high level description. On the other hand, the initial diagrams do start to break down, decompose, what might be quite a complex system into manageable parts.
A revision of the example Top Level DFD
The next step - the Next Level(s)
Each Process box in the Top Level diagram will itself be made up of a number of processes, and will need to be decomposed as a second level diagram.
Decomposition stops when a process box can be described with an Elementary Process Description using ordinary English, later on the process will be described more formally as a Function Description using, for example, pseudocode.
DATA STORAGE
In physical DFDs there can be 4 types.
D = computerised Data
M = Manual, e.g. filing cabinet.
T = Transient data file, e.g. temporary program file
T(M) = Transient Manual, e.g. in-tray, mail box.
As with external entities, it is common practice to have duplicates of data stores to make a diagram less cluttered
DFD SYMBOLS
DATA DICTIONARY
A data dictionary is a collection of descriptions of the data objects or items in a data model for the benefit of programmers and others who need to refer to them. A first step in analyzing a system of objects with which users interact is to identify each object and its relationship to other objects. This process is called data modeling and results in a picture of object relationships. After each data object or item is given a descriptive name, its relationship is described (or it becomes part of some structure that implicitly describes relationship), the type of data (such as text or image or binary value) is described, possible predefined values are listed, and a brief textual description is provided. This collection can be organized for reference into a book called a data dictionary.
When developing programs that use the data model, a data dictionary can be consulted to understand where a data item fits in the structure, what values it may contain, and basically what the data item means in real-world terms. For example, a bank or group of banks could model the data objects involved in consumer banking. They could then provide a data dictionary for a bank's programmers. The data dictionary would describe each of the data items in its data model for consumer banking (for example, "Account holder" and ""Available credit").
BALANCING IN DATA FLOW DIAGRAM
The flow of data into and out of a process must be the same as the flow of data into and out of the details of the process on the level / levels below it. Name of the data flow into and out of the process must match the name of the flow of data into and out of the details of the process. Number and the name of an entity outside the process must be equal to the number of names and entities outside of the details of the process. The issues that must be considered in the DFD which have more than one level:
1. There must be a balance between input and output of one level and the next level.
2. Balance between level 0 and level 1 at the input / output of stream data to or from the terminal on level 0, while the balance between level 1 and level 2 is seen on the input / output of stream data to / from the process concerned.
3. Name of the flow of data, data storage and terminals at each level must be the same if its object same.
PROHIBITION IN DFD
1. Data flow may not from external entity directing to external entity another without via a process
2. Data flow may not of direct data storage make towards external entity without via a process
3. Data flow may not of direct data storage wend another data trove without via a process
4. Data flow of one process directing to wend another process without via an advisable data storage / one can maybe be avoided
Refrences:
ER Ngurah Agus Sanjaya, S.KOM, M.KOM. Slide Part 4 - DATA FLOW DIAGRAM.
HM, Jogiyanto. 2005. Analisis & Desain Sistem Informasi.
http://www.edrawsoft.com/Data-Flow-Diagram-Symbols.php
http://www.cems.uwe.ac.uk/~tdrewry/dfds.htm
http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci211896,00.html
http://facweb.cs.depaul.edu/yele/Course/IT215/DFD%20Mechanics.ppt
well explained, you can find some good context, level 0 and level 1 data flow diagrams in creately diagram community to be used freely.
BalasHapus