Function Point Measurement Tool for UML Design Specification

Takuya UEMURAy, Shinji KUSUMOTOy, and Katsuro INOUEy , z

y
Graduate School of Engineering Science, Osaka University,
1-3, Machikaneyama, Toyonaka, Osaka 560-8531, Japan
Tel: +81-6-6850-6571, Fax: +81-6-6850-6574
E-mail: fuemura, kusumoto, [email protected]
z
Graduate School of Information Science, Nara Institute of Science and Technology

Abstract on the programming language.

Function point is a measure of software size that uses
Function point analysis(FPA) was proposed to help mea- logical functional terms business owners and users more
sure the size of a computerized business information system. readily understand [1]. Since it measures the software re-
It is widely used in the actual software development. How- quirements or business models, the measured size stays con-
ever, it has been reported that since function point counting stant despite the programming language, design technology,
involves judgment on the part of the counter, some differ- or development skills involved. Also, it is available early
ence for the same product would be caused even in the same in the development process, making its use opportune for
organization. In this paper, we propose detailed FPA mea- planning the design and development projects. Up to the
surement rules for the design specifications based on the present, various FPA versions based on the Albrecht’s ver-
UML(Unified Modeling Language) and develop the func- sion have been proposed. IFPUG (International Function
tion point measurement tool, whose input products are de- Point Users Group) version [2] and MarkII version [13] are
sign specifications on Rational Rose. We have also applied frequently used in software organizations.
the tool to the actual design specification and examine the However, it has been reported that since function point
difference between the values by the tool and one by the counting involves judgment on the part of the counter, some
specialist of FPA. The results show the applicability of our difference for the same product would be caused even in the
tool. same organization [6]. For example, G. Low and R. Jeffery
reported that a 30-percent variance was caused within an
organization and more than 30-percent variance was caused
across organizations[8]. In order to get consistent value, it
1. Introduction is important to automate the function point measurement[1].
In the past, function point measurement could not be com-
As the size and the complexity of software increase, it pletely automated because there were no machine readable
becomes important to develop high-quality software cost- requirements/design specifications. Recently, CASE tools
effectively within a specified period. In order to attain it, have been providing machine readable ones. Now, it is easy
it is necessary to manage the entire software development to introduce the function point measurement tools for the
processes based on the effective project plan. requirements/design specifications produced by the specific
In order to construct the distinct project plan, it is essen- CASE tool.
tial to estimate various phenomena happened in the project On the other hand, recently, many companies have
and take measures to meet them in advance. A subject of es- started to introduce object-oriented technology into their
timation about software development is size, effort invested, software development environments and the object-oriented
development time, technology used and quality. Especially development technologies are often used in software orga-
development effort is the most important subject. nizations. However, it has created new challenges for com-
There have been proposed a lot of effort models and most panies and researchers which use software metrics as a tool
of them include software size as an important parameter. In for managing the software and the process [4]. That is, it is
the models, LOC (lines of codes) is often adopted. How- necessary to establish the method to calculate the software
ever, using LOC as the software size has difficulties because metrics from the object-oriented software.
the definition of LOC is very vagueness and LOC depends This paper proposes detailed FPA measurement rules for
the design specifications using the UML (Unified Model- In the IFPUG version, the counting procedure of func-
ing Language) and develop the function point measurement tion point consists of the following seven steps[2].
tool. With respect to the development using the UML, sev-
eral CASE tools have been developed. Among them, Ratio- Step1 (Determine the Type of Function Point Count): Se-
nal Rose by Rational Software is the most prevalent one and lect the type of function point from the following
widely used in software development organizations. Thus, three ones:(1) Development project function point
as the input of the tool, we address the design specifications count, (2)Enhancement project function point count
on Rational Rose. Finally, We apply the tool to the actual and (3)Application function point count.
design specification and examine the difference between the Step2 (Identify the Counting Boundary): A boundary indi-
value by the system and one by the specialist of FPA. Then, cates the border between the application or project be-
we examine the difference between them and discuss the ing measured and the external applications or the user
applicability of our tool. domain. A boundary establishes which functions are
Section 2 describes the overview of function point anal- included in the function point count.
ysis, the IFPUG version and the several diagrams by the
UML. Next, Section 3 proposes detailed rules to count the Step3 (Count Data Function Types): Data function types
function point from the diagrams by UML. Section 4 de- represent the functionality provided to the user to meet
scribes a function point measurement system based on the internal and external data requirements. Data function
proposed rules and case study that evaluates the applicabil- types are classified into the following two types: Inter-
ity of our system. Finally, Section 5 concludes this paper. nal logical file(ILF) and External interface file(EIF).
The definition of data functions are described as fol-
2. Preliminaries lows:
Internal Logical File(ILF): (1)The group of data is
2.1. Function Point Analysis user identifiable group of data. (2)The group of
data is maintained within the application bound-
Function point measures the functionality provided by ary. (3)The group of data identified has not been
software. It can be determined from the requirements spec- counted as an EIF for the application.
ification, design specification and program code. Unlike External Interface File(EIF): (1)The group of data is
LOC, since function point measures functionality, it should user identifiable group of data. (2)The group of
be independent of the technology and language used for the data is not maintained by the application being
software implementation. counted. (3)The group of data identified has not
Allan Albrecht first proposed original function point been counted as an ILF for the application.
analysis [1]. Albrecht’s function point is computed by
counting the following software characteristics:(1)External Here, the term “file” refers to a logically related group
inputs and outputs, (2)User interactions, (3)External inter- of data and not to the physical implementation of those
faces and (4)Files used by the system. Each of them is then group of data.
individually assessed for complexity and given a weighting Then, assign each identified ILF or EIF a functional
value which varies from 3 (simple) to 15 (complex). complexity based on the number of data element types
Albrecht’s function point has been widely used but it has (DETs) and record element types (RETs) associated
some weakness. Thus, many kinds of function point, such with the ILF or EIF using the RET/DET complexity
as IFPUG version[2], 3D Function Points version[5], Fea- matrix(See Table 1). A data element type (DET) is
ture Points version[5] and MarkII version[13], have been a unique user recognizable, nonrecursive field on the
proposed. In this paper, we address the IFPUG version since ILF or EIF. A record element type(RET) is a user rec-
it provides the detail procedures and rules for function point ognizable subgroup of data elements within an ILF or
counting compared to other versions. EIF.

2.2. IFPUG version Table 1. RET/DET complexity matrix

RETnDET 1-19 20-50 51-
IFPUG version is a modified-version of the Albrecht’s 1 Low Low Average
function point. In the modification, the evaluation of the 2-5 Low Average High
complexity of the software was objectively established and 6- Average High High
the rules of the counting procedures were also described
minutely and precisely.
Step4 (Count Transactional Function Types):
Table 3. General System Characteristics
Transactional function types represent the functional- Article GSC
ity provided to the user for the processing of data by 1 Data communications
an application. They are defined as the following three 2 Distributed data processing
types: External input(EI), External output(EO) and 3 Performance
External inquiry(EQ). The definition of transactional 4 Heavily used configuration
functions are described as follows:
5 Transaction rate
External input(EI): An external input processes data 6 Online data entry
or control information that comes from outside 7 End-user efficiency
the application’s boundary. The external input it- 8 Online update
self is an elementary process. 9 Complex processing
External output(EO): An external output is an ele- 10 Reusability
mentary process that generates data or control in- 11 Installation ease
formation sent outside the application’s bound- 12 Operational ease
ary. 13 Multiple sites
14 Facilitate change
External inquiry(EQ): An external inquiry is an el-
ementary process made up of an input-output
combination that results in data retrieval. The
output side contains no derived data. Here, de- Table 4. Unadjusted Function Point Calcula-
rived data is data that requires processing other tion Table
than direct retrieval and editing of information
from internal logical files and/or external inter- Complexity
face files. No internal logical file is maintained Low Average High Total
during processing. ILF 2  7= 2 2 10= 2 2 15= 2
Then, assign each identified EI or EO a functional EIF 2  5= 2 2  7= 2 2 10= 2
complexity based on the number of file types refer- EI 2  3= 2 2  4= 2 2  6= 2
enced (FTRs) and data element types (DETs).A file EO 2  4= 2 2  5= 2 2  7= 2
type referenced is ,(1) An internal logical file read or EQ 2  3= 2 2  4= 2 2  6= 2
maintained by a function type, or (2) An external in- Unadjusted Function Point
terface file read by a function type. Also, assign each
EQ a functional complexity based on the number of and then weighted using the Table 4. The total of
file types referenced (FTRs) and data element types all the function types is the unadjusted function point
(DETs) for each input and output component. Use the count.
higher of the two functional complexities for either the
input or output side of the inquiry to translate the exter- Step6 (Determine the Value Adjustment Factor):
nal inquiry to unadjusted function points. For each of The value adjustment factor (VAF) indicates the gen-
EI, EO and EQ, there is a FTR/DET complexity ma- eral functionality provided to the user of the applica-
trix. Table 2 shows the FTR/DET complexity matrix tion. VAF is comprised of 14 general system character-
for EI. istics that assess the general functionality of the appli-
cation. Each characteristic has associated descriptions
that help determine the degree of influence of the char-
Table 2. FTR/DET complexity matrix of EI
FTRnDET
acteristic. The degree of influence ranges on a scale
1-4 4-15 16-
of 0 to 5, from no influence to strong influence. (See
0-1 Low Low Average
Table 3.)
2 Low Average High
3- Average High High Finally, VAF is calculated based on the following for-
mula, VAF = 0:65 + total
100 :
Step7 (Calculate the Final Adjusted Function Point
Step5 (Determine the Unadjusted Function Point Count): Count):
As the result of Step3 and Step4, the counts for each The final adjusted function point count is calculated
function type are classified according to complexity using a specific formula for development project, en-
 hancement project or application based on the result of
Step1.
IFPUG version has been widely used in software organi-
zations and also will be included into the ISO standard.

2.3. Unified Modeling Language

The Unified Modeling Language (called UML) [14]

was developed to provide a common language for object-
oriented modeling. It was designed to be extensible in or-
der to satisfy a wide variety of needs and was also intended
to be independent of particular programming language and
development methods.
The concrete syntax of the UML is dominated by a
graphical notation. The UML defines a large number of dif-
ferent diagrams. They are divided into following three cat- Figure 1. Example of the Class diagram
egories: Static structure diagrams, Behavior diagrams and
Implementation diagrams. not show the associations among the objects. Sequence dia-
Static structure diagrams describe the structure of the grams show the explicit sequence of messages and are better
system and include class diagrams and object diagrams. Be- for real-time specifications and for complex scenarios.
havior diagrams describe the behavior/dynamic perspective The sequence diagram represents an interaction, which
of the system and include use-case diagrams, interaction di- is a set of messages exchanged among objects within a col-
agrams, sequence diagrams, collaboration diagrams, state laboration to effect a desired operation or result.
diagrams and activity diagrams. Implementation diagrams The sequence diagram has two dimensions: the vertical
provide the information of actual source code and includes dimension which represents time and the horizontal dimen-
component diagrams and deployment diagrams. sion which represents different objects. Normally time pro-
In order to calculate the function point from the above di- ceeds down the page. There is no significance to the hori-
agrams, we use the sequence diagrams and class diagrams. zontal ordering of the objects. Objects can be grouped into
Because these diagrams include the information about all “swimlanes” on a diagram.
functions and data manipulated in the system. In subsec- Figure 2 shows an example of a sequence diagram of the
tions 2.4 and 2.5, we briefly explain the class diagrams[10] office system in a University. In Figure 2, there are nine
and sequence diagrams[10]. messages and the set of these messages correspond to the
following processing: (1)a student hands his/her registra-
2.4. Class diagrams tion sheet of the lectures, that he/she wants to attend, to the
receptionist in the office of the University, (2)the reception-
Class diagrams describe the static structure of the model, ist inputs the data to the database through the Registration
that is objects, classes and the relations between these en- system and (3)the student receives the result of the registra-
tities including generalization and aggregation. They also tion.
represent the attributes and operations of the classes.
For example, Figure 1 shows the class diagrams for Per- 3. Proposed Rules for Function Point
son, Student and Teacher that are used in the office system
in a University. In Figure 1, the class Person has two at- 3.1. Overview
tributes (Name and Address) and four operations (SetName,
SetAddress, GetName and GetAddress). Other classes, Stu- We aim to calculate the Unadjusted Function Point. We
dent and Teacher, inherit the information in the parent class propose the following five steps to apply IFPUG version to
Person. the requirements/design specifications (class diagrams and
sequence diagrams) based on the UML.
2.5. Sequence diagrams
Step1 (Determine the Type of Function Point Count):
A sequence diagram shows an interaction arranged in We handle only the development project function
time sequence. In particular, it shows the objects partici- point.
pating in the interaction by their “lifelines” and the mes-
sages that they exchange arranged in time sequence. It does Step2 (Identify the Counting Boundary):
 exchanging the data are regarded as ILF. Others are re-
garded as EIF.

Step3: Judge complexity of data function

Complexity of ILF and EIF is determined by the data
element type(DET) and the record element type(RET).
Since the DET is a unique user recognizable, nonrecur-
sive field on the ILF or ELF, we count the number of
attributes of the corresponding class. If the class is de-
rived from other class, the number of attributes of the
base class is also added.
On the other hand, the RET cannot be counted from
the class and sequence diagrams. However, from our
Figure 2. Example of the Sequence diagram previous experience, the RET is almost one in require-
ments/design specification. So, we consider that the
The counting boundary is determined by the type of RET is one.
objects which appear in the sequence diagrams. That
is, actor objects are outside the boundary and other ob- Finally, the functional complexity is rated based on
the RET/DET complexity matrix (See Table 1).
jects are inside the boundary.
Step3 (Count Data Function Types): 3.3. Rule of counting transactional function types
Data function types are automatically decided based
on the information of the class and sequence diagrams In accordance with IFPUG rules, we regard each of the
according to the rules explained in subsection 3.2. messages, which is exchanged by the object specified as
data function in sequence diagrams, as the candidate of
Step4 (Count Transactional Function Types): transactional function. Then, if a message has no argu-
Transactional function types are automatically decided ments, it means that it doesn’t exchange data and so we
based on the information of the class and sequence di- determine that it is not a transactional function.
agrams according to the rules explained in subsection At first, in order to count the transactional function from
3.3. the class and sequence diagrams, we assume the following
restrictions:
Step5 (Determine the Unadjusted Function Point Count):
As the result of Step3 and Step4, the counts for each  Assume that the sender object sends a message to other
function type are automatically classified according to object (receiver object) in the sequence diagram. If
complexity and then weighted. The total for all func- the receiver object returns meaningful message to the
tion types is the unadjusted function point count. sender one, the reply message must be precisely de-
scribed in the sequence diagram (According to the def-
3.2. Rule of counting data function types inition of the sequence diagrams of the UML, it is not
necessary to describe it).


Based on the definitions of data function, we propose
following rules to extract the data functions from class and Data exchange must be written as the arguments of the
sequence diagrams. Here, we classify the objects into actor messages in the sequence diagram.
and non-actor object. Since actor objects exist outside of
the application, they are not regarded as the data function.
 When an argument of the message whose name is the
same as the sender object’s attribute, we recognize the
Step1: Select candidates of data functions: data stored in the argument is simply sent from the
sender object.
We select the objects, that have some attributes and
exchange data with not-actor objects, as the candidates  If a message is repeatedly appeared in the sequence
of data functions. diagrams, the arguments and message names must be
Step2: Determine function type: the same.

For each of the candidates selected in Step1, we de- For each actor object in the sequence diagrams, we apply
termine the function type. Objects that have opera- the following two steps to count the transactional function
tions which change the attributes of other objects in types. These steps are based on the fact that function types
 Figure 3. Pattern 1

Figure 5. Pattern 3

Figure 4. Pattern 2

of the transactional function can be determined by renewal

or reference of data functions or comparison of data ele-
ments outputted.

Step1: Select candidates of transactional function: List the Figure 6. Pattern 4

sequence of messages that the first message is sent by
the actor object and the last message is received by the In Figure 5, pay attention to a “message2”, if
actor object or non-actor object in the sequence dia- all the arguments of the “message2” is the same
gram. as the attributes of the DF, we regard two mes-
sages (message1 and message2) as one External
Step2: Determine the type of transactional function: For
Inquiry. Otherwise, it means that the “message2”
each sequence listed in Step1, using the following five
contains elementary process, we regard two mes-
patterns, we determine the type of the transactional
sages as one External Output. In other words, we
function and the complexity (DET and FTR) of them.
consider that the “message1” from the actor is the
Pattern 1: An actor object sends message to a input of the key for data retrieval.
DF(Data Function) (See Figure 3) DET is the number of arguments of outputted
We regard this pattern as External Input. If no ar- message (message2). FTR is 1 since there is one
guments are given on the message, we don’t re- DF.
gard it as EI. DET is the number of arguments of Pattern 4: An actor object sends message to a DF
the message. FTR is 1 since there is one DF. and the DF sends message to another actor ob-
Pattern 2: A DF sends message to an actor object (See ject (See Figure 6)
Figure 4) We divide it into two transactional functions.
If all the arguments of the message are the same That is, Pattern 4 is the combination of the Pat-
as the attribute of the DF, we regard it as Exter- tern 1 and the Pattern 2.
nal Inquiry. Otherwise, it means that the message Pattern 5: An actor object sends message to a DF and
contains derived data. Then, we regard it as Ex- finally the actor object receives the reply message
ternal Output. DET is the number of arguments through several DFs (See Figure7)
of the message. FTR is 1 since there is one DF. Pattern 5 handles a sequence of messages. That
Pattern 3: An actor object sends message to a DF, is the case that when an actor object sends a mes-
and returns message from the DF to the actor ob- sage, the reply message comes through several
ject(See Figure 5) DFs. For example, in Figure 7, a sequence of
 Analysis unit
Design Analysis DB
specification

Counting unit
Counting DB

Result
List of Interface unit
function
type

Figure 8. Outline of the system

4.2. Case study

We applied the function measurement tool to the actual

Figure 7. Example of Pattern 5 design specifications for typical business application system
developed by the Rational Rose as follows:
five messages (message1,2,3,5,6) is a candidate
of transactional function. Then, we apply Pat- Purchase processing system: It makes out several docu-
tern3 to message1 and message6. In Figure 7, ments to purchase office equipments.
since message4 is not included in the sequence,
Order processing system: It manages to make up an esti-
we apply other pattern (in this case, Pattern2)
mate for the office equipments and decide the shop to
separately to the message.
which they are ordered.
DET is the number of arguments of outputted
message (message6). FTR is 2 since there are Stock Control system: It controls the stock of the office
two DFs in the sequence. equipments and makes the production plans.
Figure 9 shows the part of the design specification for
4. Function Point Measurement Tool and its the Purchase processing system.
application We calculated the function points from the specifications
by our tool. Also, a function point analysis specialist (not
4.1. Outline of system an author of this paper) of a software organization calculates
the function points manually from the same specifications.
We have designed and implemented the tool that can The measurement results are shown in Table 5.
compute function points of the design specification devel- With respect to the data function, the values measured by
oped by Rational Rose version 4.0 using Visual C++ lan- the tool are quite similar to the ones by the specialist. There
guage on Windows98. The inputs for the tool are sequence are no differences among them.
diagrams and class diagrams of the Rational Rose and the On the other hand, with respect to the transactional func-
output includes the values of function points, transactional tion, there are some differences among them. These dif-
functions, data functions and objects which may be related ferences are caused by that in the several sequence dia-
to the function points calculation. grams, there is only one External inquiry, but the special-
The system structure is shown in Figure 8. The system ist considered that this transactional function would consist
consists mainly of three units and two database: Analysis of two transactional functions and counted two External in-
unit, Analysis database, Counting unit, Counting database quiries. If the detailed descriptions existed in the sequence
and Interface unit. diagrams, our tool could counted the transactional functions
Analysis unit executes syntax analysis to the input files correctly.
(that is, sequence diagrams and class diagrams of the Ra- Thus, we can conclude that our proposed rules and mea-
tional Rose), extracts data functions and stores them into surement system are considerably useful for the practical
the Analysis database. Counting unit calculates the value software development.
of function points using the data in the Analysis database
and stores them into the Counting database. Interface unit 5. Conclusions
shows the measurement results, that includes the value of
function point, candidates for the data functions and trans- In this paper, we have proposed detailed function point
actional functions. analysis rules for design specification developed based on
 Table 5. The measurement results
Function point analysis specialist Our tool
Purchase Order Stock Control Purchase Order Stock Control
Data Function 14 29 26 14 29 26
Transactional Function 18 63 36 16 50 33
Total 32 92 60 30 79 59

Kenji Hatsuta, Ms. Mari Morita and Mr. Makoto Kurashige

of Hitachi, Ltd. for their discussions and advises in this pa-
per.

References

[1] A. J. Albrecht. Function point analysis. Encyclopedia of

Software Engineering, 1:John Wiley & Sons, 1994.
[2] A. J. Albrecht. Function Point Counting Practices Man-
ual, Release 4.0. International Function Points Users Group,
1994.
Figure 9. A part of the design specification [3] A. J. Albrecht and J. E. Gaffney. Software function, source
lines of code, and development effort prediction: A software
the UML. Then, based on the proposed rules, we have de- science validation. IEEE Transactions on Software Engi-
veloped the function point measurement tool. We have also neering, 9(6):639–648, 1983.
[4] V. R. Basili, L. C. Briand, and W. L. Melo. A valida-
applied several design specifications for typical business ap-
tion of object-oriented design metrics as quality indicators.
plication. The values calculated by the tool are considerably
IEEE Transactions on Software Engineering, 20(22):751–
adequate. 761, 1996.
Class and sequence diagrams may be available only con- [5] C. Jones. Applied Software Measurement. McGraw-Hill,
siderably later during the development process than the time 1996.
when function points are usually applied. However, since [6] B. A. Kitchenham. The problem with function points. IEEE
these diagrams can be easily constructed from use-case and Transactions on Software Engineering, 14(2):29–31, 1997.
if we have enough experience data about class and sequence [7] L. Lian, S. Kusumoto, T. Kikuno, K. Matsumoto, and
diagrams, our system could be useful in the actual software K. Torii. A new fault localizing method for program de-
development. bugging process. Information and Software Technology,
39:271–284, 1997.
Future research works include the following:
[8] G. C. Low and D. R. Jeffery. Function points in the estima-
1. The target products of our tool are UML Version 1.1, tion and evaluation of the software process. IEEE Transac-
tions on Software Engineering, 16(1):64–71, 1990.
IFPUG Version 4.0, and Rational Rose Version 4.0.
[9] T. Quatrani. Visual Modeling with Rational Rose and UML.
Now, UML Version 1.3, IFPUG Version 4.1 and Ra- Addison Wesley Longman, 1998.
tional Rose 98 have just been released. We are going [10] Rational. UML 1.1 Notation Guide. Rational Software,
to modify our tool to cope with the new products. 1997.
[11] M. Saito, N. Onari, K. Yuura, and T. Kameda. Visualiz-
2. In order to show the validity of our technique, we will ing tool for required specifications. The Hitachi Hyoron,
apply our tool to many software development projects 77(12):15–18, 1995.
in actual software organizations. [12] I. Sommerville. Software Engineering. Addison-Wesley,
1995.
3. Our proposed rules are based on only class and se- [13] C. Symons. Software Sizing and Estimating. John Wiley &
quence diagrams. We must examine whether other Sons, 1991.
diagrams can be applicable to measure function point [14] S. Zamir. Handbook of Object Technology. CRC Press,
more precisely. 1999.

Acknowledgments

We would like to thank Mr. Takashi Kasimoto, Mr. Mi-

chio Tsuda, Mr. Katuhiko Yuura, Ms. Ayane Suzuki, Mr.