Example 3: Trading-House
Automation System (TAS)
z A large trading house wants us
to develop a software:
y to automate book keeping
activities associated with its
business.
z It has many regular customers:
y who place orders for various
kinds of commodities.
Example 3: Trading-House
Automation System (TAS)
z The trading house maintains names and
addresses of its regular customers.
z Each customer is assigned a unique
customer identification number (CIN).
z As per current practice when a customer
places order:
y the accounts department first checks the
credit-worthiness of the customer.
Example: Trading-House
Automation System (TAS)
z The credit worthiness of a customer is
determined:
y by analyzing the history of his payments to
the bills sent to him in the past.
z If a customer is not credit-worthy:
y his orders are not processed any further
y an appropriate order rejection message is
generated for the customer.
Example: Trading-House
Automation System (TAS)
z If a customer is credit-worthy:
y items he/she has ordered are checked
against the list of items the trading
house deals with.
z The items that the trading house
does not deal with:
y are not processed any further
y an appropriate message for the
customer for these items is generated.
Example: Trading-House
Automation System (TAS)
z The items in a customer's order that
the trading house deals with:
y are checked for availability in the
inventory.
z If the items are available in the
inventory in desired quantities:
y a bill with the forwarding address of
the customer is printed.
y a material issue slip is printed.
Example: Trading-House
Automation System (TAS)
z The customer can produce
the material issue slip at the
store house:
y take delivery of the items.
y inventory data adjusted to
reflect the sale to the
customer.
Example: Trading-House
Automation System (TAS)
z If an ordered item is not
available in the inventory in
sufficient quantity:
y to be able to fulfill pending orders
store details in a "pending-order"
file :
x out-of-stock items along with
quantity ordered.
x customer identification number
Example: Trading-House
Automation System (TAS)
z The purchase department:
y would periodically issue
commands to generate indents.
z When generate indents command
is issued:
y the system should examine the
"pending-order" file
y determine the orders that are pending
y total quantity required for each of the
items.
Example: Trading-House
Automation System (TAS)
z TAS should find out the
addresses of the vendors
who supply the required
items:
y examine the file containing
vendor details (their address, items
they supply etc.)
y print out indents to those
vendors.
Example: Trading-House
Automation System (TAS)
z TAS should also answers
managerial queries:
y statistics of different items
sold over any given period of
time
y corresponding quantity sold
and the price realized.
Context Diagram
indent
query
Trading-House-
Automation-
Manager System
statistics 0
order Generate-
response indent
Customer Purchase-
Department
Level 1 DFD
Customer-history Item-file
query
Accept- inventory statistics
Customer-file order
0.1 Handle-
query
0.3
order Process-
Accepted-orders
order
Vendor-list 0.2
Handle-
indent- Sales-statistics
Indent-request request
0.4
Indents pending-order Material-issue-slip +
bill
Example: Data Dictionary
z response: [bill + material-issue-slip, reject-message]
z query: period /* query from manager regarding sales
statistics*/
z period: [date+date,month,year,day]
z date: year + month + day
z year: integer
z month: integer
z day: integer
z order: customer-id + {items + quantity}*
z accepted-order: order /* ordered items available in inventory
*/
z reject-message: order + message /* rejection message */
z pending-orders: customer-id + {items+quantity}*
z customer-address: name+house#+street#+city+pin
Example: Data Dictionary
z item-name: string
z house#: string
z street#: string
z city: string
z pin: integer
z customer-id: integer
z bill: {item + quantity + price}* + total-amount + customer-
address
z material-issue-slip: message + item + quantity + customer-
address
z message: string
z statistics: {item + quantity + price }*
z sales-statistics: {statistics}*
z quantity: integer
Observation
zFrom the examples,
yobserve that DFDs help
create:
xdata model
xfunction model
Observation
z As a DFD is refined into
greater levels of detail:
y the analyst performs an
implicit functional
decomposition.
y At the same time, refinements
of data takes place.
Guidelines For
Constructing DFDs
z Context diagram should
represent the system as a
single bubble:
y Many beginners commit the
mistake of drawing more than
one bubble in the context
diagram.
Guidelines For
Constructing DFDs
z All external entities should be
represented in the context
diagram:
y external entities should not appear at
any other level of DFD.
z Only 3 to 7 bubbles per diagram
should be allowed:
y each bubble should be decomposed to
between 3 and 7 bubbles.
Guidelines For
Constructing DFDs
z A common mistake
committed by many
beginners:
y attempting to represent
control information in a DFD.
y e.g. trying to represent the
order in which different
functions are executed.
Guidelines For
Constructing DFDs
z A DFD does not represent control
information:
y when or in what order different functions
(processes) are invoked
y the conditions under which different
functions are invoked are not represented.
y For example, a function might invoke one
function or another depending on some
condition.
y Many beginners try to represent this aspect
by drawing an arrow between the
corresponding bubbles.
Example-1
z Check the input value:
y If the input value is less than -1000 or
greater than +1000 generate an error
message
y otherwise search for the number
Gener
Chec ate message
k Error
number numb
er number
Searc [found,not-found]
h
Guidelines For
Constructing DFDs
z If a bubble A invokes either
bubble B or bubble C depending
on some conditions:
y represent the data that flows
from bubble A to bubble B and
bubbles A to C
y not the conditions depending on
which a process is invoked.
Example-2
z A function accepts the book name to be searched from
the user
z If the entered book name is not a valid book name
y generates an error message,
z If the book name is valid,
y searches the book name in the database.
Search-
Good-book- book
Get-book- name
name Book-details
Print-err- Error-
message message
Book-name
Guidelines For
Constructing DFDs
z All functions of the system must be
captured in the DFD model:
y no function specified in the SRS
document should be overlooked.
z Only those functions specified in
the SRS document should be
represented:
y do not assume extra functionality of
the system not specified by the SRS
document.
Commonly made errors
z Unbalanced DFDs
z Forgetting to mention the names of the data flows
z Unrepresented functions or data
z External entities appearing at higher level DFDs
z Trying to represent control aspects
z Context diagram having more than one bubble
z A bubble decomposed into too many bubbles in the next
level
z Terminating decomposition too early
z Nouns used in naming bubbles
Shortcomings of the DFD
Model
z DFD models suffer from several
shortcomings:
z DFDs leave ample scope to be
imprecise.
y In a DFD model, we infer about the
function performed by a bubble from
its label.
y A label may not capture all the
functionality of a bubble.
Shortcomings of the DFD
Model
z For example, a bubble named find-
book-position has only intuitive
meaning:
y does not specify several things:
x what happens when some input
information is missing or is incorrect.
x Does not convey anything regarding what
happens when book is not found
x or what happens if there are books by
different authors with the same book title.
Shortcomings of the DFD
Model
z Control information is not represented:
y For instance, order in which inputs are
consumed and outputs are produced is not
specified.
Customer-history Item-file
Accept- inventory
Customer-file order
order Process-
Accepted-orders
order
Shortcomings of the DFD
Model
z A DFD does not specify
synchronization aspects:
y For instance, the DFD in TAS example
does not specify:
x whether process-order may wait until the
accept-order produces data
x whether accept-order and handle-order
may proceed simultaneously with some
buffering mechanism between them.
TAS: Level 1 DFD
Customer-history Item-file
query
Accept- inventory statistics
Customer-file order
Handle-
query
order Process-
Accepted-orders
order
Vendor-list
Handle-
indent- Sales-statistics
Indent-request request
Indents
pending-order
Shortcomings of the DFD
Model
z The way decomposition is carried out to
arrive at the successive levels of a DFD
is subjective.
z The ultimate level to which
decomposition is carried out is
subjective:
y depends on the choice and judgement of the
analyst.
z Even for the same problem,
y several alternative DFD representations are
possible:
y many times it is not possible to say which
DFD representation is superior or preferable.
Shortcomings of the DFD
Model
z DFD technique does not provide:
y any clear guidance as to how exactly one
should go about decomposing a function:
y one has to use subjective judgement to carry
out decomposition.
z Structured analysis techniques do not
specify when to stop a decomposition
process:
y to what length decomposition needs to be
carried out.
Extending DFD Technique to Real-
Time Systems
z For real-time systems (systems
having time bounds on their
actions),
y essential to model control flow and
events.
y Widely accepted technique: Ward and
Mellor technique.
x a type of process (bubbles) that handles
only control flows is introduced.
x These processes are represented using
dashed circles.
Structured Design
z The aim of structured design
y transform the results of structured analysis
(i.e., a DFD representation) into a structure
chart.
z A structure chart represents the
software architecture:
y various modules making up the system,
y module dependency (i.e. which module calls
which other modules),
y parameters passed among different
modules.
Structure Chart
z Structure chart representation
y easily implementable using programming
languages.
z Main focus of a structure chart:
y define the module structure of a
software,
y interaction among different modules,
y procedural aspects (e.g, how a
particular functionality is achieved)
are not represented.
Basic building blocks of
structure chart
z Rectangular box:
y A rectangular box represents a
module.
y annotated with the name of the
module it represents.
Process-order
Arrows
z An arrow between two modules implies:
y during execution control is passed from one
module to the other in the direction of the
arrow.
root
Process-order Handle-indent Handle-query
Data flow Arrows
z Data flow arrows represent:
y data passing from one module to another in
the direction of the arrow.
root
order
Process-order
Library modules
z Library modules represent
frequently called modules:
y a rectangle with double side edges.
y Simplifies drawing when a module is
called by several modules.
Quick-sort
Selection
z The diamond symbol represents:
y one module of several modules connected to
the diamond symbol is invoked depending on
some condition.
root
Process-order Handle-indent Handle-query
Repetition
z A loop around control flow arrows
denotes that the concerned modules are
invoked repeatedly.
root
Process-order Handle-indent Handle-query
Structure Chart
z There is only one module at the top:
y the root module.
z There is at most one control relationship
between any two modules:
y if module A invokes module B,
y module B cannot invoke module A.
z The main reason behind this restriction:
y consider modules in a structure chart to be
arranged in layers or levels.
Structure Chart
z The principle of abstraction:
y does not allow lower-level
modules to invoke higher-
level modules:
y But, two higher-level modules
can invoke the same lower-
level module.
Example
root
Valid-numbers rms
rms
Valid-numbers
Get-good-data Compute-solution Display-solution
Validate-data
Get-data
Bad Design
Shortcomings of Structure
Chart
z By looking at a structure chart:
y we can not say whether a module
calls another module just once or
many times.
z Also, by looking at a structure
chart:
y we can not tell the order in which
the different modules are
invoked.
Flow Chart (Aside)
z We are all familiar with the flow chart
representations:
y Flow chart is a convenient technique to represent the
flow of control in a system. A=B
z A=B
z if(c == 100) yes no
z P=20
P=20 P=80
z else p= 80
z while(p>20) dummy
z print(student mark) yes no
Print
Flow Chart versus
Structure Chart
z A structure chart differs from a flow
chart in three principal ways:
y It is difficult to identify modules of a
software from its flow chart
representation.
y Data interchange among the modules
is not represented in a flow chart.
y Sequential ordering of tasks inherent
in a flow chart is suppressed in a
structure chart.
Transformation of a DFD Model
into Structure Chart
z Two strategies exist to
guide transformation of a
DFD into a structure
chart:
yTransform Analysis
yTransaction Analysis
Transform Analysis
z The first step in transform
analysis:
y divide the DFD into 3 types of
parts:
xinput,
xlogical processing,
xoutput.
Transform Analysis
z Input portion in the DFD:
y processes which convert input data
from physical to logical form.
y e.g. read characters from the terminal
and store in internal tables or lists.
z Each input portion:
y called an afferent branch.
y Possible to have more than one
afferent branch in a DFD.
Transform Analysis
z Output portion of a DFD:
y transforms output data from logical
form to physical form.
x e.g., from list or array into output
characters.
y Each output portion:
x called an efferent branch.
z The remaining portions of a DFD
y called central transform
Transform Analysis
z Derive structure chart by
drawing one functional
component for:
y the central transform,
y each afferent branch,
y each efferent branch.
Transform Analysis
z Identifying the highest level input and
output transforms:
y requires experience and skill.
z Some guidelines:
y trace the inputs until a bubble is found
whose output cannot be deduced from the
inputs alone.
y Processes which validate input are not
central transforms.
y Processes which sort input or filter data from
it are.
Transform Analysis
z First level of structure chart:
y draw a box for each input and output
units
y a box for the central transform.
z Next, refine the structure chart:
y add subfunctions required by each
high-level module.
y Many levels of modules may required
to be added.
Factoring
z The process of breaking functional
components into subcomponents.
z Factoring includes adding:
y read and write modules,
y error-handling modules,
y initialization and termination modules,
etc.
z Finally check:
y whether all bubbles have been
mapped to modules.
Example 1: RMS
Calculating Software
Data- Compute-
items RMS
0
User result
Context Diagram
Example 1: RMS
Calculating Software
z From a cursory analysis of the
problem description,
y easy to see that the system needs to
perform:
x accept the input numbers from the user,
x validate the numbers,
x calculate the root mean square of the
input numbers,
x display the result.
Example 1: RMS
Calculating Software
numbers
Read- Validate-
numbers numbers
0.1 0.2
Valid -
Data- numbers
items error
Compute-
Display rms
0.4 0.3
result RMS
Example 1: RMS
Calculating Software
z By observing the level 1
DFD:
y identify read-number and
validate-number bubbles as
the afferent branch
y display as the efferent branch.
Example 1: RMS
Calculating Software
Example 2: Tic-Tac-Toe
Computer Game
z As soon as either of the human player or
the computer wins,
y a message congratulating the winner should
be displayed.
z If neither player manages to get three
consecutive marks along a straight line,
y and all the squares on the board are filled up,
y then the game is drawn.
z The computer always tries to win a
game.
Context Diagram for
Example 2
Tic-tac-toe
display software
0
move
Human Player
Level 1 DFD
game
Display-
move board result
Validate- Check-
move board winner
Play-
move
Structure Chart
root
Get-good-move Compute-game Display
Get-move Validate- play-move Check-
move winner
Transaction Analysis
z Useful for designing transaction
processing programs.
y Transform-centered systems:
x characterized by similar processing steps
for every data item processed by input,
process, and output bubbles.
y Transaction-driven systems,
x one of several possible paths through the
DFD is traversed depending upon the input
data value.
Transaction Analysis
z Transaction:
y any input data value that triggers an action:
y For example, selected menu options might
trigger different functions.
y Represented by a tag identifying its type.
z Transaction analysis uses this tag to
divide the system into:
y several transaction modules
y one transaction-center module.
Transaction analysis
Transaction-
center
trans 3
trans 1
trans 2
type 1 type 2 type 3
Level 1 DFD for TAS
Customer-history Item-file
query
Accept- inventory statistics
Customer-file order
Handle-
query
order Process-
Accepted-orders
order
Vendor-list
Handle-
indent- Sales-statistics
Indent-request request
Indents
pending-order
Structure Chart
