******Created by ebook converter - www.ebook-converter.

com******

Novices usually clutter their DFDs with too many data flow arrow. It
becomes difficult to understand a DFD if any bubble is associated with
more than seven data flows. When there are too many data flowing in
or out of a DFD, it is better to combine these data items into a high-
level data item. Figure 6.7 shows an example concerning how a DFD
can be simplified by combining several data flows into a single high-
level data flow.

Figure 6.7: Illustration of how to avoid data cluttering.

We now illustrate the structured analysis technique through a few

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 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. After representing these four functions in Figure
6.8(b), we observe that the calculation of root mean square essentially
consists of the functions—calculate the squares of the input numbers,
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

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
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

bsq: integer
csq: integer
msq: integer
Example 6.1 is an almost trivial example and is only meant to illustrate the
basic methodology. Now, let us perform the structured analysis for a more
complex problem.
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. As 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 are 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
software that would help it to automate a scheme that it plans to introduce
to encourage 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 staff when he makes any purchase. In this
case, the value of his purchase is credited against his CN. At the end of each
year, the supermarket intends to award surprise gifts to 10 customers who
make the highest total purchase over the year. Also, it intends to award a 22
caret gold coin to every customer 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.

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

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.

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

Figure 6.10: Context diagram for Example 6.3.

Figure 6.11: Level 1 diagram for Example 6.3.

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

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

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

(that is, command to the software) a n d no real data. We have

included it in the DFD because it simplifies the structured design
process 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
customer data and sales data. Should we have combined them into a
single data store? The answer is—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 activities 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
orders with it for various kinds of commodities. The trading house
maintains the names and addresses of its regular customers. Each of
these regular customers should be assigned a unique customer
identification 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 customer.
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
processed any further and an appropriate apology message for the
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

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
issue 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

sufficient quantity to satisfy the 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 purchase 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
determine the orders that are pending and determine the total
quantity required for each of the items. It should find out the addresses
of the vendors 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.

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

Figure 6.13: Context diagram for Example 6.4.

Figure 6.14: Level 1 DFD for Example 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#
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

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
customer-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
generate-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
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

is updated or an item is sold, whereas the vendor data remains

unchanged.
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 implicit 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,
become data stores in the DFD representation. Therefore, to determine
which data should be 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
personal 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.

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

Figure 6.16: Level 1 DFD for Example 6.5.

The level 2 DFD for the manageOwnBook bubble is shown in Figure 6.17.

Figure 6.17: Level 2 DFD for Example 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

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

response: friend-reg-conf-msg + own-book-response + stat-response + borrowed-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 +
serial#.
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 + landline# + 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# + mobile# + book-list
borrowed-book-details: book-title + borrow-date
serial#: integer
Observation: Observe that since there are more than seven functional
requirements 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
DFD models suffer from several shortcomings. The important
shortcomings of DFD models are the following:

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
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.
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
******ebook converter DEMO - www.ebook-converter.com*******