Unit 3

FUNCTION-ORIENTED SOFTWARE DESIGN

 Function-oriented design view a system as a black-box that provides a set of

services to the users of the software.
 These services provided by a software (e.g., issue book, search book, etc.,) for a
Library Automation S o f t w a r e to its users are also known as the high-level func-
tions supported by the software.
 During the design process, these high-level functions are successively decom-
posed into more detailed functions.
 The term top-down decomposition is often used to denote the successive decompo-
sition of a set of high-level functions into more detailed functions.
 After top-down decomposition has been carried out, the different functions iden-
tified and these functions are mapped to modules and a module structure is
created.

3.1OVERVIEW OF SA/SD METHODOLOGY

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 analysis, the SRS document is transformed into a data flow di-
agram (DFD) model
 During structured design, the DFD model is transformed into a structure chart.
 Figure 6.1: Structured analysis and structured design methodology.

 As shown in Figure 6.1, the structured analysis activity transforms the SRS doc-
ument into a graphic model called the DFD model.
 During structured analysis, functional decomposition of the system is
achieved.
 Each function that the system needs to perform is analyzed and hierarchically
decomposed into more detailed functions.
 During structured design, all functions identified during structured analysis are
mapped to a module structure. This module structure is also called the high-
level design or the software architecture for the given problem. This is repre-
sented using a structure chart.
 The high-level design stage is normally followed by a detailed design stage. Dur-
ing the detailed design stage, the algorithms and data structures for the indi-
vidual modules are designed.
 The detailed design can directly be implemented as a working system using a
conventional programming language.

3.2 STRUCTURED ANALYSIS

The structured analysis technique is based on the following underlying prin-
ciples:

Top-down decomposition approach.

Application of divide and conquer principle. Through this each high- lev-
el function is independently decomposed into detailed functions. Graphical
representation of the analysis results using data flow
Diagrams(DFD)
 A DFD is a hierarchical graphical model of a system that shows the different
processing activities or functions that the system performs and the data inter-
change among those functions.
 In the DFD terminology, each function is called a process or a bubble, each
process consumes some input data and produces some output data.
3.2.1 Data Flow Diagrams (DFDs)
• A DFD is a graphical tool that describes the flow of data through a system and the
functions performed by the system.
• It shows the processes that receive input, perform a series of transformations, and
produce the desired outcomes.
• It does not show the control information (time) at which processes are executed.
• DFD is also called a bubble chart or process model or information flow model.

Primitive symbols used for constructing DFDs

• There are essentially five different types of symbols used for constructing DFDs. The-
se primitive symbols are depicted in Figure 6.2.

Figure 6.2: Symbols used for designing DFDs.

Function symbol or Process : A process is represented by a circle and it denotes transfor-
mations of the input data to produce the output data.
External entity symbol: It is the external entity that represents the source or sink (desti-
nation of data). It is represented by a rectangle.(e.g librarian, library member etc.,)
Data flow symbol: represent the movement of data, i.e., leaving one process and entering
into another process. Data flows are represented by arrows, connecting one data transfor-
mation to another.
 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: Data store is the data at rest. It is represented in parallel lines.
As an example of a data store, number is a data store in Figure 6.3(b).
Output symbol: The output symbol is as shown in Figure 6.2. The output symbol is
used when a hard copy is produced.

Important concepts associated with constructing DFD models

Synchronous and asynchronous operations
 If two bubbles are directly connected by a data flow arrow, then they are syn-
chronous. This means that they operate at t h e 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 t o wait until t h e validate-
number bubble has consumed its data.
 If two bubbles are connected through a data store, as in Figure6.3(b) then the
speed of operation of the bubbles are independent.

Figure 6.3: Synchronous and asynchronous data flow

Data dictionary
A data dictionary lists all data items that appear in a DFD model.
• Data dictionary is metadata that describe composite data structures defined in the
DFD.

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 grossPay con-
sists of the components regularPay and overtimePay.
grossP ay = regularP ay + overtimeP ay
 The dictionary plays a very important role in any software development pro-
cess, 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.
The data dictionary helps the developers to determine the definition of dif-
ferent data structures in terms of their component elements while imple-
menting 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..

 For large systems, the data dictionary can become extremely complex and vo-
luminous. 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.
Data definition
Composite data items can be defined in terms of primitive data items using the
following data definition operators.
1) +: denotes composition of two data items, e.g. a+b represents data a and b.
2) [,,]: 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 o r b oc-
curs.
3) (): the contents inside the bracket represent optional data which may or may not
appear.a+(b) represents either a or a+b occurs.
4) {}: represents iterative data definition, e.g. {name}5 represents five name da-
ta.{name}* represents zero or more instances of name data.
5) =: represents equivalence, e.g. a=b+c means that a is a composite data item
with b and c.
6) /* */: Anything appearing within /* and */ is considered as comment.

3.3 DEVELOPING THE DFD MODEL OF A SYSTEM

 A DFD model of a system graphically represents how each input data is trans-
formed to its corresponding output data through a hierarchy of DFDs.
The DFD model of a problem consists of many of DFDs and a single data dictionary.
 The DFD model of a system i s constructed by using a hierarchy of DFDs (see
Figure 6.4). The top level DFD is called the level 0 DFD or the context diagram.
 This is the most abstract (simplest) representation of the system (highest level).
It is the easiest to draw and understand.
 At each successive lower level D FD s , more and more details are gradually
introduced.
 To develop a higher-level DFD model, processes are decomposed into their
subprocesses and the data flow among these subprocesses are identified.

 Figure 6.4: DFD model of a system consists of a hierarchy of DFDs and a single data dic-
tionary.
3.3.1 Context Diagram
 The context diagram is the most abstract (highest level) data flow representa-
tion of a system.
 It represents the entire system as a single bubble ,we can name it with the
name of the software system being developed (usually a noun
 As an example of a context diagram, consider the context diagram a software
developed to automate the book keeping activities of a supermarket (see
Figure 6.10). The context diagram has been labelled as ‘Supermarket software’.
 The context diagram establishes the context in which the system operates; that
is, who are the users, what data do they input to the system, and what data
they received by the system.
 The various external entities with which the system interacts and the data flow
occurring between the system and the external entities are represented. The data
input to the system and the data output from the system are represented as in-
coming and outgoing arrows. These data flow arrows should be annotated with
the corresponding data names.
 To develop the context diagram of the system, we have to analyse the SRS doc-
ument to identify the different types of users of the system and the data
they would be receiving from the system.
3.3.2 Level 1 DFD
 The level 1 DFD usually contains three to seven bubbles(only important func-
tions).
 To develop the level 1 DFD, examine the high-level functional requirements in
the SRS document.
 If a system has more than seven high-level requirements identified in the SRS
document then some of the related requirements have to be combined and rep-
resented as a single bubble i n the level 1 DFD. (We illustrate construction of
level 1 DFD in example 6.1 to 6.4)
Decomposition
 Each bubble in the DFD represents a function performed by the system. The
bubbles are decomposed into sub functions at the successive levels of the DFD
model.
 Decomposition of a bubble is also known as factoring or exploding a bubble.
 Each bubble at any level of DFD is usually decomposed to anything three to
seven bubbles.
 Decomposition of a bubble should be carried on until a level is reached at
which the function of the bubble can be described using a simple algorithm.
1. Construction of context dia g ra m: Examine the SRS document to de-
termine:
• Different high-level functions that the system needs to perform.
• Data input to every high-level function.
• Data output from every high-level function.
• Interactions (data flow) among the identified high-level functions. Repre-
sent these aspects of the high-level functions in a diagrammatic form,it
iscalled as top-level data flow diagram (DFD) or DFD 0.
Construction of level 1 diagram: Examine the high-level functions described
in the SRS document. If there are three to seven high-level requirements in the
SRS document, then represent each of the high-level function in the form of a bub-
ble. If there are more than seven bubbles, then some of them have to be com-
bined. If there are less than three bubbles, then some of these have to be split.
Construction of lower-level diagrams: Decompose each high-level function into its
constituent subfunctions through the following set of activities:
• Identify the different subfunctions of the high-level function.
• Identify the data input to each of these subfunctions.
• Identify the data output from each of these subfunctions.
• Identify the interactions (data flow) among these subfunctions. Rep-
resent these aspects in a diagrammatic form using a DFD.
Recursively repeat Step 3 for each subfunction until a subfunction can be
represented by using a simple algorithm.
Numbering of bubbles
 It is necessary to number the different bubbles occurring in the DFD to unique-
ly identifying any bubble in the DFD from its bubble number.
 The bubble at the context level is usually assigned the number 0 to indicate
that it is the 0 level DFD. Bubbles at level 1 are numbered, 0.1, 0.2, 0.3,
etc. When a bubble numbered x is decomposed, its children bubble are
numbered x.1, x.2, x.3, etc.
 In this numbering scheme, by looking at the number of a bubble we
can unambiguously determine its level, its ancestors, and its successors.
Balancing DFDs
The DFD model of a system usually consists of many DFDs that are organized in a
hierarchy.
The data that flow into or out of a bubble must match the data flow at the next
level of DFD. This is known as balancing a DFD.
We illustrate the concept of balancing a DFD in Figure 6.5. In the level 1
DFD, data items d1 and d3 flow out of the bubble 0.1 and the data item d2
flows into the bubble 0.1 (shown by the dotted circle). In the next level, bubble
0.1 is decomposed into three DFDs (0.1.1,0.1.2,0.1.3). The decomposition is bal-
anced, as d1 and d3 flow out of the level 2 diagram and d 2 flows in. Please note
that dangling arrows (d1,d2,d3) represent the data flows into or out of a diagram.
How far to decompose?
 A bubble should not be decomposed any further once a bubble is found to
represent a simple set of instructions.
 Large industry standard problems may need decomposition up to level 3 or
level 4. Rarely, if ever, decomposition beyond level 4 is needed.

Figure 6.5: An example showing balanced decomposition.

Commonly made errors while constructing a DFD model

Many beginners commit the mistake of drawing more than one bubble in
the context diagram. Context diagram should depict the system as a single
bubble.
Many beginners create DFD models in which external entities appearing
at all levels of DFDs. All external entities interacting with the system should
be represented only in the context diagram.
It is a common oversight to have either too few or too many bubbles in a
DFD. Only three to seven bubbles per diagram should be allowed.
Many beginners leave the DFDs at the different levels of a DFD model un-
balanced.
A common mistake committed by many beginners while developing a
DFD model is attempting to represent control information in a DFD.

It is important to realise that a DFD represents only data flow, and it does
not represent any control information.
The following are some illustrative mistakes of trying to represent control as-
pects such as:
Illustration 1. A book can be searched in the library catalog by inputting its name.
If the book is available in the library, then the details of the book are displayed.
If the book is not listed in the catalog, then an error message is generated. While
developing the DFD model for this simple problem, many beginners commit the
mistake of drawing an arrow (as shown in Figure 6.6) to indicate that the error
function is invoked after the search book. But, this is a control information and
should not be shown on the DFD.

Figure 6.6: It is incorrect to show control information on a DFD.

 Illustration 2. Another type of error occurs when one tries to represent when
or in what order different functions (processes) are invoked. A DFD simi-
larly should not represent the conditions under which different functions are
invoked.
Illustration 3. If a bubble A invokes either the bubble B or the bubble C de-
pending upon some conditions, we need only to represent the data that flows be-
tween bubbles A and B or bubbles A and C and not the conditions depending on
which the two modules are invoked.

A data flow arrow should not connect two data stores or even a data store
with an external entity.
All the functionalities of the system must be captured by the DFD
model.
Only those functions of the system specified in the SRS document
should be represented. (the system should be overlooked).
Incomplete data dictionary and data dictionary showing incorrect
composition of data items are other frequently committed mistakes.
The data and function names must be relevent.
Novices usually clutter their DFDs with too many data flow arrow. Figure
6.7 shows an example concerning how a DFD can be simplified by combin-
ing several data flows into a single high- level data flow.

Figure 6.7: Illustration of how to avoid da-

ta cluttering.
 Structured Analysis Technique With Examples.
Example 6.1 (RMS Calculating Software) A software system called RMS calculating
software would read three integral numbers from the user in the range of –1000
and +1000 and would determine the root mean square (RMS) of the three input
numbers and display it.
 In this example, the context diagram is simple to draw. The system accepts
three integers from the user and returns the result to him. This has been
shown in Figure 6.8(a).
 To draw the level 1 DFD, from a cursory analysis of the problem description,
we can see that there are four basic functions that the system needs to per-
form—accept the input numbers from the user, validate the numbers, calculate
the root mean square of the input numbers and, then display the result.
 After representing these four functions in Figure6.8(b), we observe that the cal-
culation of root mean square essentially consists of the functions—calculate
the squares of the input numbers calculate the mean, and finally calculate
the root. This decomposition is shown in the level 2 DFD in Figure 6.8(c).

Figure 6.8: Context diagram, level 1, and level 2 DFDs for Example 6.1.
Data dictionary for the DFD model of Example 6.1
data-items: {integer}3
rms: float
valid-data:data-items
a: integer
b: integer
c: integer
asq: integer
bsq: integer
csq: integer
msq: integer
Example 6.2 (Tic-Tac-Toe Computer Game ) Tic-tac-toe is a computer game in
which a human player and the computer make alternate moves on a 3 × 3
square. A move consists of marking a previously unmarked square. The
player who is first to place three consecutive marks along a straight line (i.e.,
along a row, column, or diagonal) on the square wins. A s soon as either of the
human player or the computer wins, a message congratulating the winner should
be displayed. If neither player manages to get three consecutive marks along
a straight line, and all the squares on the board a re filled up, then the game is
drawn. The computer always tries to win a game.
The context diagram and the level 1 DFD are shown in Figure 6.9.
Data dictionary for the DFD model of Example 6.2
move: integer /* number between 1 to 9 */
display: game+result
game: board
board: {integer}9
result: [“computer won”, “human won”, “drawn”]
Example 6.3 (Supermarket Prize Scheme) A super market needs to develop a soft-
ware that would help it to automate a scheme that it plans to introduce to en-
courage regular customers. In this scheme, a customer would have first register by
supplying his/her residence address, telephone number, and the driving license
number. Each customer who registers for this scheme is assigned a unique
customer number (CN) by the computer. A customer can present his CN to the
check out staf f when he makes any purchase. In this case, the value of his pur-
chase is credited against his CN. At the end of each year, the supermarket in-
tends to award surprise gifts to 10 customers who make the highest total pur-
chase over the year. Also, it intends to award a 22 caret gold coin to every cus-
tomer whose purchase exceeded Rs. 10,000. The entries against the CN are reset
on the last day of every year after the prize winners’ lists are generated.
 Figure 6.9: Context diagram and level 1 DFDs for
Example 6.2.
The context diagram for the supermarket prize scheme problem of Example
6.3 is shown in Figure 6.10. The level 1 DFD in Figure 6.11. The level 2 DFD
in Figure 6.12.
 Figure 6.10: Context diagram for Example 6.3.

Figure 6.11: Level 1 diagram for Example 6.3.

 Figure 6.12: Level 2 diagram for
Example 6.3.
Data dictionary for the DFD model of Example 6.3
address: name+house#+street#+city+pin
sales-details: {item+amount}* + CN
CN: integer
customer-data: {address+CN}*
sales-info: {sales-details}*
winner-list: surprise-gift-winner-list + gold-coin-winner-list
surprise-gift-winner-list: {address+CN}*
gold-coin-winner-list: {address+CN}*
gen-winner-command: command
total-sales: {CN+integer}*
Observations: The following observations can be made from the Example 6.3.

1. The fact that the customer is issued a manually prepared customer identity
card or that the customer hands over the identity card each time he
makes a purchase has not been shown in the DFD. This is because these
are item transfers occurring outside the computer.
2. The data generate-winner-list in a way represents control information
 (that is, command to the software) a n d no real data. We have in-
cluded it in the DFD because it simplifies the structured design pro-
cess as we shall realize after we practise solving a few problems. We
could have also as well done without the generate-winner-list data, but this
could have a bit complicated the design.
3. Observe in Figure 6.11 that w e have two separate stores for the cus-
tomer data and sales data. Should we have combined them into a single
data store? The answer i s—No, we should not. If we had combined
them into a single data store, the structured design that would be carried
out based on this model would become complicated. Customer data and
sales data have very different characteristics. For example, customer data
once created, does not change. On the other hand, the sales data
changes frequently and also the sales data is reset at the end of a year,
whereas the customer data is not.

Example 6.4 (Trading-house Automation System (TAS)) A trading house wants us to

develop a computerized system that would automate various book- keeping activ-
ities associated with its business. The following are the salient features of the
system to be developed:

The trading house has a set of regular customers. The customers place or-
ders with it for various ki nds of commodities. The trading house main-
tains the names and addresses of its regular customers. Each of these
regular customers should be assigned a unique customer identifica-
tion numb e r (CIN) by the computer. The customers quote their CIN on
every order they place.
Once order is placed, as per current practice, the accounts department of
the trading house first checks the credit-worthiness of the customer. The
credit-worthiness of the customer is determined by analysing the history of
his payments to different bills sent to him in the past. After automation,
this task has be done by the computer.
If a customer is not credit-worthy, his orders are not processed any further
and an appropriate order rejection message is generated for the cus-
tomer.
If a customer is credit-worthy, the items that he has ordered are
checked against the list of items that the trading house deals with. The
items in the order which the trading house does not deal with, are not pro-
cessed any further and an appropriate apology message for the
 customer for these items is generated.
The items in the customer’s order that the trading house deals with are
checked for availability in the inventory. I f the items are available in the
inventory in desired quantity, then:

– A bill is with the forwarding address of the customer is printed.

– A material issue slip is printed. The customer can produce this material is-
sue slip at the store house and take delivery of the items.
– Inventory data is adjusted to reflect the sale to the customer.

If any of the ordered items are not available in the inventory in suf-
ficient quantity to satisfy t he order, then these out-of-stock items along
with the quantity ordered by the customer and the CIN are stored in a
“pending-order” file for further processing to be carried out when the pur-
chase department issues the “generate indent” command. The purchase
department should be allowed to periodically issue
commands to generate indents. When a command to generate indents is
issued, the system should examine the “pending-order” file to deter-
mine the orders that are pending and determine the total quantity
required for each of the items. It should find out the addresses of the ven-
dors who supply these items by examining a file containing vendor details
and then should print out indents to these vendors.
The system should also answer managerial queries regarding the statistics
of different items sold over any given period of time and the corresponding
quantity sold and the price realised.

The context diagram for the trading house automation problem is shown in
Figure 6.13. The level 1 DFD in Figure 6.14.
 Figure 6.13: Context diagram for Ex-
ample 6.4.

Figure 6.14: Level 1 DFD for Exam-

ple 6.4.
Data dictionary for the DFD model of Example 6.4
response: [bill + material-issue-slip, reject-msg,apology-msg] query:
period /* query from manager regarding sales statistics*/ period:
[date+date,month,year,day]
date: year + month + day year: integer
 month: integer day: integer customer-id: integer order:
customer-id + {items + quantity}* + order#
accepted-order: order /* ordered items available in inventory */
reject-msg: order + message /* rejection message */ pending-
orders: customer-id + order# + {items+quantity}* customer-
address: name+house#+street#+city+pin
name: string
house#: string
street#: string
city: string
pin: integer custom-
er-id: integer
customer-file: {customer-address}* + customer-id
bill: {item + quantity + price}* + total-amount + customer-address +
order#
material-issue-slip: message + item + quantity + customer-address
message: string
statistics: {item + quantity + price }*
sales-statistics: {statistics}* + date
quantity: integer
order#: integer /* unique order number generated by the program */
price: integer
total-amount: integer gener-
ate-indent: command
indent: {item+quantity}* + vendor-address
indents: {indent}*
vendor-address: customer-address
vendor-list: {vendor-address}* item-
file: {item}*
item: string
indent-request: command
Observations: The following observations can be made from Example 6.4.
1. In a DFD, if two data stores deal with different types of data, e.g. one type
of data is invariant with time whereas another varies with time, (e.g.
vendor address, and inventory data) it is a good idea to represent them as
separate data stores.

If two types of data always get updated at the same time, they should be stored
in a single data store. Otherwise, separate data stores should be used for them.
The inventory data changes each time supply arrives and the inventory
 is updated or an item is sold, whereas the vendor data remains un-
changed.
2. If we are developing the DFD model of a process which is already being
manually carried out, then the names of the registers being maintained in
the manual process would appear as data stores in the DFD model. For
example, if TAS is currently being manually carried out, then normally
there would registers corresponding to accepted orders, pending orders,
vendor list, etc.
3. We can observe that DFDs enable a software developer to develop the data
domain and functional domain model of the system at the same time. As
the DFD is refined into greater levels of detail, the analyst performs an im-
plicit functional decomposition. At the same time, the DFD refinement
automatically results in refinement of corresponding data items.
4. The data that are maintained in physical registers in manual processing, be-
come data stores in the DFD representation. Therefore, to determine which
data should b e represented as a data store, it is useful t o try to imagine
whether a set of data items would be maintained in a register in a manual
system.
Example 6.5 (Personal Library Software) Perform structured analysis for the per-
sonal library software of Example 6.5.
The context diagram is shown in Figure 6.15.

Figure 6.15: Context diagram for Example 6.5.

The level 1 DFD is shown in Figure 6.16.
 Figure 6.16: Level 1 DFD for Ex-
ample 6.5.
The level 2 DFD for the manageOwnBook bubble is shown in Figure 6.17.

Figure 6.17: Level 2 DFD for Ex-

ample 6.5.
Data dictionary for the DFD model of Example 6.5
input-data: friend-reg-data + own-book-data + stat-request + borrowed-book-data
response: friend-reg-conf-msg + own-book-response + stat-response + bor-
rowed-book-response
own-book-data: query-details + own-book-details + query-outstanding-books-
option + return-own book- details + reg-own-book-data
own-book-response: query-book-response + issue-book-msg + friend-details +
return-book- msg +
seri-
al#.
borrowed-book-data: borrowed-book-details + book-return-details + display-books-
option borrowed-book- response: reg-msg + unreg-msg + borrowed-books-list
friend-reg-data: name + address + land-
line# + mobile#
own-book-details: friend-reg-data + book-title +
data-of-issue return-own-book-details: book-title
+ date-of-return
friend-details: name + address + landline# + mo-
bile# + book-list borrowed-book-details: book-title
+ borrow-date
serial#: in-
teger
Observation: Observe that since there are more than seven functional re-
quirements for the personal library software, related requirements have been
combined to have only five bubbles in the level 1 diagram. Only level 2
DFD has been shown, since the other DFDs are trivial and need not be drawn.
Shortcomings of the DFD model
Imprecise 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
i s missing or is incorrect. Further, t h e find- book-position bubble may not
convey anything regarding what happens when the required book is missing.
Not-well defined control aspects are not defined by a DFD. For in-
stance, the order in which inputs are consumed and outputs are pro-
duced by a bubble is not specified. A DFD model does not specify the or-
der in which the different bubbles are executed. Representation of such
aspects is very important for modelling real-time systems. Decomposition:
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. D
u e 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.
Improper data flow diagram: T h e d a t a flow diagramming technique does
not provide any specific guidance as to how exactly to decompose a given
function into its subfunctions and we have to use subjective judgment to
carry out decomposition.

6.3.3 Extending DFD Technique to Make it Applicable to Real-time

Systems
In a real-time system, some of the high-level functions are associated with
deadlines. Therefore, a function must not only produce correct results but al-
so should produce them by some prespecified time. For real-time systems,
execution time is an important consideration for arriving at a correct de-
sign. Therefore, 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 represent-
ing 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 represents the behavior of the system in two dif-

ferent ways:

It contains a state transition diagram (STD). The STD is a sequential

specification of behaviour.
It contains a p r o g r a m activation table (PAT). The PAT is a
combinatorial specification of behaviour. PAT represents invocation
sequence of bubbles in a DFD.
3.4 STRUCTURED DESIGN
The aim of structured design is to transform the results of the structured
analysis (that i s , the DFD model) into a structure chart. A structure
chart represents the software architecture. The various modules making up
the system, the module dependency (i.e. which module calls which other
modules), and the parameters that are passed among the different
modules. The structure chart representation can be easily implemented
using some programming language. Since the main focus in a structure chart
representation is on module structure of a software and the interaction
among the different modules, the procedural aspects (e.g. how a partic-
ular functionality is achieved) are not represented.
The basic building blocks using which structure charts are designed are as fol-
lowing:
Rectangular boxes: A rectangular box represents a module. Usually, every rec-
tangular box is annotated with the name of the module it represents. Module invo-
cation arrows: An arrow connecting two modules implies that
during program execution control is passed from one module to the other in
the direction of the connecting arrow. However, just by looking at the
structure chart, we cannot say whether a modules calls another module just once
or many times. Also, just by looking at the structure chart, we cannot tell the
order in which the different modules are invoked.
Data flow arrows: These are small arrows appearing alongside the module invo-
cation arrows. The data flow arrows are annotated with the corre-
sponding data name. Data flo w arrows represent the fact that the named
data passes from one module to the other in the direction of the arrow.
Library modules: A library module is usually represented by a rectangle with double
edges. Libraries comprise the frequently called modules. Usually, when a
module is invoked by many other modules, it is made into a library module.
Selection: The diamond symbol represents the fact that one module of several
modules connected with the diamond symbol i s invoked depending on the out-
come of the condition attached with the diamond symbol.
Repetition: A loop around the control flow arrows denotes that the respective
modules are invoked repeatedly.
In any structure chart, there should be one and only one module at the top,
called the root. There should be at most one control relationship between any two
modules in the structure chart. This means that if module A invokes module B,
module B cannot invoke module A. The main reason behind this restriction is that
we can consider the different modules of a structure chart to be arranged in lay-
ers 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 t wo
higher-level modules to invoke the same lower-level module. An example of a
properly layered design and another of a poorly layered design are shown in Figure
6.18.

Figure 6.18: Examples of properly and poorly layered designs.

Flow chart versus structure chart
We are all familiar with the flow chart representation of a program. Flow
chart is a convenient technique to represent t h e flo w of control in a pro-
gram. A structure chart diffe rs from a flow chart in three principal ways:

It is usually difficult to identify the different modules of a program from its

flow chart representation.
Data interchange among different modules is not represented in a flow
chart.
Sequential ordering of tasks that i s inherent to a flow chart is
suppressed in a structure chart.
6.4.1 Transformation of a DFD Model into Structure Chart
Systematic techniques are available to transform the DFD representation of a
problem into a module structure represented by as a structure chart.
Structured design provides two strategies to guide transformation of a DFD
into a structure chart:

Transform analysis
Transaction analysis

Normally, one would start with the level 1 DFD, transform it into module
representation using either the transform or transaction analysis and then pro-
ceed toward 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.
Whether to apply transform or transaction processing?
Given a specific DFD of a model, how does one decide whether to apply
transform analysis or transaction analysis? For this, one would have to ex-
amine the data input to the diagram. The data input to the diagram can be
easily spotted because they are represented by dangling arrows. If all the
data flow into the diagram are processed in similar ways (i.e. if all the input
data flow arrows are incident on the same bubble in the DFD) then trans-
form analysis is applicable. Otherwise, transaction analysis is applicable.
Normally, transform analysis is applicable only to very simple processing.
Please recollect that the bubbles are decomposed until it represents a very sim-
ple processing that can be implemented using only a few lines of code. Therefore,
transform analysis is normally applicable at the lower levels of a DFD model. Each
different way in which data is processed corresponds to a separate transaction.
Each transaction corresponds to a functionality that lets a user perform a meaning-
ful piece of work using the software.
Transform analysis
Transform analysis identifies the primary functional components (modules)
and the input and output data for these components. The first step in
transform analysis is to divide the DFD into three types of parts:
 • Input.
• Processing.
• Output.
The input portion in the DFD includes processes that transform input data fro
m physical (e.g, character from terminal) to logical form (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 form to physical
form. Each output portion is called an 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 each for the central transform, the afferent and ef-
ferent branches. These are drawn below a root module, which would invoke these
modules.
Identifying the input and output parts requires experience and skill. One possible
approach is to trace the input data until a bubble is found whose output data
cannot be deduced from its inputs alone. Processes which validate input are
not central transforms. Processes which sort input o r filter data from it are cen-
tral tansforms. T h e first level o f structure chart is produced by representing
each input and output unit as a box and each central transform as a single
box.
In the third step of transform analysis, the structure chart is refined by adding
subfunctions required by each of the high-level functional components. Many levels
of functional components may be added. This process of breaking functional com-
ponents into subcomponents is called factoring. Factoring includes adding read and
write modules, error-handling modules, initialisation and termination process, iden-
tifying consumer modules etc. The factoring process is continued until all bubbles
in the DFD are represented in the structure chart.
Example 6.6 Draw the structure chart for the RMS software of Example 6.1.
By observing the level 1 DFD of Figure 6.8, we can identify validate-input as the
afferent branch and write-output as the efferent branch. The remaining (i.e., com-
pute-rms) as the central transform. By applying the step 2 and step
3 of transform analysis, we get the structure chart shown in Figure 6.19.
 Figure 6.19: Structure chart for Example 6.6.
Example 6.7 Draw the structure chart for the tic-tac-toe software of
Example 6.2.
The structure chart for the Tic-tac-toe software is shown in Figure 6.20. Ob-
serve that the check-game-status bubble, though produces some outputs. i s not
really responsible for converting logical data to physical data. On the other hand,
it carries out the processing involving checking game status. That is the main rea-
son, why we have considered it as a central transform and not as an efferent type
of module.
Transaction analysis
Transaction analysis is an alternative to transform analysis and is useful while de-
signing transaction processing programs. A transaction allows the user to perform
some specific type of work by using the software. For example, ‘issue book’, ‘return
book’, ‘query book’, etc., are transactions.
 Figure 6.20: Structure chart for Ex-
ample 6.7.

As in transform analysis, first all data entering into the DFD need to be
identified. In a transaction-driven system, different data items may pass
through different computation paths through the DFD. This is in contrast to a
transform centered system where each data item entering the DFD goes through
the same processing steps. Each different way in which input data is processed is a
transaction. A simple way to identify a transaction is the following. Check the input
data. The number of bubbles on which the input data to the DFD are incident de-
fines the number of transactions. However, some transactions may not require any
input data. These transactions can be identified based on the experience gained
from solving a large number of examples.
For each identified transaction, trace the input data to the output. All the trav-
ersed 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 as a module.
Every transaction carries a tag identifying its type. Transaction analysis uses this
tag to divide the system into transaction modules a n d a transaction-center mod-
ule.
Example 6.8 Draw the structure chart for the Supermarket Prize Scheme
software of Example 6.3.
The structure chart for the Supermarket Prize Scheme software is shown in
Figure 6.21.
Example 6.9 Draw the structure chart for the trade-house automation system
(TAS) software of Example 6.4.
The structure chart for the trade-house automation system (TAS) software of
Example 6.4 is shown in Figure 6.22.
By observing the level 1 DFD of Figure 6.14, we can see that the data input to
the diagram are handled by different bubbles and therefore transaction analysis is
applicable to this DFD. Input data to this DFD are handled in three different ways
(accept-order, accept- indent-request, and handle-query), we have three different
transactions corresponding to these as shown in Figure
6.22.

Figure 6.21: Structure chart for Example 6.8.

Figure 6.22: Structure chart for Example 6.9.

Word of caution
 We should view transform and transaction analyses as guidelines, rather than
rules. We should apply these guidelines in the context of the problem
and handle the pathogenic cases carefully.
Example 6.10 Draw the structure chart for the personal library software of
Example 6.6.
The structure chart for the personal library software is shown in Figure
6.23.

Figure 6.23: Structure chart for Ex-

ample 6.10.

6.5 DETAILED DESIGN

During detailed design the pseudo code description of the processing and the
different data structures are designed for the different modules of the
structure chart. These are usually described in the form of module specifi-
cations (MSPEC). MSPEC is usually written using structured English. The
MSPEC for the non-leaf modules describe the different conditions under
which the responsibilities are delegated to the lower- level modules. The
MSPEC for the leaf-level modules should describe in algorithmic form how
the primitive processing steps are carried out. To develop the MSPEC of a
module, it is usually necessary to refer to the DFD model and the SRS doc-
ument to determine the functionality of the module.
6.6 DESIGN REVIEW

After a design is complete, the design is required to be reviewed. The review

team usually consists of members with design, implementation, testing, and
maintenance perspectives, who may or may not be the members of the de-
velopment team. Normally, members of the team who would code the de-
sign, and test the code, the analysts, and the maintainers attend the review
meeting. The review team checks the design documents especially for the
following aspects:
Traceability: Whether each bubble of the DFD can be traced to some module in
the structure chart a n d vice versa. They check whether each functional re-
quirement in the SRS document can be traced to some bubble in the DFD model
and vice versa.
Correctness: Whether all the algorithms and data structures of the detailed design
are correct.
Maintainability: Whether the design can be easily maintained in future.
Implementation: Whether the design can be easily and efficiently be im-
plemented.
After the points raised by the reviewers is addressed by the designers, the
design document becomes ready for implementation.