Data Flow Diagrams (DFDs)

http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm In the late 1970s data-flow diagrams (DFDs) were introduced and popularized for structured analysis and design (Gane and Sarson 1979).  DFDs show the flow of data from external entities into the system, showed how the data moved from one process to another, as well as its logical storage. Figure 1 presents an example of a DFD using the Gane and Sarson notation.  There are only four symbols: Squares representing external entities, which are sources or destinations of data. Rounded rectangles representingprocesses, which take data as input, do something to it, and output it. Arrows representing thedata flows, which can either be electronic data or physical items. Open-ended rectangles representingdata stores, including electronic stores such as databases or XML files and physical stores such as or filing cabinets or stacks of paper.

Figure 1. Enrolling in the university.

To create the diagram I simply worked through a usage scenario, in this case the use case logic described in theEnroll in University system use case.  On actual projects it抯 far more common just to stand at a whiteboard with one or more project stakeholders and simply sketch as we talk through a problem.

In this case I started with the applicant, the external entity in the top left corner, and simply followed the flow of data throughout the system.  I introduced theInspect Forms process to encapsulate the initial validation steps.  I assigned this process identifier 1.0, indicating that it抯 the first process one the top level diagram.  A common technique with DFDs is to create detailed diagrams for each process to depict more granular levels of processing.  Were I to do this for this process I would number the subprocesses 1.1, 1.2, and so on.  Subprocesses of 1.1 would be numbered 1.1.1, 1.1.2, and so on.  I wouldn抰 bother to expand this process to more detailed DFD as it is fairly clear what is happening in it and therefore the new diagram wouldn抰 add any value.  I also indicated who/what does the work in the bottom section of the process bubble, in this case the registrar.  This information is optional although very useful in my experience.  You can see how the improperly filled out forms are returned to the applicant if required. 

I then continued to follow the logic of the use case, concentrating on how the data is processed by each step.  The second process encapsulates the logic for creating a student record, including the act of checking to see it the person is eligible to enroll as well as if they抮e already in the database.  Notice how each data flow on the diagram has been labeled.  Also notice that the names of the data change to reflect how it抯 been processed.

Now that I look closer at the diagram the arrow between the Input Student Information process and the Student DB data store should be two-way because this process searches the database for existing student records.  Unfortunately I抳e erased this diagram from my whiteboard so it isn抰 easy to address this minor problem.  Yes, I could use a drawing program to update the arrowhead but its more important to make the point that agile models don抰 need to be perfect, they just need to be good enough.  AM recommends that you follow the practiceUpdate Models Only When it Hurts and in this case this issue doesn抰 hurt enough to invest the two or three minutes it would take to fix the diagram.

The Collect Fees process is interesting because it interacts with an electronic data store,Financial DB, as well as a physical one,Cash Drawer.  DFDs can be used to model processes that are purely physical, purely electronic, or more commonly a mix of both.  Electronic data stores can be modeled via data models, particularly if they represent a relational database.  Physical data stores are typically self explanatory.

There are several common modeling rules that I follow when creating DFDs:

1. All processes must have at least one data flow in and one data flow out.

2. All processes should modify the incoming data, producing new forms of outgoing data.

3. Each data store must be involved with at least one data flow.

4. Each external entity must be involved with at least one data flow.

5. A data flow must be attached to at least one process.

Although many traditional methods have a tendency to apply DFDs in dysfunctional ways it is still possible to do so in an agile manner as well.  Keep your diagrams small, as I did above.  Use simple tools, such as whiteboards, to create them with your stakeholders.  Travel light and erase them when you抮e through with them.  Create them if they抮e going to add value, not simply because your process tells you to do so.  The bottom line is that some of the modeling methodologies may have been flawed but the need to represent the data flow within a system is still required. 

 

Source

This artifact description is excerpted from Chapter 9 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.

 

 

===============

http://www.engr.sjsu.edu/fayad/current.courses/cmpe202-spring07/docs/projects/Sample-Process-2.pdf

A) Data Flow Diagram
A data flow diagram explains business processes and activities
in a clear, concise way by illustrating how data flows through
the system from one process to another. It is a structured,
diagrammatic technique representing external entities, logical
storage, data sinks and data flows in the system.

B) Data Flow Diagram Principles
1. A system can be decomposed into subsystems, and
subsystems can be further decomposed into lower level
subsystems.
2. Each subsystem represents a process or activity in which
data is processed.
3. At the lowest level, processes can no longer be decomposed.
4. Each 'process' has the characteristics of a system. A process
must have input and output.
5. Data enters the system from the environment, data flows
between processes within the system and data is produced
as output from the system.

C) Data Flow Diagram Rules
1. Any data flow leaving a process must be based on data that
are input to the process.
2. All data flows are named and the name reflects the data
flowing between processes, data stores, sources, or sinks.
3. Only data needed to perform the process should be an input
to the process.
4. A process should know nothing about, that is, be
independent of, any other process in the system, it should
depend only on its own input and output.
5. Processes are always running, they do not start or stop.
Analysts should assume that a process is always ready to
function or perform necessary work.
6. Output from processes can be an input data to other
process, modified data such as change of status and change
of content.

D) Data Flow Diagram Types
1. Physical Data Flow Diagram: Physical data flow diagrams
are implementation-dependent and show the actual devices,
department, people, etc., involved in the current system.
2. Logical or Conceptual Data Flow Diagram: Logical data
flow diagram represents business functions or processes. It
describes the system independently of how it is actually
implemented, and focuses rather on how an activity is
accomplished.

E) Data Flow Diagram Components and Corresponding Notations
1. External Entities: External Entities are sources and
destinations of the system’s imputs and outputs.
2. Processes: A data process represents the transformation of
data in the system modifying the inputs in the process of
generating the outputs.
4.Data Flows: A data flow is a pipeline through which packets
of information flow.
5. Data Stores: A data store represents either a temporary or
permanent place where the data comes to rest.

F) Data Flow Diagram Levels
A Data Flow Diagram can be subdivided into several levels
where the highest level is known as the context level or toplevel.
Each level can further be decomposed into subsystems
until all of the processes and subsystems are identified.

G) Data Flow Diagram Approach
The Data Flow Diagram can be developed in one of the
following two ways:
1. Top-Down Approach
This type of approach starts by drawing a context-level
diagram. The context-level diagram is then decomposed
into sets of processes, data stores and data flows until the
sufficient level of detail has been reached.
2. Event Partitioning Approach
The opposite of the top-down approach, the event
partitioning approach starts by identifying subsytems from
the lowest level. The subsystems are then aggregated into
processes until the context-level DFD can be determined.

-------
The following are the different phases involved in the Data Flow
Diagram Process.
1. Proposition
1.1 The Project Manager initiates the proposition for the data
flow diagram.
1.2 During this phase, the requestor requests for a data flow
diagram of a system.
2. Analysis
2.1 The Analyst gathers the business requirements and
identifies all possible functionalities of the system which
include the various processes and the flows of information
and material linking them to each other, to inventories and
to various external agents of the system.
2.2 The Analyst creates a high level business design with the
identified processes of the system.
2.3 The Analyst reviews the high level business design with
the Project Manager. If the high level business design
requires any revisions, go to step 2.1.
2.4 The Analyst conducts the high level business design walkthrough
with the Technical Reviewer and the Developer.
3. Implementation
3.1 The Technical Reviewer along with the Developer
determines the type of data flow diagram (Physical or
Logical data flow diagram) to be used.
3.2 The Developer determines the approach (Top-Down or
Event Partitioning approach) for implementing the data flow
diagram process.
3.3 If top-down approach go to step 3.4 else if event
partitioning approach go to step 3.5
3.4 Top-Down Approach
3.4.1 Determine the context level of the Data Flow
Diagram.
3.4.2 Determine whether the subsystems inside the
process are decomposable. If yes, go to step
3.4.3. If no, go to step 3.4.4.
3.4.3 Decompose each subsystem into processes.
3.4.4 Identify the processes, external entities, data
stores and data flows inside each subsystem.
3.4.5 If the lowest level of the system is reached
covering all necessary details of the system,
then go to step 3.4.7, else go to step 3.4.6.
3.4.6 Go to step 3.4.2 to iterate through each
processes identified inside a subsystem are
decomposable or not.
3.4.7 Draw the data flow diagram with the identified
processes, external entities, data stores and
data flows.
3.5 Event Partitioning Approach
3.5.1 Identify every event in a process.
3.5.2 If there are no more event inside the process
go to step 3.5.4.
3.5.3 Construct a process for each event and
identify the processes, external entities, data
flows and the data stores associated with the
process.
3.5.4 Aggregate group of related processes into a
process of higher level.
3.5.5 If the context level of the Data Flow Diagram is
reached then go to step 3.5.6, else go to step
3.5.1.
3.5.6 Draw the data flow diagram using event
partitioning approach.
3.6 Submit the Data Flow Diagram to the Technical
Reviewer for review.
4. Review
4.1 The Technical Reviewer reviews in conjunction with the
Developer reviews the data flow diagram to determine
whether the data flow diagram rules are met and if there
any revisions are needed.
4.2 If revisions are needed, go to step 4.3 else go to step 4.4
4.3 The Technical Reviewer requests the Developer to revise
the data flow diagram (proceed to step 3).
4.4 Once revisions are complete, the Technical Review
forwards the data flow diagram to the Analyst (proceed to
step 5).

 

========

http://www.google.com.hk/url?sa=t&rct=j&q=process+flow+data+flow&source=web&cd=9&cad=rja&ved=0CFEQFjAI&url=http%3A%2F%2Fwww.nku.edu%2F~sakaguch%2Fifs310%2FWeek3.ppt&ei=VWVZULCmNMuSiQfa9oBw&usg=AFQjCNFM5uSiF1gjG_5Sqy7-LzKKAkbVMQ

 

The development process of a Data Flow Diagram includes the
following roles
Project Manager
The Project Manager initiates the data flow diagram
development process.
The Project Manager reviews the high level business design of
the data flow diagram along with the Analyst to determine
whether all requirements are met.
The Project Manager finally accepts the completed Data Flow
Diagram.
Analyst
The Analyst studies in depth the business requirements and
creates a high level business design.
The Anaylst together with the Technical Reviewer reviews the
high level business design.
The Analyst then conducts a walk-through of the high level
business design with the Technical Reviewer and
Developer.
Developer
The Developer is reponsible for determining the data flow
diagram approach.
The Developer determines the proceses and other
components that will comprise the data flow diagram.
Once these have been determined, the Developer then
models and draws the data flow diagram.
The Developer is responsible for revising the data flow
diagram if any revisions are needed upon review with the
Technical Reviewer.
Technical Reviewer
The Techincal Reviewer determines the type of data flow
diagram to be used in conjunction with the Developer.
The Technical Reviewer reviews the completed data flow
diagram according to the data flow diagram rules and
determines whether all the functionalities of the system
are covered or not.
If any revisions are needed, the Technical Reviewer instructs
the developer to revise the data flow diagram. Otherwise
the Technical Reviewer forwards the data flow diagram to
the Analyst.