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.
 Data dictionary
 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}*
Shortcomings of the DFD model
 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.
 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 modeling real-time systems.
 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. Due 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.
 The data flow diagramming technique does not provide any
specific guidance as to how exactly to decompose a given
function into its sub functions and we have to use subjective
judgment to carry out decomposition.
STRUCTURED DESIGN
 The aim of structured design is to transform the results of
the structured analysis (that is, 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 basic building blocks using which structure charts are
designed are as following:
 Rectangular boxes: A rectangular box represents a module.
Usually, every rectangular box is annotated with the name of the
module it represents.
 Module invocation 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 or
the order in which the different modules are invoked.
 Data flow arrows: These are small arrows appearing alongside the module
invocation arrows. The data flow arrows are annotated with the
corresponding data name. Data flow 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 is invoked depending
on the outcome 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 layers 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 two higher-level modules to invoke the same
lower-level module.
Flow chart versus structure chart
 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 is inherent to a flow chart is
suppressed in a structure chart.
Transformation of a DFD Model into
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 proceed 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?
 Examine the data input to the diagram.
 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 transform analysis is applicable. Otherwise, transaction
analysis is applicable.
 Normally, transform analysis is applicable only to very simple
processing.
 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
meaningful 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 from 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 efferent branches. These are drawn
below a root module, which would invoke these modules.
 In the third step of transform analysis, the structure chart is
refined by adding sub functions required by each of the high-level
functional components.
 Many levels of functional components may be added. This process
of breaking functional components into subcomponents is called
factoring.
 Factoring includes adding read and write modules, error-handling
modules, initialization and termination process, identifying
consumer modules etc.
 The factoring process is continued until all bubbles in the DFD are
represented in the structure chart.
Transaction analysis
 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.
 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 defines
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 traversed 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.
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 specifications
(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.
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 development team.
 Normally, members of the team who would code the design,
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 and vice versa. They check whether each
functional requirement 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
implemented.
After the points raised by the reviewers is addressed by the
designers, the design document becomes ready for implementation.