Data Flow Diagrams - PowerPoint PPT Presentation

Loading...

PPT – Data Flow Diagrams PowerPoint presentation | free to download - id: 3c330f-MGMxN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Data Flow Diagrams

Description:

* * * * * * * * * * * * * * * * * * * * * A data flow diagram (DFD) is a graphical representation of the – PowerPoint PPT presentation

Number of Views:158
Avg rating:3.0/5.0
Slides: 24
Provided by: angelwolf
Learn more at: http://www.angelwolfe53.com
Category:
Tags: data | diagrams | flow

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Data Flow Diagrams


1
Data Flow Diagrams
  • Trisha Cummings

2
What are Data Flow Diagrams?
  • A data flow diagram (DFD) is a graphical
    representation of the "flow" of data through an
    information system.
  • A data flow diagram can also be used for the
    visualization of data processing (structured
    design).
  • It is common practice for a designer to draw a
    context-level DFD first which shows the
    interaction between the system and outside
    entities.
  • This context-level DFD is then "exploded" to
    show more detail of the system being modeled

3
Data Flow Diagram Symbols
  • There are only four symbols
  • Squares representing external entities, which are
    sources or destinations of data.
  • Rounded rectangles representing processes, which
    take data as input, do something to it, and
    output it.
  • Arrows representing the data flows, which can
    either be electronic data or physical items.
  • Open-ended rectangles representing data stores,
    including electronic stores such as databases or
    XML files and physical stores such as or filing
    cabinets or stacks of paper.

4
(No Transcript)
5
  • Data flow diagrams can be used to provide a clear
    representation of any business function.
  • The technique starts with an overall picture of
    the business and continues by analyzing each of
    the functional areas of interest.
  • This analysis can be carried out to precisely the
    level of detail required.

6
Common Modeling Rules
  • All processes must have at least one data flow in
    and one data flow out.
  • All processes should modify the incoming data,
    producing new forms of outgoing data.
  • Each data store must be involved with at least
    one data flow.
  • Each external entity must be involved with at
    least one data flow.
  • A data flow must be attached to at least one
    process.

7
Ways to develop a DFD
  • Top-Down Approach
  • Event Partitioning Approach

8
Top-Down Approach
  • The system designer makes a context level DFD,
    which shows the interaction (data flows) between
    the system (represented by one process) and the
    system environment (represented by terminators).
  • The system is decomposed in lower level DFD
    (Zero) into a set of processes, data stores, and
    the data flows between these processes and data
    stores.
  • Each process is then decomposed into an even
    lower level diagram containing its sub processes.
  • This approach then continues on the subsequent
    sub processes, until a necessary and sufficient
    level of detail is reached which is called the
    primitive process (aka chewable in one bite).

9
Event Partitioning Approach
  • This approach was described by Edward Yourdon in
    Just Enough Structured Analysis
  • Construct detailed DFD.
  • The list of all events is made.
  • For each event a process is constructed.
  • Each process is linked (with incoming data flows)
    directly with other processes or via data stores,
    so that it has enough information to respond to a
    given event.
  • The reaction of each process to a given event is
    modeled by an outgoing data flow

10
  • As an aid in developing DFDs, consider the
    following description of processing steps.

11
Advantages to using a DFD
  • Data flows and process consequences.
  • Wherever we start in the process, we can
    understand the processing steps that the needed
    to take to complete the relevant transaction(s)
    and to inform its constituents of the results.
  • Data inputs and outputs.
  • The DFD also makes it possible to understand what
    data are needed to provide appropriate inputs to
    any processing step.

12
  • Simplifying complexity by isolating process
    components.
  • The DFD would make it easier to capture the
    detail of such data flows.
  • At the time that DFDs were developed, this shift
    towards modularizing data flows and processing
    elements represented a major step forward in
    enabling systems analysts to add useful structure
    to process representations rapidly and easily.

13
Common DFD Mistakes
  • Illegal data flows
  • Illegal data flows
  • DFDs are not flow charts

14
Illegal data flows
  • One of the patterns of data flow analysis is that
    all flows must begin with or end at a processing
    step.
  • This makes sense, since presumably data cannot
    simply metastasize on its own without being
    processed (in spite of the circumstantial
    evidence we might have gathered in our own
    business experience...).
  • This simple rule means that the following
    mistakes can be fairly easily identified and
    corrected in a DFD.
  • The symbols shown on the next slide are
    purposefully left blank (e.g., without captions)
    so that it is easier for you to recognize
    patterns such as these in your own DFDs.

15
(No Transcript)
16
Black holes, grey holes, and miracles
  • A processing step may have input flows but no
    output flows. This situation is sometimes called
    a black hole .
  • A processing step may have output flows but now
    input flows. This situation is sometimes called a
    miracle.
  • A processing step may have outputs that are
    greater than the sum of its inputs - e.g., its
    inputs could not produce the output shown. This
    situation is sometimes referred to as a grey
    hole.

17
(No Transcript)
18
DFDs are not flow charts
  • Many of us have had prior experience developing
    flow charts. Flow chart diagrams can be useful
    for describing programming logic or understanding
    a single sequence of process activities.
  • It is important to recognize, however, that DFDs
    are not flow charts.
  • Flow charts often show both processing steps and
    data "transfer" steps (e.g., steps that do not
    "process" data) DFDs only show "essential"
    processing steps.
  • Flow charts might (indeed, often do) include
    arrows without labels DFDs never show an unnamed
    data flow.
  • Flow charts show conditional logic DFDs don't
    (the conditional decisions appear at lower
    levels, always within processing steps).
  • Flow charts show different steps for handling
    each item of data DFDs might include several
    data items on a single flow arrow.

19
(No Transcript)
20
(No Transcript)
21
Who makes DFD tools?
  • ConceptDraw - Windows and MacOS X data flow
    diagramming tool
  • Dia - Free source diagramming tool with flowchart
    support
  • Kivio - Free source diagramming tool for KDE
  • Microsoft Visio - Windows diagramming tool which
    includes very basic DFD support (Images only,
    does not record data flows)
  • SILVERRUN ModelSphere - cross-platform tool for
    business process modelling and data flow
    diagramming
  • SmartDraw - Windows diagraming tool with "Yourdon
    and Coad Process Notations" and "Gane and Sarson
    Process Notation"

22
Resources
  • Data Flow Diagrams
  • http//en.wikipedia.org/wiki/Data_flow_diagram
  • Agile Modeling
  • http//www.agilemodeling.com/artifacts/dataFlowDia
    gram.htm
  • EDrawSoft Data Flow Diagrams
  • http//www.edrawsoft.com/Data-Flow-Diagrams.php

23
More Sources
  • Data flows Note on Data-Driven Process Modeling
  • http//faculty.babson.edu/osborn/mis7520/readings/
    dfddiag.htm
About PowerShow.com