1. Function Point Measurement from Java Programs
Shinji Kusumoto+, Masahiro Imagawa+, Katsuro Inoue +
Shuuma Morimoto$, Kouji Matsusita$, Michio Tsuda$
+Osaka University
$Hitachi System & Service, Ltd.
Thank you chair. The title of my talk is ...
This is a collaboration research with Hitachi S&S.

2. Background(1/3)
Function point analysis(FPA) was proposed to help measure the functionality of the application software.
effort
(person-months) FP
2000
300
At first, I explain the background of our study.
Function point analysis was proposed to help measure the functionality of application software.
Up to now, various FPA methods have been
proposed and frequently used in software organizations.
I explain one typical example of the use. This graph shows the relationship between effort and function point value about each
software development. Here, in if we can get a numerical relation like this, and the estimated value of FP for next spoftware development,
becomes then, we can estimate the effort 300.

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.
However, several problems for FP are reported.
First one is ..
next one is.
We consider that one solution is automatic measurement of FP.

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.
Hitachi System &　Service. has been introducing function point to the software development projects for several years.
We have been studying the For example, we have developed .....
Through the study, we found that many company wan to measure ...
because, Because sometimes there are some
functional differences between requirements/design specification and
source code and the actual functions are existed only in source code.
Also, software company sometimes remain only source code.
* 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 (2001).

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
In this research, ...
At first,
Next
Finally.//

6. Function Point Analysis
FPA 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
USER
Input
Now I briefly explain function point analysis.
FPA is a technique that functions in the target application has classified into DF and TF. and then measures the functionality.
Data function types are Internal and external data requirements
Transactional Function types Represent the functionality provided to the user for the processing of data by an application. Intuitively speaking, they are Input, output, inquiry. In the FPA, main activity is to get Data Function and Transactional Function from specification.
Output
Internal
data
External
data
Inquiry
Application Software

7. Definition of Data Function types
Internal Logical File(ILF) :
user identifiable group of data.
maintained within the system.
External Interface File(EIF) :
not maintained by the system.
Each ILF or EIF has a functional complexity based on the number of data of it.
Here I explain about data function types.
Data function types are classified into Internal logical files and External interface files.

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.
And next I explain about transactional function types.
They are defined as the following three types: External input, External output and External inquiry.
あとはandでつなぎながら棒読み

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
Here, we explain the key idea of the proposed function point
measurement rules for object-oriented programs. It
deal with the function point measurement based on IFPUG, the main
process is extracting data functions and transactional functions from
the target program.
We consider that it’s difficult to judge the types of functions only from the
static information about source codes. So, 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. It is desirable that the testcases are used for acceptance
test by the user because functions not used by the user (for example,
functions used by only the developers for debug or maintenance
activities) are not tested and such functions should not be counted as
function point. Also, since the testcases used in the acceptance test
would be kept in the organization, this assumption is appropriate.

10. Key Idea (2/2) message classA classB classC classD
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.
Here, I briefly explain the dynamic information. THis figure shows An example of the dynamic information collected from program execution
there
are four classes\footnote{Actually, they are objects based on the
classes. ``Class'' in this paper is almost the same as ``object''. }
($A$, $B$, $C$ and $D$). 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 {\em method calling sequence}. By analyzing
the contents of the messages and the type of the classes in the method
calling sequence constructed by each testcase, we measure the function
point.

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.
We consider that some of the classes included in the target program
are data functions because, in IFPUG, data functions are defined as
the functionality provided to the user to meet internal and external
data requirements.
From our previous experience\cite{kusumoto}\cite{uemura}, most classes
(except actor classes) on the object-oriented requirements/design
specification directly corresponded to data functions. However, in
the actual program even if it was developed based on the design
specification, there are a lot of classes which are not appeared on
the specification. So, it is quite difficult to identify which classes
should be corresponded to data functions. Here, we assume that the
function point analyst select the classes that would be the data
functions from the program.
Then, the data functions are classified into two types: Internal
Logical File (ILF) and External Input File (EIF) as follows:
\begin{description}
\item ILF: Among the classes selected as data function, during the
program execution, the classes some of which methods are called with
some arguments are regarded as ILF. That is, we consider that the
arguments represents the data and the methods update the data which
the class obtains.
\item EIF: Among the classes selected as data function, other classes
that are not regarded as ILF, are regarded as EIF.
\end{description}

12. Counting Data Function Types(2/2)
Classify DF into two types:
ILF: During the program execution, the classes 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)
We consider that some of the classes included in the target program
are data functions because, in IFPUG, data functions are defined as
the functionality provided to the user to meet internal and external
data requirements.
From our previous experience\cite{kusumoto}\cite{uemura}, most classes
(except actor classes) on the object-oriented requirements/design
specification directly corresponded to data functions. However, in
the actual program even if it was developed based on the design
specification, there are a lot of classes which are not appeared on
the specification. So, it is quite difficult to identify which classes
should be corresponded to data functions. Here, we assume that the
function point analyst select the classes that would be the data
functions from the program.
Then, the data functions are classified into two types: Internal
Logical File (ILF) and External Input File (EIF) as follows:
\begin{description}
\item ILF: Among the classes selected as data function, during the
program execution, the classes some of which methods are called with
some arguments are regarded as ILF. That is, we consider that the
arguments represents the data and the methods update the data which
the class obtains.
\item EIF: Among the classes selected as data function, other classes
that are not regarded as ILF, are regarded as EIF.
\end{description}
Y.method (arguments)

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

14. Counting Transactional Function Types(2)
Step1:
Calculate the method calling sequences for all testcases.
Set application boundary (classes whose methods are inevitably called when the user input some data. ex. GUI classes or Java Servlet classes )
(Boundary class)
classA
classB
classC
classD
D.method
(DF)

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)

16. Counting Transactional Function Types(4)
Step3:
Identify the type of transactional functions:
External Input (EI) is the sequences that include the following pattern.
classA
(Boundary
class)
classB
classC (DF)
C.method(X)

17. Counting Transactional Function Types(5)
(2) External Output (EO) is the sequences that include the following pattern.
classA
(Boundary
class)
classB
(halfway class)
classC (DF)
C.method(0)
(3) External Inquiry (EQ) is the sequences not satisfying the above pattern.

18. FP measurement tool (1/2)
Syntax
Information
File
Java
Programs
Syntax
Analysis Unit
FP calculation
Unit
Execution
Unit (JVMPI)
Execution
Log File
Test
Case
Data Function
Class FP
results
Boundary
Class

19. Screen of FP measurement tool

20. Case study(1): Target application
Target application is a typical Web application that has been developed based on the object oriented approach.
Application server
Java Program
Java Servlet
Browserﾞ
Java
Servlet
Components
for
DB access
Database server
Ｏｒａｃｌｅ８ｉ
HTML
ＣＳＶ
ＪＤＢＣ
Web server
We compare the FP values by our tool with ones by a Function Point specialist of Hitachi System & Services, Ltd.

21. Case study (2) Result Tool Specialist Data function ILF 11 4 EIF 1 7
Transactional
function EI 9 6 EO 13 14 EQ
FP total
174
170

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 the 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.

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.

24. Example classX (Boundary class) classB classC(DF) classD (1) classY
(2)

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 .
In order to evaluate the usefulness of our technique, we applied the function point measurement tool to the following rec specifications: Purchase processing system, order processing system, and stock control system.
For these specifications, we compare the FP values by our tool with FP by a function point analysis specialist of a software organization.
The values by the tool are quite close to the values by the specialist