TRANSACTION FLOW AND TRANSFORM FLOW MAPPING

Strategies for converting the DFD into Structure Chart

 Transaction Flow Mapping

 Transform Flow Mapping

Steps :

 Break the system into suitably tractable units by means of transaction analysis
 Convert each unit into a good structure chart by means of transform analysis
 Link back the separate units into overall system implementation

Transaction Analysis

The transaction is identified by studying the discrete event types that drive the system. For
example, with respect to railway reservation, a customer may give the following transaction
stimulus:

The three transaction types here are: Check Availability (an enquiry), Reserve Ticket (booking)
and Cancel Ticket (cancellation). On any given time we will get customers interested in giving
any of the above transaction stimuli. In a typical situation, any one stimulus may be entered
through a particular terminal. The human user would inform the system her preference by
selecting a transaction type from a menu. The first step in our strategy is to identify such
transaction types and draw the first level breakup of modules in the structure chart, by creating
separate module to co-ordinate various transaction types. This is shown as follows:
 Ticket Booking System
Transaction choice

Enquiry details status reserve details Booking details Ticket details Return Money

Get Transaction Choice Ticket Enquiry Reserve Ticket Cancel Ticket

The Ticket Reservation System which is a over-all coordinating module, gets the information
about what transaction the user prefers to do through TransChoice. The TransChoice is returned
as a parameter to Main function.

Remember, we are following our design principles faithfully in decomposing our modules. The
actual details of how GetTransactionType ( ) is not relevant for Main function. It may for
example, refresh and print a text menu and prompt the user to select a choice and return this
choice to Main ( ). It will not affect any other components in our breakup, even when this
module is changed later to return the same input through graphical interface instead of textual
menu. The modules Ticket Enquiry, Reserve Ticket and Cancel Ticket are the coordinators of
transactions one, two and three respectively. The details of these transactions are to be exploded
in the next levels of abstraction.

We will continue to identify more transaction centers by drawing a navigation chart of all input
screens that are needed to get various transaction stimuli from the user. These are to be factored
out in the next levels of the structure chart (in exactly the same way as seen before), for all
identified transaction centers.

Transform Analysis

Transform analysis is strategy of converting each piece of DFD (may be from level 2 or level 3,
etc.) for all the identified transaction centers. In case, the given system has only one transaction
(like a payroll system), then we can start transformation from level 1 DFD itself. Transform
analysis is composed of the following five steps [Page-Jones, 1988]:

1. Draw a DFD of a transaction type (usually done during analysis phase)

2. Find the central functions of the DFD
3. Convert the DFD into a first-cut structure chart
4. Refine the structure chart
5. Verify that the final structure chart meets the requirements of the original DFD
 Let us understand these steps through a payroll system example:

 Identifying the central transform

The central transform is the portion of DFD that contains the essential functions of the system
and is independent of the particular implementation of the input and output.

One way of identifying central transform (Page-Jones, 1988) is to identify the centre of the DFD
by pruning off its afferent and efferent branches.
  Afferent stream is traced from outside of the DFD to a flow point inside, just before the
input is being transformed into some form of output (For example, a format or validation
process only refines the input – does not transform it).
 Similarly an efferent stream is a flow point from where output is formatted for better
presentation. The processes between afferent and efferent stream represent the central
transform (marked within dotted lines above).

In the above example, P1 is an input process, and P6 & P7 are output processes. Central
transform processes are P2, P3, P4 & P5 - which transform the given input into some form
of output.

 First-cut Structure Chart

To produce first-cut (first draft) structure chart, first we have to establish a boss module. A boss
module can be one of the central transform processes. Ideally, such process has to be more of a
coordinating process (encompassing the essence of transformation). In case we fail to find a boss
module within, a dummy coordinating module is created

In the above illustration, we have a dummy boss module “Produce Payroll” – which is named in
a way that it indicate what the program is about. Having established the boss module, the afferent
stream processes are moved to left most side of the next level of structure chart; the efferent
stream process on the right most side and the central transform processes in the middle. Here, we
moved a module to get valid timesheet (afferent process) to the left side (indicated in yellow).
The two central transform processes are move in the middle (indicated in orange). By grouping
the other two central transform processes with the respective efferent processes, we have created
two modules (in blue) – essentially to print results, on the right side.

The main advantage of hierarchical (functional) arrangement of module is that it leads to

flexibility in the software. For instance, if “Calculate Deduction” module is to select deduction
rates from multiple rates, the module can be split into two in the next level – one to get the
selection and another to calculate. Even after this change, the “Calculate Deduction” module
would return the same value.
  Refine the Structure Chart

Expand the structure chart further by using the different levels of DFD. Factor down till you
reach to modules that correspond to processes that access source / sink or data stores. Once this
is ready, other features of the software like error handling, security, etc. has to be added. A
module name should not be used for two different modules. If the same module is to be used in
more than one place, it will be demoted down such that “fan in” can be done from the higher
levels. Ideally, the name should sum up the activities done by the module and its sub-ordinates.

 Verify Structure Chart vis-à-vis with DFD

Because of the orientation towards the end-product, the software, the finer details of how data
gets originated and stored (as appeared in DFD) is not explicit in Structure Chart. Hence DFD
may still be needed along with Structure Chart to understand the data flow while creating low-
level design.

Some characteristics of the structure chart as a whole would give some clues about the quality of
the system. Page-Jones (1988) suggest following guidelines for a good decomposition of
structure chart:

 Avoid decision splits - Keep span-of-effect within scope-of-control: i.e. A module can
affect only those modules which comes under it’s control (All sub-ordinates, immediate
ones and modules reporting to them, etc.)
 Error should be reported from the module that both detects an error and knows what the
error is.
 Restrict fan-out (number of subordinates to a module) of a module to seven. Increase fan-
in (number of immediate bosses for a module). High fan-ins (in a functional way)
improves reusability.