Fast&&Serious: a UML based metric for effort estimation

Fast&&Serious: a UML based metric for effort estimation
Massimo Carbone and Giuseppe Santucci
Dipartimento di Informatica e Sistemistica "Antonio Ruberti"
Universita' degli studi di Roma "La Sapienza"
Via Salaria 113, 00198-Rome, Italy
santucci@dis.uniroma1.it
Abstract
In this paper we present a new method to estimate the size of a software project developed
following the object-oriented paradigm.
The method is designed to work with a set of UML diagrams describing the most important system
features. We calculate the complexity of a system in terms of source lines of code. Outstanding
features of our method are its flexibility (allowing estimation of projects described with few
diagrams) and the capability to completely automate the entire counting process extracting
information about UML diagrams from Rational Rose 98 or 2000 petal files.
Keyword: Object Oriented, size estimation, UML, Rational Rose
1. Introduction
Recently, many companies have started to introduce object-oriented (OO) technologies into their
software development process.
Consequently, many researchers have proposed several metrics suitable for measuring the size and
the complexity of OO software, assessing old or introducing new metrics that capture exclusive
concepts of the OO paradigm, such as inheritance, cohesion, and coupling. Traditional metrics such
as Function Point (FP) are unsatisfactory for predicting software size, because of they are based on
the procedural paradigm that separates data and functions while the OO paradigm combines them.
OO metrics should catch the three canonical dimensions of OO software: functionality (behaviour
of objects), amount of communication among objects, and percentage of reuse through inheritance.
Our proposal, Fast&&Serious, combines several measures extracted by UML diagrams associating
each class with a size estimation, in terms of source lines of code (SLOC).
Fast&&Serious automatically extracts data about the project under analysis from a case tool by
Rational Software: Rational Rose 2000. This tool is one of the most prevalent and widely spread
case tool used in software development organizations for design specification using UML (Unified
Modeling Language). After data about a project has been extracted by UML diagrams, we apply a
measurement process that computes for each class a size estimation.
1

According to the design level of detail, the process applies the Fast method or the Serious method.
Fast method is useful during the early phases of the project, in which we want just a rough size
estimation, because the entire project is not well defined.
Otherwise, we use the Serious method that applies a more complex computation method to the
extracted data and accomplishes the goal of estimating in a better way the size when we have more
significant information about the system.
Our method produces an estimation of the software complexity terms of SLOC; for comparison
purpose we convert it in terms of traditional FP using a backfire index. Figure 1 shows two different
ways to obtain the number of FP associated with a project; a standard way is to follow the IFPUG
guide lines [11]; an alternative way is to use our completely automated method.
Client
Login
Catalog
User
Sequence
Diagram
Administ rator
Rational Rose
2000 (*.m dl)
Modify Request
DBMS
Use Case
Dagram
: Profess or
: Client
: D BM S
login
insert
retrieve data
Result
Automated
Analysis
state 1
state 1
Start
Start
state 4
state 4
Person
Student
University
Administrator works in
(from Use Case View)
Class
Department
Diagram
Start
Analisys
Requirements
state 2
state 2
[ guard condition ] / action ^event
[ state guard 3condition
] / action ^event Finish
state 3
Finish
state 5 Stat e
state 5 State
Diagram
Diagram
Extract
Data
Standard
Analysis
Fast
&&
SLOC Backfire
&&
Index
Serious
C
Estimate FP O Effort
O
C
O
Function Effective FP M
Duration
Point
O
Analysis
II II
(IFPUG)
Figure 1: two alternative ways to measure effort and duration
The paper is structured in the following way: Section 2 describes related proposals and evidences
our main contributions, Section 3 describes the Fast&&Serious method, Section 4 presents a case
study. Some conclusions are drawn in Section 5.
2. Related work
Several proposals are available in the literature to estimate effort and duration of OO projects.
A first group of them are extension of the FP method: Fetcke [1], Caldeira [2], Uemura [3] define a
set of rules for mapping OO concepts into classical FP concepts. They map classes into logical files
and methods or messages exchanged among objects into transactions. Whitmire [6] proposes a 3D
Function Point, an extension of FP that measures data, control, and functionalities of a software
project. 3D FP is a good metric to estimate productivity but less valuable for effort prediction.
Specific OO concepts, such as inheritance and polymorphism are treated in a particular way.
2

A second class of proposals do not follow the Function Point Analysis and define new complexity
metrics: Minkiewicz [4] proposes a Predictive Object Point (POP) that computes a class complexity
weighing its methods and using adjustment factors depending on the topology of the class diagram
under analysis. Methods are weighted considering their type (i.e., constructor, destructor, modifier,
selector, iterator) and complexity (low, average, high), giving a number of POPs in a similar way to
traditional FP. Sneed [7] proposes Object Point as a measure of cost for OO system, different from
FP. He treats Class Points (CP), Message Points (MP), and Process Point (PP) as a measure of the
cost involved in class development, class integration and developer tests, and system test,
respectively. Object Points are the sum of CP, MP, and PP. Finally, he adjusts this value including
influencing and quality factors. Hastings [10] proposes the Vector Size Measure (VSM) and Vector
Prediction Model (VPM) approach to software size measurement and effort estimation based on
algebraic specification. VSM incorporates both functionality and problem complexity in a balanced
and orthogonal manner. VPM receives VSM as input and produces an early estimation of the
development effort.
Other proposals, more close to our approach, exploit information coming from UML diagrams
assessing the estimated figures using subjective factors. Karner [5] proposes Use Case Point (UCP)
as a method that exploits use case diagrams as a basis to estimate software development effort. In
particular, the method classifies actors and use cases calculating their complexity and including
subjective factors about overall system complexity and efficiency. Fishman [8] proposes Class
Method Point to estimate the size for UML-derived software that is equivalent to FP but easier to
learn, with an extension for complex internal functions. Sarferaz [9] presents the CEOS method to
estimate the effort based on decomposing system (described by a class diagram) into manageable
building blocks (component, subsystem, classes) and assessing the complexity for all their
associated development cycles.
Unfortunately the result of these metrics and methods are not directly comparable to other metrics,
such as traditional FP or LOC. Moreover, the proposals more close to UML present three main
drawbacks:
1) few kinds (typically 1) of UML diagrams are used in each method;
2) subjective parameters are extensively used;
3) the human interaction is always required.
Our proposal is, to the best of our knowledge, the first one attempting to estimate software
complexity relating several UML diagrams in an integrated and completely automatic way.
3. The Fast&&Serious method
The philosophy underlying our method is based on the following considerations:
3

1. The class diagram is the most important diagram;
2. The class diagram level of detail is not always the same;
3. The more is the information associated with a class the more we can refine the estimation.
According to such considerations, we developed a method that starts analyzing the class diagram
and, on the basis of the diagram level of detail, applies a rough (Fast) or a detailed (Serious)
estimation method. Figures got for the classes belonging to the class diagram are assessed through
additional pieces of information coming from other UML diagrams (i.e., use cases, sequence
diagrams, and state diagrams). Moreover, in order to make our method totally automatic we
considered only the data and the relationships stored within a Rational Rose file.
In the following we detail our method.
The Fast&&Serious measurement process consists of six major steps, some of them optional. Table
1 lists them, where a * denotes an optional step. It is worth noting that in this section we introduce
several formulas whose constants have to be fixed performing exhaustive tests; in the following we
use preliminary figures derived by some training experiments.
Step Description
1
2
3*
4*
Determine the type of method to apply: Fast or Serious
Calculate the complexity of each class (CP) in the class diagram under analysis.
Assess the CPs by use case diagram.
Assess the CPs by interaction diagrams.
5* Assess the CPs by state diagrams.
6
Sum the CPs computed in phases 2, 3, 4, and 5 obtaining the number of SLOC of the whole system.
Step 1: Fast or Serious?
Table 1: the six steps of the Fast&&Serious method
In this step we analyze the class diagram and we extract for each class the following metrics:
DIT (Depth in Inheritance Tree)
MPC (Number of Methods per Class)
NAC (Number of Association per Class)
PMS (Percentage of methods with signature).
We use the average of PMS to choose the method to adopt in the next steps: if PMS>threshold then
we use the Fast method, otherwise we use the Serious method. (In our first experiments we set
threshold=70%)
DIT, MPC, and NAC will be used during next steps.
4

Step 2: Computing class complexity
In this step we calculate a complexity value for each class. First we classify class attributes in three
categories: Light, Heavy, and Imported. For a class c we consider even the public or protected
attributes of each superclass of c.
Table 2 helps to identify each kind of attribute and shows the associated weight as well.
Complexity Definition Weight
Light Simple attributes, such as integer, string, etc. 1
Heavy
Imported
Complex attributes developed and tested yet, such
as attributes in predefined packages.
Complex attributes of a class not developed and
not tested yet.
Table 2: weighted attributes
Let ListAttr be the set of classified couples .
We calculate the number of State Point (SP) as:
SP(
c)
=
numAttr(
c)
∑
i=
1
Weight(
ListAttr )
i
(1.1)
where numAttr(c) is the number of attributes belonging to class c.
After that, we classify methods in two categories: Trivial and Substantial.
With the Fast method we classify all methods as Substantial with one Imported attribute.
With the Serious method we analyze the signatures of methods following the guidelines specified in
Table 3.
Complexity Definition
Trivial (T)
Substantial (S)
Methods that have at least 80% Light attributes and that have not
Imported attributes in the signature.
Non Trivial methods
Table 3: Methods Classification Rules
Note: as ”default property” we assign one Imported attribute:
• for all methods if we adopt Fast;
• if a method has not signature;
• if a class has not attributes.
For each method m we calculate the Complexity of Method (CM) as:
3
5
5

CM ( m)
=
( T S )
⎛1
⎜
⎝1
2
3
⎛ numLA⎞
3⎞⎜
⎟
⎟⎜numHA⎟
5⎠⎜
⎟
⎝ numIA ⎠
where numLA, numHA, and numIA are the number of Light, Heavy, and Imported attributes in the
signature of m, respectively. T and S stand for Trivial (T=1, S=0) and Substantial(T=0, S=1).
We use CM to estimate the Behavioural Point (BP) of a class c as:
BP(
c)
= [ 1 + numAss ( c)]
numMet ( c )
∑
i=
1
CM ( m
where numAss(c) is the number of associations of class c (NAC) and numMet(c) is the number of
methods of class c.
Finally we calculate, for each class, the number of Class Point (CP) as:
CP ( c)
= 2*
SP(
c)
+ 3*
BP(
c)
i
(1.2)
)
(1.4)
(1.3)
CP(c) estimates the complexity of class c.
Note that if a class c has no attributes and methods it is not included in the estimation process.
Step 3: Assessing class complexity using Use Case Diagrams
In this step we want to assess the CP associated with each class in the previous step using
information extracted from use case diagrams.
We start associating a complexity value with each use case and each actor; after that we assess the
CP(c) depending on the complexity of use cases and actors associated with the class c. We suppose
that each use case uc is associated with a number of scenarios (numScen) (such as interaction
diagrams). For each use case uc we calculate its complexity (COUC) as:
COUC(
uc)
= 1+
numScen(
uc)
∑ =
i 1
numMess
where numMessi is the number of messages exchanged between all objects in scenarioi. ”1”is a
constant useful for an uc that has not associated scenarios.
For an actor a we calculate the Complexity Of Actor (COA) as:
COA ( a)
= numAss(
a)
* dit(
a)
where numAss(a) is the number of associations among a and the use cases (if the actor is a subactor
in a hierarchy we add all the numAss of the parent actors); dit(a) is the Depth in Inheritance Tree
(DIT) for a.
6
i
(1.5)
(1.6)

Now, for each class c in the Class Diagram we scan all the scenarios to find instances of objects
belonging to c and for each instance, we store an association between c and the use case the
scenario belongs to. In other words, we assume that an actor a is associated with a class c if there is
a use case associated with c that communicates with a.
For a class c we calculate the Complexity of Use Cases Associated with c (CUCA) and the
Complexity of Actor Associated (CAA) with c as:
CUCA(
c)
=
numUC ( c)
∑
i=
1
COUC(
uc )
i
(1.7)
CAA(
c)
=
numAct(
c)
∑
i=
1
COA(
a )
where numUC(c) is the number of use case associated with c and numAct(c) is the number of actors
associated with c.
We use CUCA(c) and CAA(c) to assess the complexity of c finding in Table 4 the
increment/decrement percentage for c.
For example if CP(c)=1000 and CUCA(c)=8, CAA(c)=15 we obtain a new value for
CP(c)=1000+1000*9/100.
CUCA(C)
CAA(C)
Step 4: Exploiting Interaction Diagrams
0- 3 4-6 7-9 10-13 >13
0-4 -10% +3% +5% +7% +20%
5-10 -5% +2% +5% +10% +25%
10-20 +6% +7% +9% +25% +30%
Table 4: Use Case assessing percentage
In step 3 we have illustrated the strategy to assess the CP of a class when new information is
available. In this step we focus our attention on interaction diagrams; in particular we refer to
sequence diagrams.
Then, for each sequence diagram sedj where j=1..nsed and nsed is the number of available sequence
diagrams we look at the instances of c in each sedj calculating numMess(c, sedj) as the number of
messages sent or received from instances of class c in sedj.
Finally, let totMess(c) the sum of numMess(c, sedj) and let rsed(c) the ratio between the number of
sequence diagrams in which c appears and nsed. Roughly speaking, totMess(c) gives an idea of the
amount of communication involving class c, while rsed(c) corresponds to the percentage of code
that communicates with such a class.
These values are useful to find in Table 5 the percentage of increment/decrement for CP(c).
i
(1.8)
7

totMess(c)
rsed(c)
Step 5: Exploiting State Diagrams
0- 3 4-6 7-9 10-13 >13
0-19% -10% -5% 5% 7% 12%
20-49% -5% 2% 5% 10% 13%
50-100% 4% 5% 7% 10% 15%
Table 5: Interaction diagram assessing percentage
A State Diagram std may be directly associated with a class c or to a method of c. We extract the
following values from each std: the number of states as numSta(std) and the number of actions (i.e.,
entry and exit actions associate with a state) as numAction(std).
We assess CP(c) finding in Table 6 the percentage of increment/decrement computing the total
amount of states totSta(c) and of actions totAction(c) for the class c.
totSta(Std)
totAction(Std)
Step 6: Computing the whole system size
0- 3 4-6 7-9 10-13 >13
0-5 -8% -3% 3% 7% 12%
6-10 -3% 2% 4% 10% 13%
11-20 3% 4% 7% 12% 15%
Table 6: State diagram assessing percentage
So far, we have a CP(c) associated with each class in the class diagram CD; CP(c) is correlated with
the size of c and of the whole system (in terms of java SLOCs) through the following formulas:
Size ( c)
= 4 + 10*
CP(
c)
0.
7
(1.9)
Size ( System)
Size(
c )
∑ ∈
=
ci
CD
i
(1.10)
We can obtain the number of FP associated with the Size(System) using the backfire index for the
java language.
4. A Simple Fast&&Serious Calculation
We want now to explain how our proposal works through a simple example of a software project
named “Web Bookstores”. This project was implemented using Java servlets.
We have a Rational Rose 98 petal file which describes the design specification. In this file we have
the following diagrams:
• 1 Use Case Diagram;
• 1 Class Diagram that describes the Data Base of the web-site.
8

Step 1: looking at the Class Diagram (Main) shown in Figure 2 we can see that PMS=0%

Bookstore search_Author() Sub 1 3
Bookstore search_Topic() Sub 1 3
Bookstore search_Title() Sub 1 3
Table 8: note the use of the “default property”
Finally we calculate a value of complexity for all the 5 classes, using (1.3) and (1.4).
Table 9 shows the final result of Step 2.
Step 3:
Class Name SP BP CP
Author 5 1 13
Topic 2 1 7
Bookstore 2 28 88
Nearby 11 1 25
Book 14 3 37
Table 9: Final report of Step 2.
In this step we analyze the use case diagram shown in Figure 3.
0..n
execute
search
1..1
Client
Availability
1..1
visualize
0..n
search_Author
search_Title
BookReport
Figure 3: The use case diagram
search_Topic
BookInfo
AuthorInfo
The present use cases are very simple and so then there are not scenarios associated with one of
them. For the use cases we apply (1.5) and we obtain the same value (COUC=1) for each of the 8
use cases. There is one actor “Client” with COA(Client)=2 because of this actor communicates with
10

2 use cases. Looking at the class diagram we can infer the association between use cases and classes
shown in Table 10.
Class Name Associated use cases. CUCA COA inc/dec
Author AuthorInfo,
BookInfo
2 0 -10%
Topic BookInfo 1 0 -10%
Bookstore Search,
Search_Topic,
Search_Author,
Search_Title
4 4 +3%
Nearby Availability 1 0 -10%
Book BookInfo,
BookReport
2 2 -10%
Table 10:Association among use cases and actors
Note: In this table "inc/dec" are derived from Table 4.
The news CP(c) are listed in Table 11:
Class Name CP(C ) old CP(C) new
Author 13 11.7
Topic 7 6.3
Bookstore 88 90.64
Nearby 25 22.5
Book 37 33.3
Table 11:Final report of Step 3
Step 4 and 5: There are not other diagrams so we skip these two steps.
Step 6: Finally we apply (1.9) to obtain the size of each class. The SLOC estimated for the classes
and for the System are shown in Table 12:
Class Name Size
Author 60
Topic 40
Bookstore 238
Nearby 92
Book 120
Size(System) 550
Table 12:Size in java SLOC for each class
The project was developed using 608 SLOC vs the 550 estimated; then the error is about 9.5%.
11

5.Conclusion and future work
In this paper we present a novel method for estimating OO software projects size exploiting UML
diagrams. The main features of our approach are:
1. the method can be totally automated;
2. it exploits all the principal UML diagrams in its estimation process;
3. its output is in terms of SLOC, so can be compared with well known standard like FP.
In this very moment, we are setting an experiment to fix the formulas' constants we introduced in
the method. The experiment will be carried out together with the Ericsson Lab Italy that will
provide us with a large set of homogeneous Rational Rose diagrams plus the actual class size in
terms of java SLOC.
6. References
[1] T. Fetcke, A. Abran, T. H. Nguyen. “Mapping the OO-Jacobson Approach into Function Point
Analysis”. Proceedings of TOOLS-23’97, Santa Barbara, CA. IEEE.
[2] G. Caldiera, G. Antoniol, C. Lokan, R. Fiutem. ”Definition and Experimental Evaluation of
Function Points for Object-Oriented System”. Proceedings of 5 th International Software Metrics
Symposium, pp. 167-178. Bethesda Maryland, November 1998. IEEE.
[3] T. Uemura, S. Kusumoto, K. Inoue. “Function Point Measurement Tool for UML Design
Specification”. Graduate School of Engineering Science, Osaka University.
[4] A. Minkiewicz. ”Measuring Object-Oriented Software with Predictive Object Points”. ASM’97,
Atlanta, October 1997.
[5] G. Karner. ”Resource Estimation for Objectory Projects”. Objectory Systems, 1993.
[6] Whitmire, Scott. “3-D Function Points: Applications for Object-Orented Software in
Applications of Software Management Conference (1996)
[7] H. Sneed. Estimating the Costs of Object-Oriented Software. Proceedings of Software Cost
Estimation Seminar, System Engineering Ltd. , Durham, UK, March 1995.
[8] L. Fischman, K. McRitchie. “A Size Metric For UML-Derived Software”
[9] S. Sarferaz, W. Hesse. ”CEOS-A Cost Estimation Method for Evolutionary, Object-Oriented
Software Development”. Proceedings of New Approaches in Software Measurement, 10 th
International Workshop, IWSM 2000, Berlin, Germany, October 2000.
[10] T. E. Hastings, A. S. M. Sajeev. “A Vector-Based Approach to Software Size Measurement
and Effort Estimation”. IEEE Transactions on Software Engineering, vol. 27, NO. 4, April 2001.
[11] Interantional Function Point Users Group "Function Point Counting Practices Manual -
Release 4.1", 1999.
12