How To Draw DFD’s

Use a Data Flow Diagram (DFD) to show the relationships among the business processes within an organization to: 

· external systems,· external organizations,· customers,· other business processes.

 Method

 Data flow diagrams are used to describe how the system transforms information. They define how information is processed and stored and identify how the information flows through the processes. When building a data flow diagram, the following items should be considered: 

· where does the data that passes through the system come from and where does it go,

 · what happens to the data once it enters the system (i.e., the inputs) and before it leaves the system (i.e., the outputs),

 · what delays occur between the inputs and outputs (i.e., identifying the need for data stores).

 Components of a Data Flow Diagram

 

STEPS TO DRAW A DATA FLOWDIAGRAMSteps

·Start from thecontextdiagram. Identify the parent process and theexternal entitieswith their net inputs andoutputs.·Place the external entities on thediagram. Draw the boundary. ·Identify thedata flowsneededto generate the net inputs and outputs to the externalentities.·Identify thebusiness processesto perform the work needed to generate the input and output dataflows.·Connect the data flows from theexternal entities to the processes.·Identify thedatastores.·Connect the processes and data storeswith data flows.·Apply theProcess Model Paradigmto verifythat the diagram addresses the processing needs of all externalentities.·Apply theExternal Control Paradigmto furthervalidate that the flows to the external entities arecorrect.·Continue to decompose to thenthlevel DFD. Draw all DFDs at onelevel before moving to the next level of decomposing detail. You should decompose horizontally first to asufficient nth level to ensure that the processes are partitioned correctly;then you can begin to decompose vertically.

Tips andHints

Considercreating adataaccess modelto document the processes that create, update, and delete datain the system.As analternative to functional decomposition, consider using a bottom-up approachwhen the details about the system are well known.When analyzing the business system under study in terms of its response to events (for example, user interaction with windowed systems), consider the following: 

Using External Events to Build DFDs

Components of Data Flow DiagramsCraig Borysowich | Feb 14, 2007 | Comments (13)

Whatever convention is used to construct the Data Flow Diagram, all DFDs are composed of the following components: 

EXTERNAL ENTITIES ON A DFD External entities are also known as terminators, sources/sinks, and actors. External entities define the sources and destinations of information entering and leaving the system. An external entity can be a person, system, or organization that has pre-defined behaviour.

 External entities are mandatory on context diagrams but optional on data flow diagrams. 

Description of External Entities External entities are components that interact with a business process on the DFD but fall outside of the boundaries of the DFD. External entities can be: 

· initiators of data (i.e., spontaneous generators) flowing into the business process,

 · end recipients of data (i.e., data sinks) flowing from the business process.

 Examples

 Examples of external entities include: 

· End User,· Purchasing Department,· Inventory System.

 Drawing External Entities on a DFD

 Place external entities on the diagram with all data flows.

 To reduce the visual complexity of the drawing, an external entity can be used more than once on the same DFD. Draw a diagonal line across the lower-left corner of the external entity square to indicate another occurrence of the external entity elsewhere on the same DFD.

 Document External Entities

 Provide a description of external entities to support the DFD.  

FLOWS 

Definition Flows define the interfaces between the components within the system, and the system and its external components. 

Types of Flows Flows that transport data around the data flow diagram are called data flows.

 Description of Data Flows

 Data flows are the pipelines through which data are transmitted between any two components on a DFD. The composition of data is known and defined in a data dictionary. A data flow is also called a data flow vector. Examples of data flows are: 

· purchase order,· customer profile,

· account number,· product.

 Naming Data Flows

 Data flows must be given a name that describes the content of the data being transmitted and a description of the data flow listing the data elements. For example:

Data Flow Name: Employee Info,Description: Information stored about an employee,Data elements: Employee Name,

Employee Date of Birth,Employee ID.

 Bi-Directional Data Flows

 Bi-directional data flows are used only when the information flowing in each direction is identical. 

Data Flows with the Same Name Multiple data flows can have the same name on a DFD. When this occurs, the data transmitted in all of the flows with the same name must be identical. 

Complex Data Flows Data flows are described as complex when there is more than one data flow going in the same direction between any two entities. Name the complex data flow to encompass the contents of all the data flowing along the pipeline. 

Trivial Data Flows DFDs do not show trivial (relative to the specification of functional requirements) flows, such as error messages, keys for retrieving data from a data store, or data store updating instructions. 

Guidelines for Drawing Data Flows on a DFD Connect the data flows from/to external entities to/from business processes within the boundary of the DFD. Connect internal business processes to data stores and other internal processes with appropriate data flows. Label all data flows with care for they indicate the interface requirements for a process. Use descriptive names for labelling data flows. Ensure that all flows to external entities on lower level diagrams balance with data flows from external entities on upper level diagrams. In other words, a new data flow cannot be created at a lower level if it was not identified on an upper level diagram. Double-headed data flows are permitted when the data flowing in both directions are identical. Data flows from/to external entities to/from data stores are not permitted. All data must flow through a process. Be careful not to produce long names for complex data flows. As a rule of thumb, a DFD component (process, data store, or external entity) should not have more than seven data flows connected to it.  Flows that access stored data are called access flows. Flows that are used to synchronize the system control flow and do not require data are called event flows. Common uses include starting, stopping, and changing the system status. Event flows are also known as control flows. Flows can be continuous or discrete. A discrete flow is only present for an instant of time. A continuous flow persists over time. Types of Flows Example:

 Guidelines

 A data flow name should be a singular noun phrase (e.g., delivery list, customer information, credit limit).  Naming access flows is optional. An event flow name should be a singular verb or noun phrase (e.g., start, stop, item available, processing complete). If a data flow contains multiple attributes (i.e., data elements), an attribute list should be provided.

 STORES

 Definition

 Stores represent information (i.e., data or control) at rest. Stores are used when different processes need to share information but are active at different times. Information can be written to a store and read from a store.

 Types of Stores 

Stores that contain data are called data stores. DATA STORES ON A DFD

 Identifying Data Stores

 Data stores are usually derived from the entities in an entity-relationship diagram. 

Creation of Data Stores Data stores are created to store information for later use. They represent data that is temporarily at rest between processes. For example, a data store is needed to store data that is generated on a daily basis but is required for a process that runs weekly. 

Local and Shared Data Stores Local data stores are data stores whose accesses are contained completely within the boundary of a DFD. A data store crossing the boundary of a DFD process indicates that it is shared by processes on another DFD. 

Drawing Data Stores on a DFD A data store can be drawn on the same DFD more than once to reduce the visual complexity of the drawing. An extra vertical bar is drawn in the duplicated data stores to indicate that it appears elsewhere on the same diagram. Stores that contain status or control information are called event stores. Event stores are used to save events that have occurred but have not yet been used. Unlike a data store, an event store has behaviour associated with it which is not apparent when looking at the data flow diagram. If the system accesses an event store and the event has not occurred, the system will be suspended until the event occurs. Once an event has occurred, accessing it will remove it from the event store. Types of Stores Example

 Guidelines

 The data stores on the data flow diagram map to the entities on the entity-relationship diagram. Minimize the use of event stores on the DFD. Try using flags instead. 

PROCESSES 

Definition Processes are also known as data transforms. Processes transform input flows into output flows in a defined manner. A process is a distinct activity (or set of activities) described by its inputs and outputs. A process describes a unique behaviour that has a beginning and an end. A process is performed repeatedly.

 Types of Processes 

A data process transforms input data into output data. Data processes act directly on data, either from flows or stores. They represent the functionality of the system.

 A control process transforms input events into output events and is used on a data flow diagram to indicate the presence of a state transition diagram. Control processes cannot transform data but can control processes that do. A state transition diagram describes the behaviour of the control process.

 Types of Processes Example

 Guidelines 

A process name and number must be unique. A process can only exist once on a data flow diagram. A process must have at least one input and one output. In other words, a process is asked (i.e., triggered) to do something and then must deliver (i.e., respond). A data process cannot input or output discrete event flows (i.e., a data process should not control the system, it should do the work). A control process cannot input or output data flows (i.e., a control process should control the system, not do the work). A process name should start with an active verb (e.g., Produce Items, Control Production). A process exists to do something (i.e., transform input flows into output flows), therefore a process must have an incoming set of requirements to which it must conform.  An nth-level (i.e., next level of detail) data flow diagram must describe its parent process. An nth-level data flow diagram is a decomposition of its parent process and cannot introduce new functionality. 

Notation There are several conventions used to depict the DFD. 

NOTATION ON A DATA FLOW DIAGRAM 

Gane and Sarson The notation described below and used in this technique was popularized by Gane and Sarson: 

· Round-ended rectangles represent processes. 

· Squares identify external entities. 

· Arrows indicate flows. 

· Open-ended rectangles identify stores. 

· Diagonal line across the lower-left corner of an external entity square indicates it appears elsewhere on the same DFD.

 · Extra diagonal line on a data store rectangle indicates it appears elsewhere on the same DFD.

 · Double-headed arrow indicates the same data flowing in both directions.

 Yourdon, DeMarco, and Others

 Another notation popularized by Yourdon, DeMarco, and others is described below: 

· Circles represent processes. 

· Squares identify external entities. 

· Arrows indicate flows. 

· Rectangles open on both ends identify stores. 

Extensions To support the use of DFDs in describing how systems respond to events, the notation has been extended to include the control-oriented information typically needed to describe real-time systems. The widely adopted convention is to represent the control components using dashed lines. The extensions apply to both notations described above

Using External Events to Derive Data Flow DiagramsCraig Borysowich | Feb 15, 2007 | Comments (10)

Identify the external events (from the event list) that have a data event classification. Data events cause data to be transformed. A data flow diagram is used to describe this type of behaviour. An external event may have multiple classifications. If one of the external event's classifications is "D" (i.e., data event) then a data flow diagram is used to model the data transformation component of the system response.

 USING EXTERNAL EVENTS TO IDENTIFY PROCESSES

 The event response can be used to determine the required behaviour and name of a process. Responses and processes are not necessarily at the same level of abstraction. Responses that represent low-level activities must be grouped into related processes. Responses that represent high-level functions must be decomposed into low-level processes. Group related responses together. Responses can be related by the activities that they perform (i.e., if responses do the same things you may want to group them together). Responses can also be related by the data that they use (i.e., if responses use the same data you may want to group them together). If there are multiple responses to an event, multiple processes may be required. If an event has multiple responses and each response processes different data, then a different process should be created for each response since each process will use different data flows and data stores. Separating the processes will simplify their interfaces. Different processes should also be created when different external events have similar responses but process different data. 

The same process may be used by different responses as long as the process's behaviour and data requirements are the same for each event. 

USING EXTERNAL EVENTS TO GROUP PROCESSES You can also use external events to group related processes (i.e., identify parent processes). Identify control events (i.e., the events that use a state transition diagram to describe the system's response). State transition diagrams describe processing sequence, therefore the processes controlled by a state transition diagram should be grouped together with the control process that prompts (i.e., controls) them. Identify the data processes controlled by a control process. Group the data processes and the control process together under the same parent process.