A Data Flow Diagram is intended to serve as a communication tool among
1. systems analysts
2. end users
3. data base designers
4. system programmers
5. other members of the project team
A data flow diagram (DFD) is a graphical tool that allows system analysts (and system users) to depict the flow of data in an information system.
The DFD is one of the methods that system analysts use to collect information necessary to determine information system requirements.
Data flow diagram (DFD) is a picture of the movement of data between external entities and the processes and data stores within a system
Example
Source/Sink (External Entity)
External entity that is origin or destination of data (outside the system)
Is the singular form of a department, outside organization, other IS, or person
Labels should be noun phrases
Source – Entity that supplies data to the system
Sink – Entity that receives data from the system
DFD Symbols
Entity Symbol
- Symbol is a rectangle, which may be shaded to make it look three-dimensional
- An entity name is the singular form of a department, outside organization, other information system, or person
- Name of the entity appears inside the symbol
- A DFD shows only the external entities that provide data to the system or receive output from the system
- can be duplicated, one or more times, on the diagram to avoid line crossing.
- determine the system boundary. They are external to the system being studied. They are often beyond the area of influence of the developer.
- go on margins/edges of data flow diagram
- Entities also called
- Terminators: because they are data origins or final destination
- Source: for entity that supplies data to the system
- Sink: for entity that receives data from the system
Rules for Entity
- External people, systems and data stores
- Reside outside the system, but interact with system
- Either a) receive info from system, b) trigger system into motion, or c) provide new information to system
- e.g. Customers, managers
- Not clerks or other staff who simply move data
- Must be connected to a process by a data flow
- Entity can be connected with a process only
Data store symbol
- Represent data that the system stores
- A DFD does not show the detailed content of data store
- The physical characteristics of a data store are unimportant because you are concerned only with a logical model
- Is a flat rectangle that is open on the right side and closed on the left side
- A data store name is a plural name consisting of a noun and adjectives, if needed
- can be duplicated, one or more times, to avoid line crossing.
- is detailed in the data dictionary
- Rules for Data store
- Internal to the system
- Data at rest
- Include in system if the system processes transform the data
- Store, Add, Delete, Update
- Very data store on DFD should correspond to an entity on an ERD
- Data stores can come in many forms:
- Hanging file folders
- Computer-based files
- Notebooks
- Must have at least one incoming and one outgoing data flo
- Is used in a DFD to represent data that the system stores
- Labels should be noun phrases
- A data store must be connected to process with a data flow
- A data store must have at least one incoming and one outgoing data flow
- One exception when data store has no input data flow because it contains fixed reference data that is not updated by the system
Data Flow Symbol
A data flow is a path for data to move from one part of the information system to anther
- Represents one or more data items
- The detailed content of the data flow does not appear in the DFD
- The symbol for a data flow is a line with a single or double arrowhead
- A data flow name consists of a singular noun and an adjective, if needed
- Is detailed in the data dictionary
- Is a path for data to move from one part of the IS to another
- Arrows depicting movement of data
- Can represent flow between process and data store by two separate arrows
Rules for Data Flow
Data in motion, moving from one place to another in the system
- From external entity (source) to system
- From system to external entity (sink)
- From internal symbol to internal symbol, but always either start or end at a process
- A join means that exactly the same data comes from any two or more different processes, data stores or sources/sinks to a common location
- A data flow cannot go directly back to the same process it leaves
- A data flow to a data store means update
- A data flow from a data store means retrieve or use
- A data flow has a noun phrase label
At least one data flow must enter and one data flow must exit each process symbol
Process Symbol
- Work or actions performed on data (inside the system)
- Labels should be verb phrases
- Receives input data and produces output
- Receives input data and produces output that has a different content, form, or both
- Contain the business logic which determines how a system handles data and produces useful information. Business logic, also called business rules, reflect the operational requirements of the business.
- Process name identifies a specific function and consists of verb, and an adjective, if necessary
- a process symbol can be referred to as a black box, because the inputs, outputs, and general functions of the process are known, but the underlying details and logic of the process are hidden
Rules for Process
- Always internal to system
- Law of conservation of data:
- Data stays at rest unless moved by a process.
- Processes cannot consume or create data
- Must have at least 1 input data flow (to avoid miracles)
- Must have at least 1 output data flow (to avoid black holes)
- Should have sufficient inputs to create outputs (to avoid gray holes)
- Can have more than one outgoing data flow or more than one incoming data flow
- Can connect to any other symbol (including another process symbol)
- 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)
Types of Data Flow Diagram
Context Diagram
A data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system
Level-O Diagram
Creating DFDs is a highly iterative process of gradual refinement.
General steps:
1. Create a preliminary Context Diagram
2. Identify Use Cases, i.e. the ways in which users most commonly use the system
3. Create DFD fragments for each use case
4. Create a Level 0 diagram from fragments
5. Decompose to Level 1,2,…
6. Go to step 1 and revise as necessary
7. Validate DFDs with users.
DFD Rules—General
- Basic rules that apply to all DFDs
- Inputs to a process are always different than outputs
- Objects always have a unique name
- In order to keep the diagram uncluttered, you can repeat data stores and sources/sinks on a diagram
DFD Rules—Context Diagram
- One process, numbered 0.
- Sources and sinks (external entities) as squares
- Main data flows depicted
- No internal data stores are shown
- They are inside the system
- External data stores are shown as external entities
- How do you tell the difference between an internal and external data store?
Top-level view of IS
Shows the system boundaries, external entities that interact with the system, and major information flows between entities and the system.
Example: Order system that a company uses to enter orders and apply payments against a customer’s balance
DFD Rules – Level 0
- Shows the system’s major processes, data flows, and data stores at a high level of abstraction
- When the Context Diagram is expanded into DFD level-0, all the connections that flow into and out of process 0 needs to be retained.
Lower Level Diagrams
- Functional Decomposition
- An iterative process of breaking a system description down into finer and finer detail
- Uses a series of increasingly detailed DFDs to describe an IS
- When decomposing a DFD, you must conserve inputs to and outputs from a process at the next level of decomposition. This is called balancing.
Functional decomposition
- Act of going from one single system to many component processes
- This is a repetitive procedure allowing us to provide more and more detail as necessary
- The lowest level is called a primitive DFD
Level-N DiagramsLevel-N Diagrams
A DFD that is the result of n nested decompositions of a series of subprocesses from a process on a level-0 diagram
DFD Rules—Balancing DFDs
DFD Rules—Balancing DFDs
- Balancing
- The conservation of inputs and outputs to a data flow process when that process is decomposed to a lower level
- Ensures that the input and output data flows of the parent DFD are maintained on the child DFD
A Balance Example
- We have the same inputs and outputs
- No new inputs or outputs have been introduced
- We can say that the context diagram and level-0 DFD are balanced
An unbalance Example
- In context diagram, we have one input to the system, A and one output, B
- Level-0 diagram has one additional data flow, C
- These DFDs are not balanced
Example Level 0
Example Level 1
Strategies for Developing DFDs
- Top-down strategy
- Create the high-level diagrams (Context Diagram), then low-level diagrams (Level-0 diagram), and so on.
- Bottom-up strategy
- Create the low-level diagrams, then higher-level diagrams
- During data and process modeling, a systems analyst develops graphical models to show how the system transforms data into useful information
- Data flow diagrams (DFDs) graphically show the movement and transformation of data in the information system
- DFDs use four symbols: the process symbol transforms data; the data flow symbol shows data movement; the data store symbol shows data at rest; and the external entity symbol represents someone or something connected to the information system
- Various rules and techniques are used to name, number, arrange, and annotate the set of DFDs to make them consistent and understandable
Works Cited
- Rosenblatt, H. J. (2013). Systems Analysis and Design. Boston, MA 02210, USA: Cengage Learning.
- SERAI, P. S. (2017, April 1). Chapter summary data flow diagrams dfds graphically. Retrieved from https://www.coursehero.com: https://www.coursehero.com/file/p5tdf33/Chapter-Summary-Data-flow-diagrams-DFDs-graphically-show-the-movement-and/
- Shelly, G., & Rosenblatt, H. J. (2009). Systems Analysis and Design. Boston, MA 02210, USA: Cengage Learning.
No comments:
Post a Comment