STRUCTURED DESIGN
The aim of structured design is to transform the results of
the structured analysis (that is, the DFD model) into a
structure chart.
A structure chart represents the software architecture.
The structure chart representation can be easily
implemented using some programming language.
Since the main focus in a structure chart representation is
on module structure of a software and the interaction
among the different modules.
The basic building blocks using which structure charts are
designed are as following:
Rectangular boxes: A rectangular box represents a module.
Usually, every rectangular box is annotated with the name of
the module it represents.
Module invocation arrows: An arrow connecting two
modules implies that during program execution control is
passed from one module to the other in the direction of the
connecting arrow
Data flow arrows: These are small arrows appearing
alongside the module invocation arrows. The data flow arrows
are annotated with the corresponding data name.
Library modules: A library module is usually represented
by a rectangle with double edges. Libraries comprise the
frequently called modules. Usually, when a module is invoked
by many other modules, it is made into a library module.
Selection: The diamond symbol represents the fact that one
module of several modules connected with the diamond
symbol is invoked depending on the outcome of the condition
attached with the diamond symbol.
Repetition: A loop around the control flow arrows denotes
that the respective modules are invoked repeatedly
Flow chart versus structure chart :A structure chart differs from a
flow chart in three principal ways:
It is usually difficult to identify the different modules of a
program from its flow chart representation.
Data interchange among different modules is not represented in a
flow chart.
Sequential ordering of tasks that is inherent to a flow chart is
suppressed in a structure chart.
Transformation of a DFD Model into Structure Chart
Systematic techniques are available to transform the DFD
representation of a problem into a module structure
represented by as a structure chart.
Structured design provides two strategies to guide
transformation of a DFD into a structure chart:
Transform analysis
Transaction analysis
At each level of transformation, it is important to first
determine whether the transform or the transaction analysis is
applicable to a particular DFD.
Whether to apply transform or transaction processing?
Given a specific DFD of a model, how does one decide whether
to apply transform analysis or transaction analysis?
For this, one would have to examine the data input to the
diagram.
The data input to the diagram can be easily spotted because
they are represented by dangling arrows.
If all the data flow into the diagram are processed in similar
ways (i.e., if all the input data flow arrows are incident on the
same bubble in the DFD) then transform analysis is
applicable.
Otherwise, transaction analysis is applicable
Transform analysis
Transform analysis identifies the primary functional
components (modules) and the input and output data for
these components.
The first step in transform analysis is to divide the DFD
into three types of parts:
Input
Processing
Output
The input portion in the DFD includes processes that
transform input data from physical (e.g., character from
terminal) to logical form (e.g., internal tables, lists, etc.). Each
input portion is called an afferent branch.
The output portion of a DFD transforms output data from
logical form to physical form. Each output portion is called an
efferent branch. The remaining portion of a DFD is called
central transform.
In the next step of transform analysis, the structure chart is
derived by drawing one functional component each for the
central transform, the afferent and efferent branches. These are
drawn below a root module, which would invoke these
modules.
In the third step of transform analysis, the structure chart is
refined by adding sub functions required by each of the high-
level functional components.
Many levels of functional components may be added.
This process of breaking functional components into
subcomponents is called factoring.
Factoring includes adding read and write modules, error
handling modules, initialization and termination process,
identifying consumer modules etc.
The factoring process is continued until all bubbles in the DFD
are represented in the structure chart.
Transaction analysis
Transaction analysis is an alternative to transform analysis and
is useful while designing transaction processing programs.
A transaction allows the user to perform some specific type of
work by using the software.
As in transform analysis, first all data entering into the DFD
need to be identified.
In a transaction-driven system, different data items may pass
through different computation paths through the DFD.
This is in contrast to a transform centered system where each
data item entering the DFD goes through the same processing
steps.
A simple way to identify a transaction is the following.
Check the input data.
The number of bubbles on which the input data to the DFD are
incident defines the number of transactions.
However, some transactions may not require any input data. These
transactions can be identified based on the experience gained from
solving a large number of examples.
For each identified transaction, trace the input data to the output.
All the traversed bubbles belong to the transaction.
These bubbles should be mapped to the same module on the structure
chart.
In the structure chart, draw a root module and below this module
draw each identified transaction as a module.
Every transaction carries a tag identifying its type.
Transaction analysis uses this tag to divide the system into transaction
modules and a transaction-center modules.
DETAILED DESIGN
During detailed design the pseudocode description of the processing and the
different data structures are designed for the different modules of the structure
chart.
These are usually described in the form of module specifications (MSPEC).
MSPEC is usually written using structured English.
The MSPEC for the non-leaf modules describe the different conditions under
which the responsibilities are delegated to the lower-level modules.
The MSPEC for the leaf-level modules should describe in algorithmic form
how the primitive processing steps are carried out.
To develop the MSPEC of a module, it is usually necessary to refer to the
DFD model and the SRS document to determine the functionality of the
DESIGN REVIEW
After a design is complete, the design is required to be reviewed.
The review team usually consists of members with design, implementation, testing,
and maintenance perspectives, who may or may not be the members of the
development team.
The review team checks the design documents especially for the following
aspects:
Traceability: Whether each bubble of the DFD can be traced to some module in the
structure chart and vice versa. They check whether each functional requirement in
the SRS document can be traced to some bubble in the DFD model and vice versa.
Correctness: Whether all the algorithms and data structures of the detailed design
are correct.
Maintainability: Whether the design can be easily maintained in future.
Implementation: Whether the design can be easily and efficiently be implemented.
After the points raised by the reviewers is addressed by the designers, the design
document becomes ready for implementation
