Software Design: Embedded Systems - 3 | Embedded Systems (Web) - Computer Science Engineering (CSE) PDF Download

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, we judge the function performed by a bubble 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 is missing or is 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 modeling 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 a times it is not possible to say which DFD representation is superior or preferable to another.
• 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. 

Extending DFD Technique To Real-Time Systems  

The aim of structured design is to transform the results of the structured analysis (i.e. a DFD representation into a structure chart).  A structure chart represents the software architecture, i.e. the various modules making up the system, the module dependency, and the parameters that are passed among the different modules. Since the main focus in a structure chart representation is on the module structure of software and the interaction between the different modules, the procedural aspects are not represented. 

 A real-time system is one where the functions must not only produce correct result but also should produce them by some pre-specified time. For real-time systems since reasoning about time is important to come up with a correct design, explicit representation of control and event flow aspects are essential. One of the widely accepted techniques for extending the DFD technique to real-time system analysis is the Ward and Mellor technique [1985]. In the Ward and Mellor notation, a type of process that handles only control flows is introduced. These processes representing control processing are denoted using dashed bubbles. Control flows are shown using dashed lines/arrows. 

Unlike Ward and Mellor, Hatley and Pirbhai [1987] show the dashed and solid representations on separate diagrams. To be able to separate the data processing and the control processing aspects, a Control Flow Diagram (CFD) is defined.  This reduces the complexity of the diagrams. In order to link the data processing and control processing diagrams, a notational reference (solid bar) to a control specification is used. The CSPEC describes the following: 

• The effect of an external event or control signal
• The processes that are invoked as a consequence of an event Control specifications represent the behaviour of the system in two different ways:
• It contains a state transition diagram (STD). The STD is a sequential specification of behaviour.
• It contains a program activation table (PAT). The PAT is a combinational specification of behaviour. PAT represents invocation sequence of bubbles in a DFD. 

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).  A structure chart represents the software architecture, i.e. the various modules making up the system, the module dependency, and the parameters that are passed among the different modules. Since the main focus in a structure chart representation is on the module structure of software and the interaction between the different modules, the procedural aspects are not represented. 

Flow Chart Vs. Structure 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.
• Sequential ordering of tasks inherent in a flow chart is suppressed in a structure chart. 

Transformation of a DFD into a Structure Chart 

Systematic techniques are available to transform the DFD representation of a problem into a module structure represented by a structure chart. Structured design provides two strategies:

• Transform Analysis
• Transaction Analysis

Transform Analysis 

Transform analysis identifies the primary functional components (modules) and the high level inputs and outputs for these components. The first step in transform 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 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 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. 

For this example, the context diagram was drawn earlier. To draw the level 1 DFD (fig. 36.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. 

Fig. 36.11 Level 1 DFD 

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

Fig. 36.12 Structure chart 

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 centred 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 transactions 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-centre module. 

The structure chart for the supermarket prize scheme software is shown in fig. 36.13. 

Fig. 36.13 Structure chart for the supermarket prize scheme