Assessing the Impact of Framework Changes Using Component Ranking
Reishi Yokomori † Harvey Siy †† Masami Noro † Katsuro Inoue ††††Department of Software Engineering, Nanzan University
27 Seirei-cho, Seto, Aichi 489-0863, Japan††
Department of Computer Science, University of Nebraska at Omaha
6001 Dodge Street, Omaha, NE 68182, USA†††
Graduate School of Information Science and Technology, Osaka University
1-5 Yamadaoka, Suita, Osaka 565-0871, Japan{yokomori, yoshie}@se.nanzan-u.ac.jp, hsiy@mail.unomaha.edu, inoue@ist.osaka-u.ac.jp
Abstract

reducing development interval while maintaining software
quality.

Most of today’s software applications are built on topof libraries or frameworks. Just as applications evolve, libraries and frameworks also evolve. Upgrading is straightforward when the framework changes preserve the API andbehavior of the offered services. However, in most cases,
major changes are introduced with the new framework release, which can have a significant impact on the application. Hence, a common question a framework user mightask is, “Is it worth upgrading to the new framework version?” In this paper, we study the evolution of an application and its underlying framework to understand the information we can get through a multi-version use relation
analysis. We use component rank changes to measure this
impact. Component rank measurement is a way of quantifying the importance of a component by its usage. As framework components are used by applications, the rankings ofthe components are changed. We use component ranking
to identify the core components in each framework version.
We also confirm that upgrading to the new framework version has an impact to a component rank of the entire systemand the framework, and this impact not only involves components which use the framework directly, but also otherindirectly-related components. Finally, we also confirm that
there is a difference in the growth of use relations between
application and framework.

Modern software systems often consist of hundreds or
thousands of classes, packages, functions and modules. Important information is scattered all over the software system. Analysis based on use-relations between components
is essential to grasp the entire picture. However, use relation analysis is a very effort-intensive task due to the needto perform syntactic and semantic analysis of source code.
Most of the previous work on use-relation analysis has focused on analyzing individual software versions rather thanmultiple versions. We suggested a method for detecting important updates in a development history by analyzing use
relations[14]. In [14], we suggested a metric which represents the overall impact of the update by calculating thedifference between two component ranks, before and after
update. However, we also have to analyze inside the software system by using use relations and metrics calculated
from them.

1. Introduction
In software development, creating applications on topof frameworks is a widely-accepted practice. Frameworks
contain reusable functions, models and code patterns. Developers build on the framework with their own functions,

In this paper, we analyze the evolution of the use relationship between the framework and an application built on
it. We make use of several metrics calculated from use relations. In an experiment, each version of the combined
software system is analyzed first, and then each version of
the application and the associated framework version are
analyzed separately. We extract external use relations between framework and application. Based on these use relations, we analyze the system by using several metrics suchas number of incoming and outgoing edges, component
rank[8], and the impact of the update. In the experiment,
trends of the above metrics of each subsystem are also analyzed and we weigh the differences between the evolutionof distribution of incoming and outgoing edges.
The impact of upgrading to a new framework version isanalyzed by investigating how component ranks change asa result of the update. By determining the effect of framework updates in the ranks and the growth of use relations,application developers can recognize where to pay attention when they update the framework. The sensitivity of thecomponent rank metric is also evaluated by comparing thecomponent ranks of the framework classes with and without
the application classes. By finding functions and functionalgroups used in actual applications, framework developers
can organize their framework to simplify its usage.
Through these analyses of use relations across multiple
versions in a software repository, we observe the effects
such external use relations would have on both the framework and the application, and consider characteristics of adevelopment project which uses a framework. These analyses provide a rich source of information, alerting us to thefact that we can observe the growth of software multilaterally by also using the growth of use relations.
In Section 2, we present models and approach based on
use relations as background. The results of applying theapproach to an open source project are presented in Section
3. Finally, we discuss the effectiveness of the model andrelated works in Section 4.

2. Background2.1. Component Graph
In general, a component is a modular part of a systemthat encapsulates its content and whose manifestation is replaceable within its environment [9, 11].
We model software systems by using a weighted directed
graph, called a Component Graph[8]. A node in the graphrepresents a software component 1, and a directed edge fromnode x to y represents a use relation meaning that component x uses component y. If the graph consists of several
software systems, a node may be combined with anothernode in certain conditions, such as because names of thesenodes are the same, or contents of these nodes are almost
same. Figure 1 shows an example of component graph forsoftware system X. X consists of 5 components A – E.
This graph also shows that component C uses both A andB, and D and E use C.
By using a component graph, we can easily identify theuse relations between components and count the incoming
and outgoing edges of a component. And we also calculate
a component rank by using the component graph.

A

B
C

D

E

System X
Figure 1. Component Graphthe ordering of values in an eigenvector for an adjacency
matrix, which is derived from a given component graph.
Intuitively, we regard the given graph as a Markov
chain[1]. If the chain is irreducible, a calculation of steadystate distribution always converges without recourse to an
initial condition. So the initial values of nodes are quitesame values, and then the steady-state distribution of thegraph is calculated by power method on the adjacency matrix. Each value of the nodes is the value in steady-state distribution, in other words, the value in the eigenvector for the
maximal eigenvalue of the matrix. Components are sortedby the value of the nodes, and we call the ranked data, thecomponent rank of a set of components. For details, pleaserefer to [8].
Product

Concrete
Product A

CreatorConcrete
Product B

Concrete
Creator A

Concrete
Creator B

ClientFigure 2. Component Graph for a Factory
Method pattern

Based on the concept of the component graph, we proposed a component rank model. This rank is determined by

For example, a system which realizes a factory method
pattern[4] is represented as a component graph in Figure 2.
Table 1 is a component rank for this system 2 . Product andCreator are used by many other classes, so these classes are
determined as important from the ranking. Thus, the more
a component is directly or indirectly used, the higher is its
rank. Components ranked high are generally important data
structures or will play an important role in understanding

1 “Component” is used in the broad sense of the word to mean any class,function, package, etc., that represents a logical unit in the program.

2 This component rank takes into consideration pseudo use-relations toconverge[8].

2.2. Component Rank Modelthe system’s behavior.
Table 1. Component rank for Figure2
Rank
1
2
3
3
5
5
7

Class
Product
CreatorConcreteProductA
ConcreteProductB
ConcreteCreatorA
ConcreteCreatorB
Clientvalue
0.409310.14301
0.09699
0.09699
0.09128
0.091280.07113

The component ranks and use relation metrics are calculated using SPARS-J, which treats Java classes as components. We consider the following as use relations: declaration of variables, creation of instances, method calls, andreference of fields. An analysis of use relations uses only
static analysis, so dynamic binding is excluded.
We investigate the evolution of use relations over several releases of the application, determining whether use
relations between framework and application show sometrends, by using several metrics.

3.1. Preparation
Component rank is also used as a ranking method in
SPARS-J 3 , a search engine for Java software components.
In [8], we indicate that component rank is useful for acomponent search engine through evaluation experiments,
which showed that component rank moves the search resultcloser to the result expected by user.

2.3. An Update-Evaluation Metric based on
Component Rank
As another usage of component rank model, we suggested a method for detecting important updates in a development history[14]. In the model, we considered thatan update which brings sweeping changes in use relations
is an important update because such update has a considerable impact on the entire system. We hypothesized thatcomponent rank also changes along with the change of use
relations between components, and suggested a way to measure the use relation’s change by calculating the differencein two component ranks, before and after update.
Based on the method, we developed a system which calculates the metric for each update, by obtaining source codefrom CVS and analyzing these code versions. We applied
the system to several open source projects as an evaluation
experiment. As a result, we can identify not only majorscale updates such as large function addition, but also relatively smaller updates, such as maintenance activities tocore components, and refactoring and re-structuring of asoftware system. Some of these updates are not large interms of lines of code (LOC) changed, but they are important updates because they have a large impact on the entire
system. We confirmed that using the metric to quantify theuse relation’s change is effective to get another perspectiveon the source code’s growth.

3. Experiment
In this paper, we analyze use relations between a framework library and an application which uses the framework.
3 SPARS-J demo: http://demo.spars.info/

In the experiment, we analyze the JHotDraw framework4 , a Java-based GUI framework for technical and structured graphics. As an application, we also analyze JARP 5 .
JARP is a Java-based Petri tool using JHotDraw as a framework for editing a Petri net, drawing the result, and so on.
Both JARP and JHotDraw are hosted in SourceForge 6 ,from which we obtained the source code for each version of
JARP and JHotDraw. JARP released 11 versions from 2001
to 2006, and we analyze these 11 versions along with the
JHotDraw release used in each version.
Table 2 is a summary of 11 versions of JARP. Each version of JARP uses a certain version of JHotDraw, for example, JARP version 1.0.0 used JHotDraw 5.1, and JARP version 1.1.12 used JHotDraw 5.3, and so on. The class column
refers to total number of classes, both of JARP classes andof JHotDraw classes. LOC is a fully inclusive sum, both
JHotDraw and JARP, this set corresponds to Set 1 described
below.
Table 2. The history of JARP
1
2
3
4
5
6
7
8
9
10
11

Versions
1.0.0
1.0.0.1
1.0.1
1.1.9
1.1.101.1.11
1.1.12
1.1.13
1.1.141.1.151.1.16Date
2001/1/21
2001/1/26
2001/1/27
2001/4/30
2001/10/14
2001/11/1
2001/12/12
2003/4/22
2004/6/24
2005/2/11
2006/7/30

JHD
5.1
5.1
5.1
5.1
5.2
5.2
5.3
5.3
5.4
5.4
5.4

Class
196( 41+155)
196( 41+155)
196( 41+155)
284(129+155)
304(133+171)
312(141+171)
416(174+242)
433(191+242)
740(215+525)740(215+525)740(215+525)

LOC
23K
23K
23K
29K
31K
32K
42K
44K
82K
82K
82K

3.2. A Procedure of Analysis
In this experiment, we use only direct use relations, suchas declaration of variables, creation of instances, method
calls and reference of fields as use relations.
4 JHotDraw: http://www.jhotdraw.org/
5 JARP: http://sourceforge.net/projects/jarp/
6 SourceForge.net - Open Source Software: http://sourceforge.net/

We extract the following metrics for each version:(a) The number of outgoing edges of each nodeThis means how many classes the class uses. Even
if there are more than one use relations between twoclasses, we treat as one use-relation exists between
these classes.
(b) The number of incoming edges of each nodeThis means how many classes use this class. As in
the case of outgoing edges, we exclude duplicate use
relations.
(c) A value of each node in steady-state distribution
These values are calculated from a component graphwhich includes both JHotDraw and JARP, and are used
for decision of component rank for a given componentset (both JHotDraw and JARP, only JARP and only
JHotDraw).

JHotDraw

JHotDraw (Set 3)
Compare

JARP(Set 2) Compare
Set 1

Set 3’JARP
Set 2’

Figure 3. Analysis Overview

Figure 3 is an overview of the analysis. The procedureof analysis is the following:(1) We analyze the entire of system (both JARP and JHotDraw) by using SPARS-J system. The analysis result
is called Set 1. Set 1 is not used immediately, but isused for calculation of Set 2 and Set 3.
(2) We divide Set 1 into a result of classes which belong
to JARP package (Set 2), and the one which belong to
JHotDraw package (Set 3).
(3) We analyze JARP by itself by using SPARS-J system.
The analysis result is called Set 2’. Set 2’ considers
only internal use relations in JARP.
(4) In the same way, we analyze JHotDraw by itself. The
analysis result is called Set 3’. Set 3’ considers onlyinternal use relations in JHotDraw.

(5) By comparing these results, we calculate the number ofexternal incoming edges and external outgoing edges
which exist between JARP and JHotDraw. We also
check the change of component rank and components
whose metrics are sensibly changed.

3.3. Overall Results
We measure an update-evaluation metric, described in
Section 2, with general metrics such as number of classes,
LOC, and so on.
The metric represents the overall degree of changes incomponent rank values. In the metric, component rank isnormalized into the value between 0 and 1, and metric calculates average of component rank’s change for each component which exists both before and after update.
We obtain component rank for Set 1, Set 2 and Set 3 respectively, and calculate update-evaluation metrics among
11 versions. Table 3 is the result. For example, in the caseof version 1.1.9, the result shows that the relative rank ofeach class moves up or down 6% on average. Considering
only JARP classes, the component rank of each class moves
up or down 26% on average. So we can consider that thisversion is a major update for JARP. Overall, updates for version 1.1.9, 1.1.12 and 1.1.14 increases the number of classes
and changes its component rank substantially, and can beconsidered as major revisions for JARP.
Next, we focus attention on the change of component
rank of subsystems (Sets 2 and 3). In the case of Set
2(JARP), versions 1.1.9, 1.1.12 and 1.1.14 change theircomponent rank. These three updates change class allocation drastically, so many components moved to anotherpackage and JARP is re-organized. We can find the architecture restructured several times in these updates. For example, in the case of version 1.1.9, functions assumed bymainwindow class are divided into other subcomponents,
and tools package is newly produced and many functions
are implemented or moved to tools package. In addition, inversion 1.1.12, functions assumed by PetriNetImpl are also
divided into other subcomponents, and edition and simulation packages appear.
In the case of Set 3(JHotDraw), version 1.1.10, version
1.1.12 and version 1.1.14 have relatively high values. Thisis because the version of JHotDraw was updated in such releases. Specially, in the case of version 1.1.14, the numberof classes in JHotDraw increases 290 classes with the introduction of JHotDraw version 5.4.
In the case of this system, we can confirm that component rank also changes substantially if the number of classes
increases substantially. In this way, we can detect major updates by using the change of component rank, and we canalso detect which subsystems are modified substantially by
evaluating for each subsystem.

Table 3. Component rank update metrics
1
2
3
4
5
6
7
8
9
10
11

Versions
1.0.0
1.0.0.1
1.0.1
1.1.9
1.1.101.1.11
1.1.12
1.1.13
1.1.141.1.151.1.16

All
0
0
0.06
0.02
0.02
0.05
0.01
0.18
0
0

JARP
0
0
0.26
0.02
0.03
0.07
0.01
0.05
0
0

JHotDraw
0
0
0.01
0.03
0.01
0.04
0
0.21
0
0

So such component only controls the ambiguous and large
feature, and uses only the essentials. In the latter period,classes for implementation and for handler, and so on use
many framework components.
In the development of JARP, developers managed components not by designing precisely from the beginning, but
by breaking down components that are too big. We think
this is a better way for open source project because developers don’t know which subsystem they should focus anddevelop with consideration of extensibility at the beginningof development.
90
80
70
60

3.4. Analysis of Outgoing Edges
For each version, we count how many classes in JHotDraw each component in JARP uses. If a component uses
other components several times, we treat as one use relation. We also find that JARP has some classes in JHotDraw
with some modification; however, these classes are integrated into an original class during construction of component graph. Because there are some JHotDraw classes modified by JARP developers, use relations from JHotDraw to
JARP may also exist. However, external use relations that
we can confirm in 11 revisions are all from classes in JARP
to classes in JHotDraw.
Table 4 is a summary of result on outgoing edges, withthe package name of each component abbreviated. We extract 4 versions and show a top ten ranking for each version. For example, JDrawingView in version 1.0.0 uses 17classes. It appears from the table that the outgoing edges perclass is bounded (the values in the top rows are not steadily
increasing).
To confirm that the maximum number of outgoing edges
per class is bounded, we plot the cumulative frequency foreach version in Figure 4. We can find that the number ofclasses which call the framework increases from one version to the next; however, within a given version, the number of class reaches a plateau early (most classes have lessthan 5 outgoing edges; beyond that, the cumulative number
does not increase significantly).
To explain this observation, we focus on the evolutionof components which use a lot of framework classes. In
earlier versions, such components play multiple roles that it
controls and implements an ambiguous and large feature. In
later versions, implemented codes in such components are
split into fragments of components.
We can picture a situation where a developer divides alarge class into several small classes when a size of coreclass becomes too big to manage. In such a situation, usageof the framework is also divided into these small classes.

Ver10050

Ver110940

Ver1112
Ver1113

30

Ver111420
100
1 2 3 4 5 6 7 8 9 101112 13 14 15 16 17 18 19 20

Figure 4. Cumulative frequency of outgoingexternal edge

2500
2000
innerJHD
1500
1000
500

innerJARP

external

0

Figure 5. Growth of use relations
Figure 5 shows the growth of use relations over time.
The number of internal use relations in JHotDraw and
JARP, and as well as the external use relations from JARP
to JHotDraw are counted. Most of the time, the internal
use relations in JARP and the external use relations have increased by similar rates. In version 1.1.9, however, only the
inner use relations in JARP increased, this is because JARP
was restructured into a model-view-controller architecture.

3.5. Analysis of Incoming Edges
As in the case of outgoing edges, we also count how
many JARP classes use each JHotDraw class. Table 5 is aTable 4. Ranking of outgoing external use-relation (from JARP classes)
1
2
3
4
5
6
7
8
9
10

Ver 1.0.0
JDrawingView
MainWindow
PetriPlaceImpl
PetriTransitionImpl
PetriConnectionHandle
PetriSelectionTool
PetriArcImpl
PetriSimulationTool
JHDLoadTool
PetriDragTracker

17
16
11
11
7
5
5
5
4
3

Ver 1.1.9
JDrawingView
PetriPlaceImpl
PetriTransitionImpl
PetriSelectionTool
PetriNetImpl
PetriConnectionHandle
PetriDragTracker
EditionTool
PetriArcImpl
PetriSimulationTool

17
14
12
11
7
7
7
7
6
5

Ver 1.1.12
PlaceImpl
TransitionImpl
SelectionToolEx
ArcImplPetriConnectionHandle
PasteCommand
CreationTool
MainWindow
JDrawingView
PetriNetImpl

14
12
12
9
8
8
8
7
6
5

Ver 1.1.14
PlaceImpl
ArcImplTransitionImpl
DrawingPreview
BendpointHandle
JDrawingView
WeightHandle
TokensHandle
PasteCommand
PetriNetImpl

18
17
16
13
11
10
9
9
8
7

Table 5. Ranking of incoming external use-relation (to JHotDraw classes)
1
2
3
4
5
6
7
8
9
10

JH 5.1 in JARP 1.0.0
DrawingView
Drawing
util.StorableInput
Figureutil.StorableOutput
Tool
DrawingEditor
ConnectionFigure
Connector
standard.AbstractFigure

8
6
5
5
4
4
4
3
3
3

JH 5.1 in JARP 1.1.9
DrawingView
DrawingEditor
Drawing
Figureutil.StorableOutput
util.StorableInput
Tool
standard.AbstractFigure
figures.AttributeFigure
figures.TextFigure

12
12
9
8
4
4
4
4
3
3

summary of result about external incoming edges. We also
extract 4 versions and show a top ten ranking for each version, with package names abbreviated. For example, DrawingView in version 1.0.0 was used by 8 classes in JARP.
Classes written in boldface came from the framework
package in JHotDraw. The top ten classes are almost all in
the framework package. Others are classes for dealing afigure and utility classes for command, input and output.
Unlike the case of outgoing edges, we observe that theincrease in maximum number of incoming edge per classover the release history is open-ended. Figure 6 represents
a cumulative frequency for each version. We find that the
number of framework classes used by the application gradually increases over time, and the point at which we find the
maximum number is getting larger for each version.
Usually, when developers need to use a feature from aframework class, they don’t consider the number of times it
is already in use. When development undergoes evolution
and many features are implemented to the systems, suchframework classes are used by many application classes, sosuch framework classes gradually become core components
in the system. On the other hand, classes which have interfaces in the framework do not increase so much as long as
the framework itself is not expanded or re-organized.

3.6. Analysis of Component Rank (JARP)
We extract JARP components from the overall system,
and compute component ranks for JARP classes, corre-

JH 5.3 in JARP 1.1.12
Drawing
util.UndoableCommand
DrawingEditor
DrawingView
Figureutil.StandardStorageFormat
util.Command
Toolstandard.AlignCommand
standard.StandardDrawingView

16
15
15
12
10
7
7
6
6
6

JH 5.4 in JARP 1.1.14
FigureFigureAttributeConstantutil.Command
DrawingView
DrawingEditor
util.UndoableCommand
Drawing
FigureEnumeration
util.StandardStorageFormat
Tool

26
25
23
21
19
17
17
10
9
8

90
80
70
60

Ver100-1001-101

50

Ver110940

Ver1112
Ver1113

30

Ver1114-16

20
10
0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

Figure 6. Cumulative frequency of incoming
external edgesponding to Set 2 in Figure 3.
Table 6 shows the top ten classes ordered by component
rank, for 4 JARP versions. In the early period, the top tenclasses are almost about implementation class of Petri net.
For example, the 1st to 6th, 8th and 9th classes in version
1.0.0 are all in a Petri package. However, in version 1.1.9,
a lot of classes are added to the system, such as GUI classes(1st, 2nd, 5th and 8th), tool classes for XML browser (6thand 10th), and utility classes for configure and name treatment (3rd and 4th), so several kinds of classes appear in thelist. The ranks of Petri net classes move down, however,they gradually move up again in version 1.1.12 and 1.1.14.

We can guess that features are added into such component
also in latter period.
Component rank of application classes are affected by
implementation of features. By referencing a ranking andchecking a component whose rank moves up drastically, we
can guess what kind of implementation is done.
In this development period, JARP developers upgraded
the JHotDraw framework version three times, as shown in
Table 2. To investigate the impact of framework updates
on the application, we compared JARP component ranks
before and after each framework update. Table 8, Table 9
and Table 10 are lists of JARP components which significantly improved in component rank after these framework
updates. Components which were deleted or added in the
updated framework version are taken into account in thecalculation of component rank, however, these components
are excluded from the result for comparison.
These results shows that many tool classes appear in every list. Main and utility classes, such as Hash, Main,and SplashWindow, also appear in the lists. By upgrading the framework, developers change components whichaccess the framework, and main and utility classes also had
to be adapted. So, we must pay attention not only components which uses the framework directly, but also main andutility classes when framework classes are upgraded.

3.7. Analysis of Component Rank (JHotDraw)
As in the case of JARP, we also compute component
ranks for JHotDraw classes, corresponding to Set 3 in Figure 3.
The summary is in Table 7. Classes in boldface comefrom the framework package in JHotDraw. Through theprogression of JARP versions, highly ranked components
seldom move dramatically. These classes are almost all in
the framework package, except for a few in util. Some
classes in framework package are consistently high; suchclasses are recognized as core components in the framework. Some classes, such as Storable, Connector, Handle, FigureChangeEvent and so on, are used only a few
times by JARP or not at all, but are ranked high. These areheavily used internally by other JHotDraw classes.
In the result of Table 7, use relations from JARP aretaken into consideration. It is noted that both JARP versions 1.0.0 and 1.1.9 use JHotDraw version 5.1, but the differences between the two JARP versions were not enoughto affect the rank order of the top 10 JHotDraw components. To further assess the sensitivity of JHotDraw component ranks to the framework’s usage by application classes,
we also compute component ranks of JHotDraw by using
only internal use relations (Set 3’). The component rank
is almost same as the former one with respect to highly

Table 8. JARP Component rank’s change between ver1.1.9 and 1.1.10 (129 components)
1
2
3
3
5

Class
PetriNetImpl
Crc32Hash
Hash
PetriSelectionTool
25 components

ver9
92
71
24
80
-

ver10
62
59
17
73
-

diff
30
12
7
7
1

Table 9. JARP Component rank’s change between ver1.1.11 and 1.1.12 (124 components)
1
2
3
4
5
5
7
8
9
10

Class
PNMLStorageFormat
FormatTool
AlignTool
EditionTool
Main
LoadTool
PrintTool
FileFilterImpl
SplashWindow
PetriNetMarking

ver11
107
94
94
94
60
94
94
107
78
21

ver12
59
54
55
60
30
64
78
93
66
13

diff
48
40
39
34
30
30
16
14
12
8

Table 10. JARP Component rank’s change between ver1.1.13 and 1.1.14 (130 components)
1
2
2
4
5
6
7
7
7
7

Class
LanguageTool
ChangeNetNameTool
FindPathAnalysis
SelectionTool
Main
PetriInvariantAnalysis
CommentTool
GridTool
NewTool
NewWindowTool

ver13
107
117
117
104
31
77
107
107
107
107

ver14
22
84
84
72
6
53
84
84
84
84

diff
85
33
33
32
25
24
23
23
23
23

ranked components. This result shows that component rankof framework is mostly determined by the structure of theframework; the application largely does not impact the component rank measurements of the framework.
However, some lower-ranked components are affectedby the use relations from the application. Table 11 and 12
are lists of JHotDraw components whose ranks improved
drastically in version 1.1.9 and version 1.1.12 respectively.
For example, AlignCommand in version 1.1.9 moved up
38 ranks, from 133 to 95, by taking into consideration thelone use relation from JARP.
The rightmost column represents the number of classes
in JARP that use the component. Components used by application frequently do not appear so much because such

Table 6. Component Rank of JARP
1
2
3
4
5
6
7
8
9
10

Ver 1.0.0
PetriNet
PetriNetEditor
PetriNetComponent
PetriTransition
PetriArc
PetriPlace
IntHashtableEntry
MainWindow
PetriStatesEnumAnalysis
ImageEncoder

Ver 1.1.9
FindFilter
FindProgressCallback
ConfigName
EFileChooser
XmlBrowser
PetriNet
FindAccessory
PetriNetEditor
AdapterNode

Ver 1.1.12
FindFilter
FindProgressCallback
ConfigName
PetriNet
PetriNetEditor
EFileChooser
XmlBrowser
AbstractJARPTool
FindAccessory

Ver 1.1.14
PetriNet
FindFilter
FindProgressCallback
PetriNetEditor
Tool
XMLResourceBundle
ToolFactory
figures.Transition
Main
figures.Place

Table 7. Component Rank of JHotDraw
1
2
3
4
5
6
7
8
9
10

JH 5.1 in JARP 1.0.0
Figureutil.Storable
Connector
FigureEnumeration
LocatorFigureChangeEvent
FigureChangeListener
util.StorableInput
util.StorableOutput
ConnectionFigure

JH 5.1 in JARP 1.1.9
Figureutil.Storable
Connector
FigureEnumeration
LocatorFigureChangeEvent
FigureChangeListener
util.StorableInput
util.StorableOutput
ConnectionFigure

components have been already ranked high by inner use relation. However, as in the case of UndoableCommand inversion 1.1.12, the rank of such component is drasticallychanged if the component is not used in the framework.
Other classes are not frequently used by application.
These classes are not closely related to core components
in the framework, and perform specific functions used only
once in the application, such as command. Some classes,
such as handler or connector classes, are affected by indirect use relations. Such components are also used to support
design patterns.

4. Discussion
4.1. Significance of Use Relation Analysis
By analyzing changes in use relations, we can determine
which updates are major updates. In this experiment, we
can identify them through a change of number of classes
and LOC, however, in general, some important updates are
not big in terms of changed LOC, such as maintenance activities to core components, refactoring, re-structuring of asoftware system, and so on.
The number of incoming edges is also a good metric forunderstanding changes. However, if a framework function
is divided into sub-functions and implemented in several

JH 5.3 in JARP 1.1.12
FigureFigureEnumeration
Connector
LocatorFigureChangeEvent
FigureChangeListener
util.Storable
DrawingView
ConnectionFigure
util.StorableInput

JH 5.4 in JARP 1.1.14
FigureDrawingView
FigureEnumeration
JHotDrawRuntimeException
Connector
ConnectionFigure
Drawing
Handleutil.CollectionsFactory
DrawingEditor

classes in the latter periods, the result may only provide partial information. On the other hand, an evaluation of component rank takes into account indirect use relations, so we
can identify components which support designing, such as
handler and connector and so on.
From the analysis result, we can find that application
classes repeat growth and breakdown cycles in the development. At first, implementation and control of a function
are implemented to a class at the same time, and the classbecomes bigger as one grows. However, when a size ofthe class is too big, implementation is divided into smallerclasses. Component rank of application classes is affectedby an addition of function, so we can roughly estimate thecontent of updates by checking a component whose rank issignificantly changed.
Ichii investigated a distribution of a number of incomingedges and outgoing edges of component graph for a variety
of software systems[12]. He reported the distribution of anumber of outgoing edges is bounded by a size of class description, however, that of incoming edges is open-ended.
Our analysis result fits well with his result.
In this experiment, some framework classes maintain ahigh component rank over time, so we can easily identify core components and core functions used by application classes. On the other hand, a few components are notin framework package and are not used in the framework

Table 11. JHotDraw Component rank’schange in JARP ver1.1.9 (156 components)
1
1
3
3
5
6
7
7
9
10
10
10
13
14
15
15
17
18
18
18

Class
AlignCommand
ToggleGridCommand
ChangeAttributeCommand
DeleteCommand
DragTracker
ConnectionHandle
BringToFrontCommand
SendToBackCommand
BufferedUpdateStrategy
CopyCommand
CutCommand
PasteCommand
ChopEllipseConnector
GroupHandle
PolyLineHandle
SelectionTool
Clipboard
RadiusHandle
ShortestDistanceConnector
DrawingEditor

Set3
95
95
92
75
81
67
114
114
91
119
119
119
77
98
52
63
50
93
93
13

Set3’
133
133
125
108
111
87
133
133
108
133
133
133
88
107
60
71
56
98
98
18

diff
38
38
33
33
30
20
19
19
17
14
14
14
11
9
8
8
6
5
5
5

Used
1
1
1
2
1
1
1
1
1
1
1
1
1
0
1
2
1
0
0
12

classes, but its rank drastically changed because of use relations from application classes. In a practical sense, suchcomponents might be included into the framework package
because they can be considered as core components since
they are used as frequently as the components in the framework. This kind of usage information represents what functions and functional groups are used in actual applications.
Such knowledge can be used by framework developers indesigning future enhancements to the framework that would
simplify its usage.

4.2. Implications for Framework Upgrade
The number of incoming edges to classes in the framework almost has not been reduced through the development
period as shown in Figure 5, so we can presume that existing APIs also have been firmly maintained, even as developers add new functions and APIs to the framework. In
those cases, use relations from the application depend on arelatively small set of framework classes, though the number of relations per class may increase without bound. If
the number of framework interfaces is tightly controlled, it
is generally worth upgrading to a new framework version,
unless existing APIs change. However, other factors such as
quality and underlying defects should be taken into accountin the decision to upgrade.
In the case where component ranks in a new framework
version dramatically change, we can identify which application classes will need closer attention and testing by locating the affected framework classes and identifying theirdependent application classes through the incoming edges.

Table 12. JHotDraw Component rank’schange in JARP ver1.1.12 (241 components)
1
2
3
4
5
6
7
8
8
10
10
12
13
13
15
16
17
18
19
19

Class
UndoableCommand
StorageFormatManager
AlignCommand
ChangeAttributeCommand
StandardDrawingView
UndoableTool
ToggleGridCommand
BringToFrontCommand
SendToBackCommand
RedoCommand
UndoCommand
DeleteCommand
CopyCommand
CutCommand
PasteCommand
UndoActivity
Alignment
StandardStorageFormat
ConnectionHandle
Clipboard

Set3
43
48
68
90
61
79
120
124
124
132
132
102
138
138
159
118
55
49
104
73

Set3’
199
201
201
185
147
164
201
201
201
201
201
167
201
201
201
157
89
79
122
91

diff
156
153
133
95
86
85
81
77
77
69
69
65
63
63
42
39
34
30
18
18

Used
15
4
6
3
6
4
1
1
1
1
1
1
1
1
1
1
6
7
1
3

By knowing which application classes will likely be heavily impacted, the application developers can make a roughassessment of the work needed to upgrade to a new framework.
A core framework class may also be divided into several small classes in the process of framework evolution.
So we can consider a situation where existing APIs are redesigned and their usages are completely changed. In sucha situation, we can assume that a number of incoming edges
to some core components in the framework decreases, as in
the case of core application classes. We cannot find any
such situation in this experiment; however, we will explore
such situations in further replications of this study.

4.3. Related Works
Previous research on analysis of software repositories have focused on understanding reasons of softwarechanges[5], identifying how communication delay amongdevelopers have effects on software development[7], detecting potential software changes and incomplete changes[15],and so on. In [10], Johnson proposed an approach that automatically records developer’s activities with the objective offinding a relation between the internal characteristics (sizeand time, etc.) and the external characteristics (quality andreliability of products, etc.) rather than measuring updates.
Several researchers have also examined issues of framework evolution. Most of these studies focused on how
framework or library developers can make it easier for user
applications to migrate to newer versions of the framework
by providing automated or semi-automated support, such ascapturing and replaying API refactorings[6], creating compatibility layers[3], and providing annotations to generate
and guide updates to applications[2, 13]. Our work complements these researches by focusing on the application
developers and providing them with metrics-based guidancefor deciding when to update to a new library version.
Our method is an extension of [14], and our goal is tounderstand how software evolves by analyzing use relations
between software components. In this paper, we show that
we can grasp further particulars by splitting the system being analyzed, e.g., into framework and application.

5. Conclusion
In this paper, we analyzed changes in use relations between framework and application, by using several metrics. We found that framework and application have several
unique features in the growth of use relation. Component
rank of application classes were affected by implementation of features, and some framework classes drastically improved in rank due to use relations from application classes.
This kind of information represents what function and functional group are used in actual application and is useful for
guiding future enhancements or redesigns of the framework.
As future work, we are planning to apply our method toother software systems to verify the external validity of ourobservations, and to refine the evaluation method based on
how use relations evolved. Our ultimate target is establishment of the technique that can point out application components which should be modified or carefully inspected, andcan roughly estimate the cost of upgrading to a new framework version.
Acknowledgments
This work was supported by KAKENHI (19700033),
Grant-in-Aid for Young Scientists (B).

References[1] G. Blom, L. Holst, and D. Sandell. “Problems and snapshots from the world of probability”. Springer, 1994.
[2] K. Chow and D. Notkin. “Semi-automatic update of applications in response to library changes”. In Proceedings of theInternational Conference on Software Maintenance (ICSM’96), pages 359–368, Monterey, California, 1996.
[3] D. Dig, S. Negara, V. Mohindra, and R. Johnson. “ReBA:
refactoring-aware binary adaptation of evolving libraries”.
In Proceedings of the International Conference on Software
Engineering (ICSE ’08), pages 441–450, Leipzig, Germany,
2008.
[4] E. Gamma, R. Helm, R. Johnson, and J. M. Vlissides. “Design Patterns: Elements of Reusable Object-Oriented Software”. Addison Wesley, 1995.

[5] D. German and A.Mockus. “Automating the measurementof open source projects”. In Proceedings of the 3rd Workshop on Open Source Software Engineering, pages 63–67,
Portland, Oregon, 2003.
[6] J. Henkel and A. Diwan. “CatchUp!: capturing and replaying refactorings to support API evolution”. In Proceedingsof the International Conference on Software Engineering(ICSE ’05), pages 274–283, St. Louis, Missouri, 2005.
[7] J. D. Herbsleb, A. Mockus, T. A. Finholt, and R. E. Grinter.
“An empirical study of global software development: Distance and speed ”. In Proceedings of the 23rd international
conference on Software Engineering, pages 81–90, Toronto,
Canada, 2001.
[8] K. Inoue, R. Yokomori, T. Yamamoto, M. Matsushita, andS. Kusumoto. “Ranking Significance of Software Components Based on Use Relations”. IEEE Transactions on Software Engineering, 31(3):213–225, 2005.
[9] I. Jacobson, M. Griss, and P. Jonsson. “Software Reuse”.
Addison Wesley, 1997.
[10] P. M. Johnson, H. Kou, J. M. Agustin, Q. Zhang, A. Kagawa, and T. Yamashita. “Practical automated process andproduct metric collection and analysis in a classroom setting: lessons learned from Hackystat- UH”. In Proceedingsof the 2004 intl. Symposium on Empirical Software Engineering (ISESE2004), pages 136–144, Redondo beach, CA,
2004.
[11] C. Krueger. “Software Reuse”. ACM Computing Surveys,
24(2):131–183, 1992.
[12] M.Ichii, M. Matsusita, and K. Inoue. “An Exploration ofPower-Law in Use-Relation of Java Software Systems”. In
Proceedings of the 19th Australian Conference on Software
Engineering, pages 422–431, Perth, WA, Australia, May
2008.
[13] J. H. Perkins. “Automatically generating refactorings to support API evolution”. In Proceedings of the Workshop on Program Analysis for Software Tools and Engineering (PASTE’05), pages 111–114, Lisbon, Portugal, 2005.
[14] R. Yokomori, M. Noro, and K. Inoue. “Evaluation of Source
Code Updates in Software Development Based on Component Rank”. In Proceedings of 13th Asia Pacific Software
Engineering Conference, pages 327–334, Bangalore, India,
2006.
[15] T. Zimmermann, P. Weissgerber, S. Diehl, and A. Zeller.
“Mining version histories to guide software changes”. In
Proceedings of the 26th international conference on Software Engineering, pages 563–572, Edinburgh, Scotland,
2004.