Function Point Measurement from Java Programs

Shinji Kusumoto+, Masahiro Imagawa+, Katsuro Inoue +

Shuuma Morimoto$, Kouji Matsusita$, Michio Tsuda$

+Osaka University$Hitachi System & Service, Ltd.

Foil 2

Background(1/3)Function point analysis(FPA) was proposed

to help measure the functionality of the application software.

effort(person-months)

FP0 2000

300

Foil 3

Background(2/3)Issues:

• Since FP counting involves judgement on the part of the counter, some difference for the same product would be caused.

• In order to introduce FPA to an organization, it is necessary to count FP from the software developed in the past as experience data.

Foil 4

Background (3/3)• Automatic FP measurement from object-

oriented software.– FP measurement tool from UML

diagrams*

• Demand to measure function point from source code. – Functional differences between

requirements/design specification and source code.

– Existence of source code without specifications.

* T. Uemura, S. Kusumoto and K. Inoue: ``Function point analysis for design specifications based on the Unified Modeling Language'', Journal of Software Maintenance and Evolution, Vol. 13, No. 4, pp.223-243 (2001).

Foil 5

Objective of the reserach

• We examine the possibility to measure function point from source code automatically.

– Propose measurement rules to count data and transactional functions from object oriented program based on IFPUG method.

– Develop the function point measurement tool based on the rules.

– Apply the tool to practical Java programs in Hitachi Systems & Services

Foil 6

Function Point AnalysisFPA is a technique that functions are classified

into the following element, and then measures the functionality.– Data function

• Internal and external data requirements– Transactional function

• Represent the functionality provided to the user for the processing of data by an application

Internaldata

Externaldata

Application Software

Input

Inquiry

Output

USER

Foil 7

Definition of Data Function types• Internal Logical File(ILF) :

– user identifiable group of data.– maintained within the system.

• External Interface File(EIF) :– user identifiable group of data.– not maintained by the system.

• Each ILF or EIF has a functional complexity based on the number of data of it.

Foil 8

Definition of Transactional Function types

• External input(EI):– processes data that come from outside the

software.• External output(EO):

– generates data sent outside the software.• External inquiry(EQ):

– is a process made up of an input-output combination that results in data retrieval.

• Each EI, EO or EQ also has a functional complexity based on the number of data processed.

Foil 9

Key Idea (1/2)

• It is difficult to judge the types of functions only from the static information of source codes.

• We use the dynamic information collected from the program execution based on a set of testcases which should correspond to all functions of the target program. – Testcases for acceptance test

Foil 10

Key Idea (2/2)

• It shows an interaction, which is a set of messages exchanged among the classes, like a sequence diagram. We call this kind of sequence as method calling sequence.

• We measure FP by analyzing the messages and the information of the classes in the sequence constructed by each testcase.

classA classB classC classDmessage

Foil 11

Counting Data Function Types(1/2)

• From our previous experience most classes on the object-oriented requirements/design specification directly corresponded to data functions.

• We assume that the function point analyst select the classes that would be the data functions from the program.

Foil 12

Counting Data Function Types(2/2)

• Classify DF into two types: – ILF: During the program execution, the class

es some of which methods are called with some arguments are regarded as ILF.

– EIF: Other classes that are not regarded as ILF, are regarded as EIF.

classX classY(DF)

Y.method (arguments)

Foil 13

Counting Transactional Function Types(1)

• Regarding the classes as data functions, the method that updates or refers to the data in the class can be used to extract the transactional function.

• Basic element in the method calling sequence– Sub-method calling sequence where a

method, that is defined in a data function class, is called by other class.

classA classB(DF)

B.method

classA(DF) classB(DF)

B.method

Foil 14

Counting Transactional Function Types(2)

• Step1: – Calculate the method calling sequences for al

l testcases.– Set application boundary (classes whose met

hods are inevitably called when the user input some data. ex. GUI classes or Java Servlet classes )

classA classB classC classD

D.method

(DF)(Boundary class)

Foil 15

Counting Transactional Function Types(3)

Step2: – Extract the method calling sequences

where the basic element is appeared.

classA classB classC classD

D.method

(DF)

Foil 16

Counting Transactional Function Types(4)

Step3: Identify the type of transactional functions:

(1)External Input (EI) is the sequences that include the following pattern.

classA(Boundaryclass)

classB classC (DF)

C.method(X)

Foil 17

Counting Transactional Function Types(5)

(2) External Output (EO) is the sequences that include the following pattern.

classA(Boundaryclass)

classB(halfway class) classC (DF)

C.method(0)

(3) External Inquiry (EQ) is the sequences not satisfying the above pattern.

Foil 18

FP measurement tool (1/2)

Syntax Analysis Unit

Execution Unit (JVMPI)

FP calculationUnit

SyntaxInformation

File

JavaPrograms

Execution Log File

TestCase

FPresults

Data FunctionClass

BoundaryClass

Foil 19

Screen of FP measurement tool

Foil 20

Case study(1): Target application

Application serverJava Program

Java ServletBrowser ﾞ

Java Servlet

Components for

DB access

Database server

Ｏｒａｃｌｅ８ｉ

HTMLHTMLＣＳＶ

ＪＤＢＣ

HTMLHTMLHTML

Web server

Target application is a typical Web application that has been developed based on the object oriented approach.

We compare the FP values by our tool with ones by a Function Point specialist of Hitachi System & Services, Ltd.

Foil 21

Case study (2) Result

170174FP total

00EQ

1413EO

69EITransactional

function

71EIF

411ILFData function

SpecialistTool

Foil 22

Case study (3) Analysis of DF

• By selecting the classes, that conceal the access to database, as data functions, the number of data functions are quite similar.

• The classification result of data function types are different between the tool and the specialist. – The result is due to the fact that most methods in t

he data function class have arguments.

• It is necessary to revise the classification rule. For example, if the argument of the method in a class indicates the meaningful data, the class is regarded as ILF.

Foil 23

Case study (4) Analysis of TF

• Both the number of transactional functions by the tool and the specialist are quite similar. – Each of the transactional functions

counted by the specialist was also counted by the tool.

• The tool counted two transactional functions excessively.

Foil 24

Example

classX(Boundary class) classB classC(DF) classD

classY(Boundary class) classB classC(DF) classD

(1)

(2)

Foil 25

Conclusions

• We have examined the possibility to measure function point from source code automatically.– Proposed measurement rules. – Developed the FP measurement tool.– Applied the tool to practical Java

programs.

• It is necessary to – apply the proposed tool to other

programs which include EQ.– revise the rule of the classification of

each function .