FUNCTION-ORIENTED SOFTWARE DESIGN IN SOFTWARE ENGINEERING

 

FUNCTION-ORIENTED SOFTWARE

DESIGN

6.1 OVERVIEW OF SA/SD METHODOLOGY

As the name itself implies, SA/SD methodology involves carrying out two

distinct activities:

Structured analysis (SA)

Structured design (SD)

The roles of structured analysis (SA) and structured design (SD) have been

shown schematically in Figure 6.1. Observe the following from the figure:

During structured analysis, the SRS document is transformed into a

data flow diagram (DFD) model.During structured design, the DFD model

is transformed into astructure chart.

Figure 6.1: Structured analysis and structured design methodology.

As shown in Figure 6.1, the structured analysis activity transforms the SRS

document into a graphic model called the DFD model. During structured

analysis, functional decomposition of the system is achieved. That is, each

function that the system needs to perform is analysed and hierarchically

decomposed into more detailed functions. On the other hand, during

structured design, all functions identified during structured analysis are

mapped to a module structure. This module structure is also called the highlevel design or the software architecture for the given problem. This isrepresented using a structure chart.The high-level design stage is normally followed by a detailed design stage.

During the detailed design stage, the algorithms and data structures for theindividual modules are designed. The detailed design can directly be

implemented as a working system using a conventional programming

language.

The results of structured analysis can therefore, be easily understood by

the user. In fact, the different functions and data in structured analysis are

named using the user’s terminology. The user can therefore even review the

results of the structured analysis to ensure that it captures all his

requirements.

In the following section, we first discuss how to carry out structured analysis

to construct the DFD model. Subsequently, we discuss how the DFD model

can be transformed into structured design.

6.2 STRUCTURED ANALYSIS

We have already mentioned that during structured analysis, the major

processing tasks (high-level functions) of the system are analysed, and

t h e data flow among these processing tasks are represented

graphically. The structured analysis technique is based on the following

underlying principles:

Top-down decomposition approach.

Application of divide and conquer principle. Through this each high

level function is independently decomposed into detailed functions.

Graphical representation of the analysis results us ing data flow

diagrams (DFDs).

DFD representation of a problem, as we shall see shortly, is very easy to

construct. Though extremely simple, it is a very powerful tool to tackle the

complexity of industry standard problems.

Please note that a DFD model only represents the data flow aspects and

does not show the sequence of execution of the different functions and the conditions based on which a function may or may not be executed. In fact, it completely ignores aspects such as control flow, the specific algorithms use It is important to understand that the purpose of structured analysis is to capture the detailed structure of the system as perceived by the user, whereas the purpose of structured design is to define the structure of the solution that is suitable for implementation in some programming language.by the functions, etc. In the DFD terminology, each function is called a process or a bubble. It is useful to consider each function as a processing station (or process) that consumes some input data and produces some output data.

DFD is an elegant modelling technique that can be used not only to

represent the results of structured analysis of a software problem, but also

useful for several other applications such as showing the flow of documentsor items in an organisation.

6.2.1 Data Flow Diagrams (DFDs)

The DFD (also known as the bubble chart) is a simple graphical

formalism that can be used to represent a system in terms of the input

data to the system, various processing carried out on those data, and

the output data generated by the system. 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. A DFD

model uses a very limited number of primitive symbols (shown in Figure

6.2) to represent the functions performed by a system and the data

flow among these functions.

Starting with a set of high-level functions that a system performs, a DFD

model represents the subfunctions performed by the functions using a

hierarchy of diagrams. We had pointed out while discussing the principle of

abstraction in Section 1.3.2 that any hierarchical representation is an

effective means to tackle complexity. Human mind is such that it can easily

understand any hierarchical model of a system—because in a hierarchical

model, starting with a very abstract model of a system, various details of the system are slowly introduced through different levels of the hierarchy. TheDFD technique is also based on a very simple set of intuitive concepts and rules. We now elaborate the different concepts associated with building a DFD model of a system.

Primitive symbols used for constructing DFDs

There are essentially five different types of symbols used for constructing

DFDs. These primitive symbols are depicted in Figure 6.2. The meaning of

these symbols are explained as follows: 

Figure 6.2: Symbols used for designing DFDs.

Function symbol: A function is represented using a circle. This symbol is

called a process or a bubble. Bubbles are annotated with the names of

the corresponding functions (see Figure 6.3).

External entity symbol: An external entity such as a librarian, a library

member, etc. is represented by a rectangle. The external entities are

essentially those physical entities external to the software system which

interact with the system by inputting data to the system or by consuming the data produced by the system. In addition to the human users, the external entity symbols can be used to represent external hardware and software such as another application software that would interact with the software being modelled.

Data flow symbol: A directed arc (or an arrow) is used as a data flow symbol. A data flow symbol represents the data flow occurring between two processes or between an external entity and a process in the direction of the data flow arrow. Data flow symbols are usually annotated with the corresponding data names. For example the DFD in Figure 6.3(a) shows three data flows—the data item number flowing from the process read-number to validate-number, data item flowing into read-number, and valid-number flowing out of validate-number.

Data store symbol: A data store is represented using two parallel lines. It

represents a logical file. That is, a data store symbol can represent either a

data structure or a physical file on disk. Each data store is connected to a

process by means of a data flow symbol. The direction of the data flow arrow shows whether data is being read from or written into a data store. An arrow flowing in or out of a data store implicitly represents the entire data of the data store and hence arrows connecting t o a data store need not be annotated with the name of the corresponding data items. As an example of a data store, number is a data store in 

Figure 6.3(b).

Output symbol: The output symbol i s as shown in Figure 6.2. The output

symbol is used when a hard copy is produced.

The notations that we are following in this text are closer to the Yourdon’s

notations than to the other notations. You may sometimes find notations in other books that are slightly different than those discussed here. For

example, the data store may look like a box with one end open. That is

because, they may be following notations such as those of Gane and Sarson[1979].

Important concepts associated with constructing DFD models

Before we discuss how to construct the DFD model of a system, let us

discuss some important concepts associated with DFDs:

Synchronous and asynchronous operations

If two bubbles are directly connected by a data flow arrow, then they are

synchronous. This means that they operate at t he same speed. An

example of such an arrangement is shown in Figure 6.3(a). Here, the

validate-number bubble can start processing only after t h e read

number bubble has supplied data to it; and the read-number bubble

has to wait until the validate-number bubble has consumed its

data. However, if two bubbles are connected through a data store, as in Figure6.3(b) then the speed of operation of the bubbles are independent. This statement can be explained using the following reasoning. The data produced by a producer bubble gets stored in the data store. It is therefore possible

that the producer bubble stores several pieces of data items, even before the consumer bubble consumes any of them.

Figure 6.3: Synchronous and asynchronous data flow.

Data dictionary

Every DFD model of a system must be accompanied by a data dictionary. A data dictionary lists all data items that appear in a DFD model. The data

items listed include all data flows and the contents of all data stores

appearing on all the DFDs in a DFD model. Please remember that the DFD

model of a system typically consists of several DFDs, viz., level 0 DFD, level 1DFD, level 2 DFDs, etc., as shown in Figure 6.4 discussed in new subsection. However, a single data dictionary should capture all the data appearing in all the DFDs constituting the DFD model of a system.

For example, a data dictionary entry may represent that the data gross Pay consists of the components regular Pay and overtime Pay.

grossP ay = regularP ay + overtimeP ay

For the smallest units of data items, the data dictionary simply lists their

name and their type. Composite data items are expressed in terms of

the component data items using certain operators. The operators using

which a composite data item can be expressed in terms of its

component data items are discussed subsequently.

The dictionary plays a very important role in any software development

process, especially for the following reasons:

A data dictionary provides a standard terminology for all relevant data

for use by the developers working in a project. A consistent vocabulary

for data items is very important, since in large projects different

developers of the project have a tendency to use different terms to

refer to the same data, which unnecessarily causes confusion.

The data dictionary helps the developers to determine the definition of

different data structures in terms of their component elements while

implementing the design.

The data dictionary helps to perform impact analysis. That is, it is

possible to determine the effect of some data on various processing

activities and vice versa. Such impact analysis is especially useful when

one wants to check the impact of changing an input value type, or a

bug in some functionality, etc.

For large systems, the data dictionary can become extremely complex and

voluminous. Even moderate-sized projects can have thousands of entries inA data dictionary lists the purpose of all data items and the definition of all composite data items in terms of their component data items. the data dictionary. It becomes extremely difficult to maintain a voluminous

dictionary manually. Computer-aided software engineering (CASE) tools come handy to overcome this problem. Most CASE tools usually capture the data items appearing in a DFD as the DFD is drawn, and automatically generate the data dictionary. As a result, the designers do not have to spend almost any effort in creating the data dictionary. These CASE tools also support some query language facility to query about the definition and usage of data items.

For example, queries may be formulated to determine which data item

affects which processes, or a process affects which data items, or the

definition and usage of specific data items, etc. Query handling is facilitated by storing the data dictionary in a relational database management system (RDBMS).

Data definition

Composite data items can be defined in terms of primitive data items

using the following data definition operators.

+: denotes composition of two data items, e.g. a+b represents data a and b.[,,]: represents selection, i.e. any one of the data items listed inside the

square bracket can occur For example, [a,b] represents either a occurs or b

occurs.

(): the contents inside the bracket represent optional data which may or may not appear.

a+(b) represents either a or a+b occurs.

{}: represents iterative data definition, e.g. {name}5 represents five name data.

{name}* represents zero or more instances of name data.

=: represents equivalence, e.g. a=b+c means that a is a composite data item

comprising of both b and c.

/* */: Anything appearing within /* and */ is considered as comment.