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.
