Definition
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.
In evaluating the quality of a data flow diagram, the following characteristics and standard must be meet or considered. The methods, components and the structure of a data flow diagram must be well followed as what is stated below.
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
Whatever convention is used to construct the Data Flow Diagram, all DFDs are composed of the following components:
→EXTERNAL ENTITIES
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
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.
→ 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.
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.
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.
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.
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.
STEPS TO DRAW A DATA FLOW DIAGRAM
Steps
Start from the context diagram. Identify the parent process and the external entities with their net inputs and outputs.
Place the external entities on the diagram. Draw the boundary.
Identify the data flows needed to generate the net inputs and outputs to the external entities.
Identify the business processes to perform the work needed to generate the input and output data flows.
Connect the data flows from the external entities to the processes.
Identify the data stores.
Connect the processes and data stores with data flows.
Apply the Process Model Paradigm to verify that the diagram addresses the processing needs of all external entities.
Apply the External Control Paradigm to further validate that the flows to the external entities are correct.
Continue to decompose to the nth level DFD. Draw all DFDs at one level before moving to the next level of decomposing detail.
You should decompose horizontally first to a sufficient nth level to ensure that the processes are partitioned correctly; then you can begin to decompose vertically.
Sources:
http://it.toolbox.com/blogs/enterprise-solutions/components-of-data-flow-diagrams-14497
http://it.toolbox.com/blogs/enterprise-solutions/data-flow-diagrams-dfds-14573
No comments:
Post a Comment