29-05-2010, 04:01 PM
DATA FLOW DIAGRAMS.ppt (Size: 69 KB / Downloads: 425)
¢ DATA FLOW DIAGRAMS
¢ Systems Analysis
¢ Focus is the logical view of the system, not the physical
¢ What the system is to accomplish, not how
¢ Tools:
“ data flow diagrams
“ data dictionary
“ process specification
“ entity-relationship diagrams
¢ Data Flow Diagram:
"a network representation of a system. The system may be automated, manual, or mixed. The DFD portrays the system in terms of its component pieces, with all interfaces among the components indicated."
- Tom DeMarco
hence DFDs:
focus on the movement of data between external entities and processes, and between processes and data stores
¢ Example Data Flow Diagram
¢ Data Flow Diagrams are:
¢ Used to perform structured analysis to determine logical requirements
¢ A graphical tool, useful for communicating with users, managers, and other IS personnel
¢ Useful for analyzing existing as well as proposed systems
¢ A relatively simple technique to learn and use
¢ Why Conduct Process Modeling?
¢ Understand components of current logical or physical system for purpose of rebuilding in a different physical form/technology, possibly with some changed functionality
¢ Find inefficiencies in current system
¢ Re-engineer current system
¢ Sources/Sinks
(external entities)
¢ Any class of people, an organization, or another system which exists outside the system you are studying.
¢ Form the boundaries of the system.
¢ The system and external entities exchange data in the form of data flows.
¢ Must be named, titles preferred to names of individuals - use a noun
¢ Data Flows
¢ data in motion
¢ marks movement of data through the system - a pipeline to carry data
¢ connects the processes, external entities and data stores
¢ Unidirectional
¢ originate OR end at a process (or both)
¢ name as specifically as possible - reflect the composition of the data - a noun
¢ do not show control flow! Control flow is easy to identify- a signal with only one byte - (on/off).
¢ HINT: if you can't name it: either it's control flow, doesn't exist or you need to get more information!
¢
¢
¢
¢ Processes
¢ transform incoming data flows into outgoing data flows
¢ represent with a bubble or rounded square
¢ name with a strong VERB/OBJECT combination; examples:
create_exception_report
validate_input_characters
calculate_discount
¢ Data Stores
¢ data at rest
¢ represents holding areas for collection of data, processes add or retrieve data from these stores
¢ name using a noun (do not use ˜file™)
¢ only processes are connected to data stores
¢ show net flow of data between data store and process. For instance, when access a DBMS, show only the result flow, not the request
¢
¢
¢
¢ Data Flow Diagram Don™ts
1. BLACK HOLES
2. MIRACLES
3. Let it get too COMPLEX: 7 ± 2 processes
4. Leave things UNLABELED
(corollary: labels should have meaning)
5. Data stores that are SOURCES or
SINKS
6. Data flows that are UNASSOCIATED with
a PROCESS
7. Expect your diagram to be perfect the
first time!
¢ Data Flow Diagram Don™ts
¢ Data Flow Diagram Don™ts
¢ Data Flow Diagram Don™ts
¢ Data Flow Diagram Don™ts
¢ Diagramming A System
¢ multiple DFDs are required to represent a system
¢ DFDs are created at increasing levels of detail
¢ Different Types of DFDs
¢ Context diagram
¢ Level-0 diagram (system diagram)
¢ Level-n diagram
¢ Primitive diagram
¢ Context Diagram
¢ defines the scope of the system by identifying the system boundary
¢ contains:
“ one process (which represents the entire system)
“ all sources/sinks (external entities)
“ data flows linking the process to the sources and sinks (external entities)
¢ Example Context Diagram
¢ Constructing a Context Diagram
¢ identify and list sources/sinks (external entities)
¢ identify and list inputs to and outputs from sources/sinks (external entities)
¢ create context diagram
¢ Level-0 Diagram
¢ describes the overall processing of the system
¢ show one process for each major processing step or functional requirement
¢ data flows from the context appear on system diagram also (level balancing)
¢ can show a single data store to represent all data in aggregate at this level
¢ can draw duplicate sources, sinks and data stores to increase legibility
¢ Drawing a Level-0 Diagram
¢ list the major data stores
¢ list major business steps
¢ draw a segment for each business step
¢ assemble into single DFD
¢ re-organize until satisfied
¢ number processes
¢ Functional Decomposition
¢ similar to a series of more detailed maps
¢ iterative process of breaking the description of a system into finer and finer detail to create a set of charts in which one process on a given chart is explained in greater detail on another chart
¢ referred to as exploding, partitioning, or leveling
¢ must use your judgment to decide what goes on each level
¢ show error and exception handling on lower levels (if at all)
¢ Lower Level Diagrams
¢ explode the processes shown on the level-0 diagram
¢ each process is represented by its own DFD
¢ balance data
“ data flows on upper level appear on lower level, or
“ data flows on upper level are broken into component pieces with components shown on lower level
¢ each lower level shows greater and greater detail
¢ follow numbering convention
¢ Balancing DFDs
¢ conserve data from level to level - inputs and outputs on the higher level must appears somewhere on the lower level
¢ Advanced Rules
¢ Composite data flow on one level can be split into its component data flows on the next level - but new data cannot be added and all data in the composite must be included in the sub-flows
¢ The inputs to a process must be sufficient to produce the outputs.
¢ Lowest level DFDs may add new data flows to represent exception handling, i.e., error messages
¢ May repeat data stores or sources/sink to avoid crossing lines
¢ Additional Guidelines
¢ the inputs to a process are different from the outputs of that process
¢ objects in a set of DFDs have unique names
¢ do not change data flow names on lower levels unless you are decomposing a data flow into component pieces.
¢ never explode a single process into another single process. If you cannot partition the process, then the lower level DFD is not needed.
¢ expect to iterate, put down the DFD and go back to it a few times to create something satisfactory.
¢ Other Questions about Lower level diagrams
1. How deep? (how many levels?)
“ if the process has only one input or one output, probably cannot partition further;
“ can you describe the process in English in about 1/2 page?
2. How broad? (how many processes on a level?)
“ 7 ± two is a reasonable heuristic
“ may temporarily place much of the system on a single diagram then re-draw into separate levels
¢ Quality Guidelines
¢ Completeness
“ all components included & in project dictionary
¢ Consistency
“ between levels: balancing, leveling
¢ Timing considerations
“ assume system never starts and never stops
¢ Iterative nature
“ revisions are common
¢ Drawing primitives (lowest level)
“ when to stop?