MOSHI COOPERATIVE UNIVERSITY

(MoCU)

Faculty : FBIS

Program : BSC -BICT

Course ante : CIT 307

Course instructor : Mr G. Sizya

Course name : Software Quality Assurance

Task : Group assignment

Submission date : 3 JULY 2020

NAME REGISTRATION
WAZIRI A. AMIRI MoCU/BSc-BICT/139/17
HEMED S. HEMED MoCU/BSc-BICT/184/17
ELIZA H. YONA MoCU/BSc-BICT/166/17
PASCHAL MUNNAH MoCU/BSc-BICT/167/17
MIRAJI D. MIRAJI MoCU/BSc-BICT/146/17
MMASI INNOCENT MoCU/BSc-BICT/188/17
Introduction:
The flow-based modeling represents how data objects are transformed as 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-based 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 based 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.

Tools used to build a data flow-based model include;

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:

A data store does not generate any operations but simply holds data for later access.

4. External Entity:

The rectangle represents an external entity.

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

Levels in DFD
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).
 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.