What is Flow Oriented Modeling ?

The flow oriented modeling represents how data objects are transformed at they move through the system. Derived from structured analysis, flow models use the data flow diagram, a modeling notation that depicts how input is transformed into output as data objects move through the system. Each software function that transforms data is described by a process specification or narrative. In addition to data flow, this modeling element also depicts control flow.

Although flow oriented modeling is perceived as an outdated technique by some software engineers, it continues to be one of the most widely used requirements analysis notations in use today.  Flow oriented modeling focuses on structured analysis and design, follows a top to down methodology and uses a graphical technique depicting information flows and the transformations that are applied as data moves from input to output.

The modeling tools that are used to build a data flow oriented model include context diagrams, data flow diagrams, entity relationship diagram, control flow diagram, state transition diagram, data dictionary, process specification and control specification. Although the data flow diagram (DFD) and related diagrams and information are not a formal part of UML (Unified Modeling Language), they can be used to complement UML diagrams and provide additional insight into system requirements and flow. The flow oriented modeling takes an input-process-output view of a system. That is, data objects flow into the software, are transformed by processing elements, and resultant data objects flow out of the software.

Data Flow Diagram :

The data flow diagram represents the flows of data between different process in a business. It is a graphical technique that depicts information flow and transforms that are applied as data from input to output. It provides a simple, intuitive method for describing business processes without focusing on the details of computer systems. DFDs are attractive techniques because they provide what users do rather than what computers do. In DFD, there are four symbols are used :

1. Process :

The circle represents the process. An activity that changes or transforms data flows. Since they transform incoming data to outgoing data, all processes must have inputs and outputs on a DFD.

2. Data Flow : 

The labeled arrows indicate incoming and outgoing data flow. Movement of data between external entities, processes and data stores is represented with an arrow symbol, which indicates the direction of flow.

3. Data Store :

The rectangle represents an external entity. A data store does not generate any operations but simply holds data for later access.


4. External Entity :
In Data Flow Diagrams external entities produce and consume data that flows between the entity and the system being diagrammed.

These data flows are the inputs and outputs of the DFD. Data objects are represented by labeled arrows, and transformations are represented by circles. The DFD is presented in a hierarchical fashion. That is, the first data flow model (sometimes called a level 0 DFD or context diagram) represents the system as a whole. Subsequent data flow diagrams refine the context diagram, providing increasing detail with each subsequent level.

In DFD there are various levels of DFD, which provide details about the input, processes, and output of a system. Note that the level of detail of process increases with increase in level(s). However, these levels do not describe the system's internal structure or behavior. These levels are listed below :

1. Level 0 DFD : This shows an overall view of the system. Level a DFD is also known as context diagram.

2. Level 1 DFD : This elaborates level a DFD and splits the process into a detailed form.2

3. Level 2 DFD : This elaborates level 1 DFD and displays the process(s) in a detailed form.

4. Level 3 DFD : This elaborates level 2 DFD and displays the process(s) in a detailed form.


Creating a Data Flow model :

The data flow diagram enables us to develop models of the information domain and functional domain. As the DFD is refined into greater levels of detail, you perform an implicit functional decomposition of the system. The Simple guidelines  the derivation of a data flow diagram :-

1. All icons must be labeled with meaningful names.

2. The DFD evolves through a number of levels of details.

3. Always begin with a context level diagram (also called level 0)

4. Always show external entities at level 0 and 1.

5. The level 0 data flow diagram should depict the software/system as a single bubble.

6. Primary input and output should be carefully noted.

7. Refinement should begin by isolating candidate processes, data objects, and data stores to be represented at the next level.

8. All arrows and bubbles should be labeled with meaningful names.

9. Information flow continuity must be maintained from level to level.

10. One bubble at a time should be refined.


Example of Data Flow Diagram :

The below figure shows the level 0 DFD diagram of food ordering system in restaurant.


Figure : Level 0 DFD for "food ordering system" in restaurant


Here customer, kitchen and restaurant managers are external entities.

  • The "food ordering system" accepts the food order from the customer and forwards the order to the kitchen.
  • When the service is provided to the customer, the system generates the bill.
  • A copy of customer bill can be submitted to the manager as a part of restaurant management report.
This level 0 DFD can be extended to level 1 DFD to show more details showing exact data flow and processes (i.e. transformers).


Figure : Level 1 DFD for "food ordering system" in restaurant


Control Flow Model :

For some types of applications, the data model and the data flow diagram are all that is necessary to obtain meaningful insight into software requirements. Such applications require the use of control flow modeling in addition to data flow modeling. The large applications which have following characteristics require control flow modeling.

The applications which are driven by the events rather than data.
The applications which produce control information rather than reports or displays.
The applications which process information in specific time.

The control item or event is implemented a Boolean value. For example, True or False, On or Off, 1 or 0.

The Control Specification :

A control specification (CSPEC) represents the behavior of the system in two different ways. The CSPEC contains a state diagram that is a sequential specification of behavior. It can also contain a program activation table a combinatorial specification of behavior.

The Process Specification :

The process specification (PSPEC) is used to describe all flow model processes that appear at the final level of refinement. The content of the process specification can include narrative text, a program design language (PDL) description of the process algorithm, mathematical equations, tables, or UML activity diagrams. By providing a PSPEC to accompany each bubble in the flow model, you can create a “mini-spec” that serves as a guide for design of the software component that will implement the bubble.



Next Topic :