CS302: Software Engineering

Rules for Transaction Analysis 

The basic steps in transaction analysis are to define transaction types and processing, develop a structure chart, and further define structure chart elements. A detailed list of transaction analysis activities follows. 

1. Identify the transactions and their defining actions. 

2. Note potential situations in which modules can be combined. For instance, the action is the same but the transaction is different-this identifies a reusable module. 

3. Begin to draw the structure chart with a high-level coordination module as the top of the transaction hierarchy. The coordination module determines transaction type and dispatches processing to a lower level. 

4. For each transaction, or cohesive collection of transactions, specify a transaction module to complete processing it. 

5. For each transaction, decompose and create subordinate function module(s) to accomplish the function( s) of the transaction. If a transaction has only one unique function, then keep the unique action as part of the transaction module identified in the previous step.

6. For functions that are not unique, decompose them into common reusable modules. Make sure that the usage of the module is identical for all using transactions. Specifically identify which transactions use the module. 

7. For each function module, specify subordinate detail module(s) to process whole detail steps as appropriate. If there is only one functional detail step, keep it as part of the function module defined in step 5.

A typical transaction application is money transfer for banks. Transactions for money transfer all have the same information: sending bank, receiving bank, sender, receiver, receiver account number, and amount. There might be other information, but this is required. What makes money transfer a transaction system is that transactions can come from phone, mail, TWX!felex, fax, BankWire, FedWire, and private network sources. Each source of transaction has a different format. Phone, mail, and fax are all essentially manual so the application can require a person to parse the messages and enter them in one format. The other three are electronic messaging systems to be understood electronically. TWX/telex, which are electronic free-form messages, may have field identifiers but have no required order to the information. A summary DFD for a money transfer system might look like Figure 8-17, which shows a deceptively simple process. What makes the process difficult is that the data entry-parse-edit processes are different for each message type, having different edit criteria, formats, and acceptance parameters. The partitioning for the transaction DFD can be either a high-level summary or detailed. The summary partition (see Figure 8-17) shows afferent flows on the summary DFD, which is annotated that structuring is by transaction type. The detailed DFD (see Figure 8-18) shows each type of transaction with its own set of afferent and efferent flows.

To create a first-cut structure chart, one control module is defined for each transaction's afferent stream and efferent stream; there may be only one transform center. For each transaction, the afferent data flows are used to define data couples. The control couples relate to data passed between modules. When control is within a superior module, it is shown via a diamond to indicate selection from among the transaction subprocesses (see Figure 8-19).

FIGURE 8-17 Summary Money Transfer DFD Partitioned

ABC Video Example Transaction Analysis The first step to determining whether you have a transaction application or a transform centered application is to identify all sources of transactions and their types. Table 8-4 contains a list of transactions for ABC Video. As you can see from the list, there are maintenance transactions for customer and video information, there are rental and return transactions, and there are periodic transactions. The only common thread among the transactions is that they share some of the same data. The processing in which they are involved is different and there are no commonalities except reading and writing of files. Therefore, we conclude that ABC Video Rental processing is not a transaction-centered application and move to transform analysis to complete the structure chart.