Structured Design

 Specific Instructional Objectives

At the end of this lesson the student will be able to:

• ·         Identify the aim of structured design.
• ·         Explain what a structure chart is.
• ·         Differentiate between a structure chart and a flow chart.
• ·         Identify the activities carried out during transform analysis with examples.
• ·         Explain what is meant by transaction analysis.

Structured Design

The aim of structured design is to transform the results of the structured analysis (i.e. a DFD representation) into a structure chart. Structured design provides two strategies to guide transformation of a DFD into a structure chart.

• ·         Transform analysis
• ·         Transaction analysis

Normally, one starts with the level 1 DFD, transforms it into module representation using either the transform or the transaction analysis and then proceeds towards the lower-level DFDs. At each level of transformation, it is important to first determine whether the transform or the transaction analysis is applicable to a particular DFD. These are discussed in the subsequent sub- sections.

Structure Chart

A structure chart represents the software architecture, i.e. the various modules making up the system, the dependency (which module calls which other modules), and the parameters that are passed among the different modules. Hence, the structure chart representation can be easily implemented using some programming language. Since the main focus in a structure chart representation is on the module structure of the software and the interactions among different modules, the procedural aspects (e.g. how a particular functionality is achieved) are not represented.

The basic building blocks which are used to design structure charts are the following:

• ·         Rectangular boxes: Represents a module.
• ·         Module invocation arrows: Control is passed from one module to another module in the direction of the connecting arrow.
•  ·         Data flow arrows: Arrows are annotated with data name; named data passes from one module to another module in the direction of the arrow.
• ·         Library modules: Represented by a rectangle with double edges.
• ·         Selection: Represented by a diamond symbol.
• ·         Repetition: Represented by a loop around the control flow arrow.

Structure Chart vs. Flow Chart

We are all familiar with the flow chart representation of a program. Flow chart is a convenient technique to represent the flow of control in a program. A structure chart differs from a flow chart in three principal ways:

·         It is usually difficult to identify the different modules of the software from its flow chart representation.

·         Data interchange among different modules is not represented in a flow chart.

·         Sequential ordering of tasks inherent in a flow chart is suppressed in a structure chart.

Transform Analysis

Transform analysis identifies the primary functional components (modules) and the high level inputs and outputs for these components. The first step in tranform analysis is to divide the DFD into 3 types of parts:

·         Input

·         Logical processing

·         Output

The input portion of the DFD includes processes that transform input data from physical (e.g. character from terminal) to logical forms (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 to physical form. Each output portion is called an efferent branch. The remaining portion of a DFD is called the central transform.

In the next step of transform analysis, the structure chart is derived by drawing one functional component for the central transform, and the afferent and efferent branches. These are drawn below a root module, which would invoke these modules.

 

Identifying the highest level input and output transforms requires experience and skill. One possible approach is to trace the inputs until a bubble is found whose output cannot be deduced from its inputs alone. Processes which validate input or add information to them are not central transforms. Processes which sort input or filter data from it are. The first level structure chart is produced by representing each input and output unit as boxes and each central transform as a single box.

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 customer modules, etc. The factoring process is continued until all bubbles in the DFD are represented in the structure chart.

 

Example: Structure chart for the RMS software

For this example, the context diagram was drawn earlier.

To draw the level 1 DFD (fig. 5.11), from a cursory analysis of the problem description, we can see that there are four basic functions that the system needs to perform – accept the input numbers from the user, validate the numbers, calculate the root mean square of the input numbers and, then display the result.

By observing the level 1 DFD, we identify the validate-input as the afferent branch and write-output as the efferent branch. The remaining portion (i.e. compute-rms) forms the central transform. By applying the step 2 and step 3 of transform analysis, we get the structure chart shown in fig. 5.12.

Transaction Analysis

A transaction allows the user to perform some meaningful piece of work. Transaction analysis is useful while designing transaction processing programs. In a transaction-driven system, one of several possible paths through the DFD is traversed depending upon the input data item. This is in contrast to a transform centered system which is characterized by similar processing steps for each data item. Each different way in which input data is handled is a transaction. A simple way to identify a transaction is to 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 transaction may not require any input data. These transactions can be identified from the experience of 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 a module. Every transaction carries a tag, which identifies its type. Transaction analysis uses this tag to divide the system into transaction modules and a transaction-center module.

For the following, mark all options which are true.

1.    The purpose of structured analysis is:-

□                              to capture the detailed structure of the system as perceived by the user   √

□                              to    define   the    structure    of    the    solution   that    is    suitable   for implementation in some programming language

□                              all of the above

 

2.    Structured analysis technique is based on

□                              top-down decomposition approach        √

□                              bottom-up approach

□                              divide and conquer principle          √

□                              none of the above

3.    Data Flow Diagram (DFD) is also known as a:

□                              structure chart

□                              bubble chart           √

□                              Gantt chart

□                              PERT chart

 

4.    The context diagram of a DFD is also known as

□                              level 0 DFD            √

□                              level 1 DFD

□                              level 2 DFD

□                              none of the above

 

5.    Decomposition of a bubble is also known as

□                              classification

□                              factoring           √

□                              exploding          √

□                              aggregation

 

6.    Decomposition of a bubble should be carried on

□                              till the atomic program instructions are reached

□                              upto two levels

□                              until a level is reached at which the function of the bubble  can be described using a simple algorithm                                      √

□                              none of the above

7.    The bubbles in a level 1 DFD represent

□                              exactly one high-level functional requirement described in SRS document

□                              more than one high-level functional requirement

□                              part of a high-level functional requirement

□                              any of the above depending on the problem       √

 

8.    By looking at the structure chart, we can

□                              say whether a module calls another module just once or many times

□                              not say whether a module calls another module just once or many times            √

□                              tell the order in which the different modules are invoked

□                              not tell the order in which the different modules are invoked √

9.    In a structure chart, a module represented by a rectangle with double edges is called

□                              root module

□                              library module              √

□                              primary module

□                              none of the above

10. A structure chart differs from a flow chart in which of the following ways

□                              it is always difficult to identify the different modules of the software from its flow chart representation                              √

□                              data interchange among different modules is not presented in a flow chart           √

□                              sequential ordering of tasks inherent in a flow chart is suppressed in a structure chart                          √

□                              none of the above

 

11.        The input portion in the DFD that transform input data from     physical to logical form is called

□                              central transform

□                              efferent branch

□                              afferent branch                    √

□                              none of the above

 

12.        If during structured design you observe that the data entering a DFD are incident on different bubbles, then you would use:

□                                          transform analysis

□                                          transaction analysis             √

□                                          combination of transform and transaction analysis

□                                          neither transform nor transaction analysis

 

13.        During structured design, if all the data flow into the diagram are processed in similar ways i.e. if all the input data are incident on the same bubble in the DFD, the one have to use:

□                              transform analysis                 √

□                              transaction analysis

□                              combination of transform and transaction analysis

□                              neither transform nor transaction analysis

 

14.        Which of the following types of bubbles may belong to the central transform ?

□                              input validation

□                              adding information to the input

□                              sorting input              √

□                              filtering data               √

15. During detailed design which of the following activities take place?

□                              the pseudo code for the different modules of the structure chart are developed in the form of MSPECs                                      √

□                              data structures are designed for the different modules of the structure chart            √

□                              module structure is designed

□                              none of the above

 Mark the following as either True or False. Justify your    answer.

1.    A DFD model of a system represents the functions performed by the system and the data flow taking place among these functions.

Ans.: - True

Explanation: - A DFD in simple words, is a hierarchical graphical model of a system that shows the different processing activities or functions that the system performs and the data interchange among these functions.

2.    A data dictionary lists the purpose of all data items and the definition of all composite data items in terms of their component data items.

Ans.: - True.

Explanation: - A data dictionary lists the purpose of all data items and the definition of all composite data items in terms of their component data items. For example, a data dictionary entry may represent that the data gross-Pay consists of the components regular-Pay and overtime-Pay.

 

gross-Pay = regular-Pay + overtime-Pay

 

3.    The context diagram of a system represents it using more than one bubble.

Ans.: - False.

Explanation:- The context diagram is the most abstract data flow representation of a system. It represents the entire system as a single bubble. This bubble is labeled according to the main function of the system. The various external entities with which the system interacts and the data flow occurring between the system and the external entities are also represented.

 

4.    External entities may appear at all levels of DFDs.

Ans.: - False.

Explanation:- All external entities interfacing with the system should be represented only in the context diagram. The external entities should not appear at other levels of the DFD.

 

5.     A DFD captures the order in which the processes (bubbles) operate.

Ans.:- False.

Explanation:- A DFD does not capture the order in which the processes (bubbles) operate.

 6.    DFDs enable a software engineer to develop the data domain and functional domain decomposition of the system at the same time.

Ans.:- True.

Explanation:- As the DFD is refined into greater levels of detail, the analyst performs an implicit functional decomposition. At the same time, the DFD refinement automatically results in refinement of corresponding data items.

 7.    There should be at most one control relationship between any two modules in a properly designed structure chart.

Ans.:- True.

Explanation:- It can be considered the different modules of a structure chart to be arranged in layers or levels. The principle of abstraction does not allow lower-level modules to be aware of the existence of the high- level modules. However, it is possible for two higher-level modules to invoke the same lower-level module.