Transform Flow And Transaction Analysis

Published Date: 02 Nov 2017

Introduction

In this lecture, the aim of structured design is distinguished, as well as discussing what a structure chart is, how it differs from a flow chart, and recognize the activities involved in transform analysis. We describe the mapping of data flow into software architecture in detail. Finally, we also present transform and transaction analysis in detail.

Learning Outcomes

Be familiar with the aim of structured design

Be familiar with transform and transaction analysis

11.0 Introduction

The objective of structured design is to convert the outcome of structured analysis (e.g. DFDs) into a structure chart. Structured design provides two methods to guide transformation of a DFD into a structure chart. These two methods are the transform analysis and transaction analysis.

11.1 Software Architecture

Software architecture is the first step in producing a software design. The software architecture of a program or computing system is the structure or structures of the system, which comprise Software components, the externally visible properties of those components, and the relationships among them.

Software architecture is not operational Software. It is a representation that has the following advantages:

It enables software engineer to analyze the effectiveness of the design in meeting its stated requirements

It enables software engineer to consider architectural alternatives at a stage when making design changes is still relatively easy

It enables software engineer to reduce the risks associated with the construction of the Software

An architecture comprises of a fairly small, easy to understand representation of how the system is made up and how its various functions interlink.

An architecture establishes design requirements from an early stage in the development cycle, which leads to an efficient and successful project.

There are three levels in the design of software systems: These are:

architecture design

code design

executable code design

At the architecture design level, the following is defined:

System capabilities are identified in the requirements specification with the system components that will implement them.

The interconnections among modules are described.

Operators that create systems from subsystems are defined

At the code design level, the following is applicable:

The system is described at the level of algorithms and data structures, and

The components are programming language primitives such as numbers, characters, pointers and control threads (array, files, procedures, etc..)

At the executable design level which is a lower level of detail the design engineer discusses memory allocation, data format, bit patterns, and so on.

11.2 Structure Design

The reasons for using structured design and to implement the two transforms include the following:

To move from an abstract system representation to a more physical one.

To reduce ambiguity which may arise from subjective interpretations.

To move from data flow concepts to program structure concepts.

Structured design, considered as a tool that converts data flow diagrams (DFDs) to software architecture can be described as a data-flow-oriented design method.

How a DFD is developed depends on the type of ‘information flow’ in question. As well as this, how a DFD is converted into software structure also depends on two mapping methods.

There are two types of information flow in DFDs:

Transform flow: The mapping used in this case is the transform mapping.

Transaction flow: The mapping used in this case is the transaction mapping.

Commonly, level 1 DFD is used and converted into module representation. This can be done using transform analysis of transaction analysis. Once this is done, lower-level DFDs are taken into account. At every conversion that takes place, one has to decide procedure is more suitable to use; transform analysis or transaction analysis. This is discussed in the following sections.

Structure Chart: A structure chart represents the software architecture. Illustrates the various modules that form the system, in addition to how they interact with one another and the conditions of this interaction. This makes the structure chart an easy tool to develop using a programming language. Due to the focus of the structure chart being the illustration of the modules of the system and how they interact with one another, the way these modules function is not included as a result.

The main notations used to develop structure charts are as follows:

Rectangular boxes: Represent modules.

Module invocation arrows: Represents the flow of control from one module to the other.

Data flow arrows: Data name is attached to the arrows. The direction of the arrow signifies the direction of the data, from one module to the other.

Library modules: Represented by a double edged rectangle.

Selection: Represented by a diamond.

Repetition: Represented by a loop.

Table 1 presents a comparison between structure charts and flow charts.

Structure charts

Flow charts

Function

Represents the software architecture. Illustrates the various modules that form the system, in addition to how they interact with one another and the conditions of this interaction.

A technique used to show the flow of control within a system.

Representation of software modules

Easy to identify various modules using a structure chart.

Difficult to identify various modules using a flow chart.

Representation of data interchange among different modules

Data interchange among different modules is represented in a structure chart.

Data interchange among different modules is not represented in a flow chart.

Representation of sequential ordering of tasks

Sequential ordering of tasks is hidden in a structure chart.

Sequential ordering of tasks is inbuilt/present in a flow chart.

Table 1: A comparison between structure charts and flow charts

General Steps Involved in structured design are:

The type of data flow is established

In this step the nature of the data flowing between processes is defined.

Determine flow boundaries (switch points)

This includes if the boundary is input boundary, output boundary, hub boundary or action boundary.

Map the abstract DFD on to a particular program structure

Determine if the program structure is a transformational structure or transactional structure

Define a valid control structure

This step is also known as "first-level" factoring. It depends on whether transformational or transactional models are used.

The control structure is either "Call-and-return" for transformational model or "Call-and-act" for transactional model.

5. Refine (tune) the resulting structure

This step is also known as "second-level factoring". It maps Input/Output flow bounded parts of DFD.

6. Supplement and tune the final architectural structure

Apply basic module independence concepts (i.e. Explode or implode modules according to coupling/cohesion requirements) to obtain an easier implementation.

11.3 Transform Mapping (Analysis)

A structure chart is produced by the conversion of a DFD diagram; this conversion is described as ‘transform mapping (analysis)’. It is applied through the ‘transforming’ of input data flow into output data flow.

Transform analysis establishes the modules of the system, also known as the primary functional components, as well as the inputs and outputs of the identified modules in the DFD. Transform analysis is made up of a number of steps that need to be carried out. The first one is the dividing of the DFD into 3 parts:

Input

Logical processing

Output

The ‘input’ part of the DFD covers operations that change high level input data from physical to logical form e.g. from a keyboard input to storing the characters typed into a database. Each individual instance of an input s called an ‘afferent branch’.

The ‘output’ part of the DFD is similar to the ‘input’ part in that it acts as a conversion process. However, the conversion is concerned with the logical output of the system into a physical one e.g. text stored in a database converted into a printed version through a printer. Also, similar to the ‘input’, each individual instance of an output is called as ‘efferent branch’. The remaining part of a DFD is called the central transform.

Once the above step has been conducted, transform analysis moves onto the second step; the structure chart is established by identifying one module for the central transform, the afferent and efferent branches. These are controlled by a ‘root module’ which acts as an ‘invoking’ part of the DFD.

In order to establish the highest input and output conversions in the system, a ‘bubble’ is drawn out. In other words, the inputs are mapped out to their outputs until an output is found that cannot be traced back to its input. Central transforms can be classified as processes that manipulate the inputs/outputs of a system e.g. sorting input, prioritizing it or filtering data. Processes which check the inputs/outputs or attach additional information to them cannot be classified as central transforms. Inputs and outputs are represented as boxes in the first level structure chart and central transforms as single boxes.

Moving on to the third step of transform analysis, sub-functions (formed from the breaking up of high-level functional components, a process called ‘factoring’) are added to the structure chart. The factoring process adds sub-functions that deal with error-handling and sub-functions that determine the start and end of a process.

Transform analysis is a set of design steps that allows a DFD with transform flow characteristics to be mapped into specific architectural style. These steps are as follows:

Step1: Review the fundamental system model

Step2: Review and refine DFD for the SW

Step3: Assess the DFD in order to decide the usage of transform or transaction flow.

Step4: Identify incoming and outgoing boundaries in order to establish the transform center.

Step5: Perform "first-level factoring".

Step6: Perform "second-level factoring".

Step7: Refine the first-iteration architecture using design heuristics for improved SW quality.

11.4 Transaction Mapping (Analysis)

Similar to ‘transform mapping’, transaction analysis makes use of DFDs diagrams to establish the various transactions involved and producing a structure chart as a result.

Transaction mapping Steps:

Review the fundamental system model

Review and refine DFD for the SW

Assess the DFD in order to decide the usage of transform or transaction flow.

Identify the transaction center and the flow characteristics along each action path

Find transaction center

Identify incoming path and isolate action paths

Evaluate each action path for transform vs. transaction characteristics

Map the DFD in a program structure agreeable to transaction processing

Carry out the ‘factoring’ process

Refine the first iteration program/ architecture using design heuristics for improved SW quality

In transaction mapping a single data item triggers one of a number of information flows that affect a function implied by the triggering data item. The data item implies a transaction.

11.5 Transform Vs Transaction Flow

Table 2 shows a comparison between transform flow and transaction flow.

Transform Flow

Transaction Flow

Incoming Flow

Incoming flow paths where incoming information is converted to internal representation.

Reception paths that converts external information into a transaction.

Center

Transform center where information is being processed.

A transaction center (dispatcher) where the transaction is evaluated and one of the emanating paths is activated.

Outgoing flow paths …..

Action paths ……….

Outgoing Flow

Overall flow of data occurs in sequential manner and follows one or more linear paths.

Overall flow of data forms a dispatch center pattern, where the incoming data flow (via the reception path) is directed to only one of the action paths by the transaction centre.

Table 2: A comparison between transform flow and transaction flow

Summary

In this lecture, the aim of structured design is distinguished, as well as discussing what a structure chart is, how it differs from a flow chart, and recognize the activities involved in transform analysis. We describe the mapping of data flow into software architecture in detail. Finally, we also present transform and transaction analysis in detail.

Exercises

Defined structured design.

List the basic steps in structured design.

What is meant by the term central transform?

What is meant by the term transaction analysis?

What is a system flow chart used for?

What symbols are used on a system flow chart?

What is the difference between afferent and efferent data flow?

Distinguish between Transform Flow and Transaction Flow.

Identify the aim of the structured analysis activity. Which documents are produced at the end of structured analysis activity?

Identify the necessity of constructing DFDs in the context of a good software design.

Write down some essential activities required to develop the DFD of a system more systematically.

The purpose of structured analysis is to capture the detailed structure of the system perceived by the user. (TRUE).

Structured analysis is a technique based on a bottom-up approach. (FALSE)

A DFD can also be known as a ‘bubble chart’. (TRUE)

The context diagram of a DFD is also known as ‘level 1 DFD’. (FALSE)

Decomposition of a bubble is also known as ‘factoring’. (TRUE)

Decomposition of a bubble should be carried on till the atomic program instructions are reached. (FALSE)