Flow-Oriented Modeling | Data Flow Model | Control Flow Model | Control Specification | Process Specification

Flow-Oriented Modeling | Data Flow Model | Control Flow Model | Control Specification | Process Specification

Although data 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. 

Although the data flow diagram (DFD) and related diagrams and information are not a formal part of UML, they can be used to complement UML diagrams and provide additional insight into system requirements and flow.

The DFD 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 objects are represented by labeled arrows, and transformations are represented by circles (also called bubbles).  

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.

Creating a Data Flow Model

The data flow diagram enables you 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.

Simple guidelines  the derivation of a data flow diagram:-

(1) the level 0 data flow diagram should depict the software/system as a single bubble.

(2) primary input and output should be carefully noted.

(3) refinement should begin by isolating candidate processes, data objects, and data stores to be represented at the next level.

(4) all arrows and bubbles should be labeled with meaningful names.

(5) information flow continuity must be maintained from level to level.

(6) one bubble at a time should be refined. There is a natural tendency to overcomplicate the data flow diagram.

The refinement of DFDs continues until each bubble performs a simple function.

That is, until the process represented by the bubble performs a function that would be easily implemented as a program component. called cohesion.

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.

I have already noted that an event or control item is implemented as a Boolean value.

The following guidelines are for select potential candidate events:

·   List all sensors that are “read” by the software.

·   List all interrupt conditions.

·   List all “switches” that are actuated by an operator. 

·   List all data conditions.

·  Recalling the noun/verb parse that was applied to the processing narrative,     review all “control items” as possible control specification inputs/outputs.

·   Describe the behavior of a system by identifying its states, identify how each state is reached, and define the transitions between states.

·  Focus on possible omissions—a very common error in specifying control; for example, ask: “Is there any other way I can get to this state or exit from it?”

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.

A somewhat different mode of behavioral representation is the process activation table. The PAT represents information contained in the state diagram in the context of processes, not states.

That is, the table indicates which processes (bubbles) in the flow model will be invoked when an event occurs.

The PAT can be used as a guide for a designer who must build an executive that controls the processes represented at this level.

The CSPEC describes the behavior of the system, but it gives us no information about the inner working of the processes that are activated as a result of this 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.