05 Structured Design

v  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 subsections.

v  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.

v  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.

04 Data Flow Diagrams (DFDs)

v  Structured Analysis:

Structured analysis is used to carry out the top-down decomposition of a set of high-level functions depicted in the problem description and to represent them graphically. During structured analysis, functional decomposition of the system is achieved. That is, each function that the system performs is analyzed and hierarchically decomposed into more detailed functions. Structured analysis technique is based on the following essential underlying principles:

• Top-down decomposition approach.

• Divide and conquer principle. Each function is decomposed independently.

• Graphical representation of the analysis results using Data Flow Diagrams (DFDs).

v  Data Flow Diagram (DFD):

The DFD (also known as a bubble chart) 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. Each function is considered as a processing station (or process) that consumes some input data and produces some output data. The system is represented in terms of the input data to the system, various processing carried out on these data, and the output data generated by the system. A DFD model uses a very limited number of primitive symbols [as shown in fig. 5.1(a)] to represent the functions performed by a system and the data flow among these functions.

 

           External Entity                  Process                          Output                    Data Flow                     Data Store

(a)

Fig. 5.1 (a) Symbols used for designing DFDs

(b), (c) Synchronous and asynchronous data flow

Here, two examples of data flow that describe input and validation of data are considered. In Fig. 5.1(b), the two processes are directly connected by a data flow. This means that the ‘validate-number’ process can start only after the ‘read number’ process had supplied data to it. However in Fig 5.1(c), the two processes are connected through a data store. Hence, the operations of the two bubbles are independent. The first one is termed ‘synchronous’ and the second one ‘asynchronous’.

v  Importance of DFDs in a good software design:

The main reason why the DFD technique is so popular is probably because of the fact that DFD is a very simple formalism – it is simple to understand and use. Starting with a set of high-level functions that a system performs, a DFD model hierarchically represents various sub-functions. In fact, any hierarchical model is simple to understand. Human mind is such that it can easily understand any hierarchical model of a system – because in a hierarchical model, starting with a very simple and abstract model of a system, different details of the system are slowly introduced through different hierarchies. The data flow diagramming technique also follows a very simple set of intuitive concepts and rules. DFD is an elegant modelling technique that turns out to be useful not only to represent the results of structured analysis of a software problem, but also for several other applications such as showing the flow of documents or items in an organization.

v  Shortcomings of a DFD model:

DFD models suffer from several shortcomings. The important shortcomings of the DFD models are the following:

• DFDs leave ample scope to be imprecise. In the DFD model, the function performed by a bubble is judged from its label. However, a short label may not capture the entire functionality of a bubble. For example, a bubble named find-book-position has only intuitive meaning and does not specify several things, e.g. what happens when some input information are missing or are incorrect. Further, the find-book position bubble may not convey anything regarding what happens when the required book is missing.

• Control aspects are not defined by a DFD. For instance, the order in which inputs are consumed and outputs are produced by a bubble is not specified. A DFD model does not specify the order in which the different bubbles are executed. Representation of such aspects is very important for modelling real-time systems.

• The method of carrying out decomposition to arrive at the successive levels and the ultimate level to which decomposition is carried out are highly subjective and depend on the choice and judgment of the analyst. Due to this reason, even for the same problem, several alternative DFD representations are possible. Further, many times it is not possible to say which DFD representation is superior or preferable to another one.

• The data flow diagramming technique does not provide any specific guidance as to how exactly to decompose a given function into its sub functions and we have to use subjective judgment to carry out decomposition.