Function-Oriented Software Design

(continued):

PPT By :Dr. R. Mall

 Organization of this Lecture
•A larger example of Structured Analysis
•Structured Design
• A major objective of this lecture is that you should be able to
develop structured design from any DFD model.
•Examples
•Summary
Example 3: Trading-House Automation System (TAS)

•A large trading house wants us to develop a software:

• to automate book keeping activities associated with its business.

•It has many regular customers:

• who place orders for various kinds of commodities.
 Example 3: Trading-House Automation
System (TAS)

• The trading house maintains names and addresses of its regular

customers.

• Each customer is assigned a unique customer identification number

(CIN).

• As per current practice when a customer places order:

• the accounts department first checks the credit-worthiness of the customer.
 Example: Trading-House Automation
System (TAS)
• The credit worthiness of a customer is determined:
• by analyzing the history of his payments to the bills sent to him in the past.

• If a customer is not credit-worthy:

• his orders are not processed any further

• an appropriate order rejection message is generated for the customer.

 Example: Trading-House Automation
System (TAS)
• If a customer is credit-worthy:
• items he/she has ordered are checked against the list of items the trading house deals
with.

• The items that the trading house does not deal with:
• are not processed any further

• an appropriate message for the customer for these items is generated.

 Example: Trading-House Automation
System (TAS)
• The items in a customer's order that the trading house deals with:
• are checked for availability in the inventory.

• If the items are available in the inventory in desired quantities:

• a bill with the forwarding address of the customer is printed.

• a material issue slip is printed.

 Example: Trading-House Automation
System (TAS)
•The customer can produce the material issue slip at the
store house:
•take delivery of the items.

•inventory data adjusted to reflect the sale to the customer.

 Example: Trading-House Automation
System (TAS)

•If an ordered item is not available in the inventory

in sufficient quantity:
•to be able to fulfill pending orders store details in a
"pending-order" file :
•out-of-stock items along with quantity ordered.
•customer identification number
 Example: Trading-House Automation
System (TAS)

•The purchase department:

• would periodically issue commands to generate indents.

•When generate indents command is issued:

• the system should examine the "pending-order" file
• determine the orders that are pending
• total quantity required for each of the items.
 Example: Trading-House Automation
System (TAS)

•TAS should find out the addresses of the vendors who

supply the required items:
•examine the file containing vendor details (their address, items they

supply etc.)

•print out indents to those vendors.

 Example: Trading-House Automation
System (TAS)
•TAS should also answers managerial queries:
•statistics of different items sold over any given period of
time

•corresponding quantity sold and the price realized.

Context Diagram
indent
query
Trading-House-A
utomation-Syste
Manager m
statistics 0

Generate-i
order ndent

response
Customer Purchase-Depa
rtment
Level 1 DFD
Customer-history Item-file
query
statistics
Accept-o
inventory
Customer-file rder
0.1 Handle-q
uery
0.3
order Process-o
Accepted-orders rder
Vendor-list 0.2

Handle-in
dent-requ Sales-statistics
Indent-request est
0.4 Material-issue-slip
Indents pending-order + bill
Example: Data Dictionary

• response: [bill + material-issue-slip, reject-message]

• query: period /* query from manager regarding sales statistics*/
• period: [date+date,month,year,day]
• date: year + month + day
• year: integer
• month: integer
• day: integer
• order: customer-id + {items + quantity}*
• accepted-order: order /* ordered items available in inventory */
• reject-message: order + message /* rejection message */
• pending-orders: customer-id + {items+quantity}*
• customer-address: name+house#+street#+city+pin
Example: Data Dictionary
• item-name: string
• house#: string
• street#: string
• city: string
• pin: integer
• customer-id: integer
• bill: {item + quantity + price}* + total-amount + customer-address
• material-issue-slip: message + item + quantity + customer-address
• message: string
• statistics: {item + quantity + price }*
• sales-statistics: {statistics}*
• quantity: integer
Observation
•From the examples,
•observe that DFDs help create:
•data model

•function model
Observation
•As a DFD is refined into greater levels of detail:
•the analyst performs an implicit functional
decomposition.

•At the same time, refinements of data takes place.

 Guidelines For Constructing DFDs
•Context diagram should represent the system as a
single bubble:
•Many beginners commit the mistake of drawing more than
one bubble in the context diagram.
 Guidelines For Constructing DFDs
•All external entities should be represented in the context
diagram:
• external entities should not appear at any other level of DFD.

•Only 3 to 7 bubbles per diagram should be allowed:

• each bubble should be decomposed to between 3 and 7 bubbles.
 Guidelines For Constructing DFDs
•A common mistake committed by many
beginners:
•attempting to represent control information in a
DFD.
•e.g. trying to represent the order in which different
functions are executed.
 Guidelines For Constructing DFDs
• A DFD does not represent control information:
• when or in what order different functions (processes) are invoked

• the conditions under which different functions are invoked are not represented.

• For example, a function might invoke one function or another depending on

some condition.

• Many beginners try to represent this aspect by drawing an arrow between the
corresponding bubbles.
 Example-1
• Check the input value:
• If the input value is less than -1000 or greater than +1000
generate an error message
• otherwise search for the number

Gener
Chec ate
Error message
k
number numb
er
number Searc
h
[found,not-found]
 Guidelines For Constructing DFDs

•If a bubble A invokes either bubble B or bubble C depending

on some conditions:
• represent the data that flows from bubble A to bubble B and
bubbles A to C

• not the conditions depending on which a process is invoked.

 Example-2
• A function accepts the book name to be searched from the user
• If the entered book name is not a valid book name
• generates an error message,
• If the book name is valid,
• searches the book name in the database.

Good-book-n Search-boo
ame k
Get-book-n
ame Book-details

Print-err-
message Error-messag
Book-name e
 Guidelines For Constructing DFDs
• All functions of the system must be captured in the DFD model:
• no function specified in the SRS document should be overlooked.

• Only those functions specified in the SRS document should be

represented:
• do not assume extra functionality of the system not specified by the SRS
document.
 Commonly made errors
• Unbalanced DFDs
• Forgetting to mention the names of the data flows
• Unrepresented functions or data
• External entities appearing at higher level DFDs
• Trying to represent control aspects
• Context diagram having more than one bubble
• A bubble decomposed into too many bubbles in the next level
• Terminating decomposition too early
• Nouns used in naming bubbles
 Shortcomings of the DFD Model
•DFD models suffer from several shortcomings:

•DFDs leave ample scope to be imprecise.

• In a DFD model, we infer about the function performed by a bubble
from its label.

• A label may not capture all the functionality of a bubble.

 Shortcomings of the DFD Model
• For example, a bubble named find-book-position has only intuitive
meaning:
• does not specify several things:
• what happens when some input information is missing or is incorrect.

• Does not convey anything regarding what happens when book is not found

• or what happens if there are books by different authors with the same book title.
Shortcomings of the DFD Model
• Control information is not represented:
• For instance, order in which inputs are consumed and outputs
are produced is not specified.

Customer-history Item-file

Accept-o inventory
Customer-file rder

order
Process-o
Accepted-orders rder
 Shortcomings of the DFD Model
•A DFD does not specify synchronization aspects:
• For instance, the DFD in TAS example does not specify:
• whether process-order may wait until the accept-order produces data

• whether accept-order and handle-order may proceed simultaneously with

some buffering mechanism between them.
TAS: Level 1 DFD
Customer-history Item-file
query
statistics
Accept-o inventory
Customer-file rder
Handle-q
uery
order Process-o
Accepted-orders rder
Vendor-list

Handle-in
dent-requ Sales-statistics
Indent-request est
Indents
pending-order
 Shortcomings of the DFD Model
• The way decomposition is carried out to arrive at the successive levels of a DFD is
subjective.
• The ultimate level to which decomposition is carried out is subjective:
• depends on the choice and judgement of the analyst.

• Even for the same problem,

• several alternative DFD representations are possible:
• many times it is not possible to say which DFD representation is superior or preferable.
 Shortcomings of the DFD Model
• DFD technique does not provide:
• any clear guidance as to how exactly one should go about decomposing a function:

• one has to use subjective judgement to carry out decomposition.

• Structured analysis techniques do not specify when to stop a

decomposition process:
• to what length decomposition needs to be carried out.
 Extending DFD Technique to Real-Time
Systems

•For real-time systems (systems having time bounds on their

actions),
• essential to model control flow and events.

• Widely accepted technique: Ward and Mellor technique.

• a type of process (bubbles) that handles only control flows is introduced.

• These processes are represented using dashed circles.

DFD to Structure Chart
• Transform Analysis
• Input – afferent branch
• Processing – central transform
• Output – efferent branch
• Process which validate input are not in central transform
• Process which sort input or filter data from it are central transform
• Transaction Analysis-alternative to transform analysis
• Transaction allows the user to perform some specific type of work by using
this software
• No. of bubbles on which input data to DFD are incident defines the
transaction
• For each identified transactions trace the input data to the output
Structure chart for RMS Calculator
THANKS….

PPT By :Dr. R. Mall 39