11.3 Structure Design


The reasons for using structured design and to implement the two transforms include the following:
To move from an abstract system representation to a more physical one.
To reduce ambiguity which may arise from subjective interpretations.
To move from data flow concepts to program structure concepts.
Structured design, considered as a tool that converts data flow diagrams (DFDs) to software architecture can
be described as a data-flow-oriented design method.
How a DFD is developed depends on the type of 'information flow' in question.
As well as this, how a DFD is converted into software structure also depends on two mapping methods.
There are two types of information flow in DFDs:
Transform flow: The mapping used in this case is the transform mapping.
Transaction flow: The mapping used in this case is the transaction mapping.
Commonly, level 1 DFD is used and converted into module representation.
This can be done using transform analysis of transaction analysis.
Once this is done, lower-level DFDs are taken into account.

11.3 Structure Design


At every conversion that takes place, one has to decide procedure is more suitable to use; transform analysis
or transaction analysis.
This is discussed in the following sections.
Structure Chart: A structure chart represents the software architecture.
Illustrates the various modules that form the system, in addition to how they interact with one another
and the conditions of this interaction.
This makes the structure chart an easy tool to develop using a programming language.
Due to the focus of the structure chart being the illustration of the modules of the system and how they
interact with one another, the way these modules function is not included as a result.
The main notations used to develop structure charts are as follows:
Rectangular boxes: Represent modules.
Module invocation arrows: Represents the flow of control from one module to the other.
Data flow arrows: Data name is attached to the arrows. The direction of the arrow signifies the direction of the
data, from one module to the other.

11.3 Structure Design


Library modules: Represented by a double edged rectangle.
Selection: Represented by a diamond.
Repetition: Represented by a loop.

Table 1 presents a comparison between structure charts and flow charts.

11.3 Structure Design


General Steps Involved in structured design are:
The type of data flow is established
In this step the nature of the data flowing between processes is defined.
Determine flow boundaries (switch points)
This includes if the boundary is input boundary, output boundary, hub boundary or action
boundary.
Map the abstract DFD on to a particular program structure
Determine if the program structure is a transformational structure or transactional structure
Define a valid control structure
This step is also known as "first-level" factoring. It depends on whether transformational or
transactional models are used.
The control structure is either "Call-and-return" for transformational model or "Call-and-act" for
transactional model.

11.3 Structure Design


Refine (tune) the resulting structure
This step is also known as "second-level factoring". It maps Input/Output flow bounded parts of
DFD.
Supplement and tune the final architectural structure
Apply basic module independence concepts (i.e. Explode or implode modules according to
coupling/cohesion requirements) to obtain an easier implementation.