Unadjusted Transactional Functions

Overview

A detailed explanation of Unadjusted Transactional Functions.

Estimation Process for Transactions

The Unadjusted Transactional Functions metric metric for an application is computed as follows:

Identify the transactions entry points (user GUI elements or batch’s entry points),
Identify the tables used directly or indirectly by each entry point,
Compute FTR and DET for each entry point,
Compute Function Points for each entry point,
Compute Unadjusted Transactional Functions (the sum of all transaction Function Points).

Step 1 - Identify the transaction entry points

A set of “entry points” is automatically provided by CAST Imaging. In addition, custom entry points can be created using the UI (see Calibration below).

Step 2 - Identify the tables used directly or indirectly by each entry point (FTR)

For each Entry point, the FP estimation engine identifies (using an impact analysis and a search algorithm) all the tables used directly or indirectly by the entry point. It explores all the dependencies starting from the entry point down to the data functions. When the entry point is a composite object, container (such as classes), the FP estimation engine explores all the dependencies including those implemented inside sub-objects (such as methods).

For example, if the transaction entry point is class, the engine will explore all the dependencies including those implemented in the methods and fields of the class.

For COBOL programs only, the FP estimation engine identifies also the files and the IMS databases accessed by the entry point.

Step 3 - Compute FTR and DET for each entry point

For each Entry point, the following numbers are computed:

FTR = File Types Referenced

= Number of tables used directly or indirectly by the entry point + number of GSAM/VSAM files directly accessed by the entry point + Number of IMS Databases.

DET = Data Element Types

= Number of non-redundant columns for all tables used directly or indirectly by the entry point (redundant columns are columns with same names) + (3 * Number of COBOL files accessed).

Step 4 - Compute Function Points for each Entry point

For all the User Entry points, the Function Points metric are computed as follows. There are 3 types of Transactional Entities:

EI - External Inputs,
EO - External Outputs,
EQ - External Inquiries.

The enhanced mode will enable the differentiation between EI and EO/EQ (at this stage, it is not yet possible to differentiate EO from EQ). A Transaction is identified as an EI if the transaction contains at least one Insert, Update Delete link of a Table or at least one Write link on a file/IMS Database used. All other transactions will be identified as EO/EQ.

The EI number of Function Points is computed as follows:

	1 to 4 DET	5 to 15 DET	> 15 DET
0 or 1 FTR	Low = 3 FP	Low = 3 FP	Average = 4 FP
2 FTR	Low = 3 FP	Average = 4 FP	High = 6 FP
> 2 FTR	Average = 4 FP	High = 6 FP	High = 6 FP

The EO/EQ transaction type will be computed as follows:

	1 to 5 DET	6 to 19 DET	> 19 DET
0 or 1 FTR	Low = 4 FP	Low = 4 FP	Average = 5 FP
2-3 FTR	Low = 4 FP	Average = 5 FP	High = 7 FP
> 3 FTR	Average = 5 FP	High = 7 FP	High = 7 FP

When Insert/Update/Delete/Select information is not available, the default value is set to be the ones used for EI and EQ.

Step 5 - Compute Unadjusted Transactional Functions (the sum of all Forms Function Points)

Unadjusted Transactional Functions = Sum of (Function Points of all User Forms)

Example

As an example, this image shows a transactional function to illustrate how the CAST estimation algorithm counts function points for it. The PowerBuilder window called w_gui_newsale is listed as language built-in user form and the CAST estimation algorithm runs a search automatically to identify the tables, data files etc. used. Here in the example, the engine finds 2 file type referenced (FTR):

SALES
TITLES

The Salesdetail table has been found to be part of the SALES FTR.

Example - “w_gui_newsale” (EI)

In the following example, the result of the counting will be 7 FP:

FTR = 2 and DET = 16
Weight is high
Results = 6 Function Points

Assumptions

The OMG-compliant Automated Function Points standard requires the counter to qualify the “Primary Intent” of the elementary process. This Primary Intent helps distinguish the screen function to be an Input, Output or Inquiry (EI, EO, EQ). An algorithm cannot distinguish the “Primary Intent” of a transaction. This is the reason why CAST Function Points Estimation engine uses a default value for Transactional Functions Points in general. The default value is set to be ones used for EI and EQ. The Transactional Functions count assumes all columns of the accessed tables of files fields are used in the user forms and are user recognizable.

Calibration

To compute the Transactional Functions, it is necessary to identify the User Interface elements (windows, web pages or buttons used on theses windows and web pages) or batches entry points. While the concepts of User Interface elements are built-in for many languages, they are not built-in in languages such as C/C++, Java and COBOL and then depend on the library or frameworks used.

So if the application uses a specific library or framework, the user needs to configure the estimation algorithm in order to setup a rule to automatically select transaction entry points for the application to be measured. The automatic selection of the transaction entry points is done using the following type of rules:

Naming Convention rules, with the selection of an object type and a naming convention,
Inheritance rule (name of an Object, then all the objects that inherit directly or indirectly from that object will be selected as entry points).
A simple object.

Several of the configuration rules can be setup for a given application. These configurations are done using the Entry Points node. CAST provides a list of predefined Entry Points as shown below:

Built-in support for EAI Services and Web Services

CAST offers built-in support for EAI Services and Web Services. Indeed, enterprises are deploying more and more IT applications using web services and without a direct access to relational database. To enable easy counting of applications, CAST FP estimation algorithm provides the ability to define a set of functions/programs that are used either as:

Data functions and thus are associated to an average Function Points count,
Or that are used as Transaction end points (without any Function Points count).

Example: the application does not use a database but simply sends messages to another application. Then data entities can be automatically identified by CAST through configuration. This is done by configuration using inheritance, naming convention or a specific object type to identify services that are to be counted as data entity and as a transaction end point without FP weight.

Transaction Identification: Path Removal

As explained above, CAST FP estimation engine uses an impact and search algorithm that explores all the dependencies starting from the entry point down to the data functions. However, CAST field research has demonstrated that some specific applications have clusters of thousands of objects that are highly coupled. These clusters appear when there is a central component that handles in a way or the other all the transactions. Integrating these highly coupled clusters often leads to overweight the transactions and to have all transactions using all data functions. This is why the CAST FP estimation engine removes from the results the clusters of highly coupled objects and theses call paths are then removed.