Function Point Measurement from Java Programs

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.

2
Background(1/3)

• Function point analysis(FPA) was proposed to help
  measure the functionality of the application
  software.

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.

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

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
Output
External data
Internal 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)
• 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.

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.

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

10
Key Idea (2/2)
message

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

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.

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.

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.

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)
15
Counting Transactional Function Types(3)

• Step2
• Extract the method calling sequences where the
  basic element is appeared.

16
Counting Transactional Function Types(4)

• Step3
• Identify the type of transactional functions
• External Input (EI) is the sequences that include
  the following pattern.

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 Log File
Execution Unit (JVMPI)
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.

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
Specialist
Tool
Data function
4
11
ILF
7
1
EIF
Transactional function
6
9
EI
14
13
EO
0
0
EQ
170
174
FP total
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
(1)
(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 .