Identifying Important Packages of Object-Oriented Software Using Weighted k-Core Decomposition

2.1 Software Entity Collection

This article mainly focuses on Java software systems. The choice of software systems in Java programming language is limited by our analysis tool and our interest. To identify the important packages of software systems, we consider the byte code of a software system. To represent a piece of software as a network, entities in the code should be extracted. As our focus is on identifying important packages, we first need to determine the entities that should be extracted. In the current work, packages, classes, and their dependencies are chosen as entities that will be represented as nodes and edges in a software network. We use the term “class” to designate classes and interfaces. We will be treating them the same from here on.

2.2 Software Network Definition

After the entities have been collected, we will introduce the software network to represent the topological characteristics of a Java software system. However, how is the software network defined?

As we all know, Java software systems are usually composed of entities at different levels of granularity, varying from methods and fields to packages. Upper-level entities are built by the lower-level ones, e.g., a package is composed of a collection of classes. As the interest of the current work mainly focuses on the identification of important packages, in the following, we will first introduce a package dependency network (PDN) to represent the topological structure of Java software systems at the package level.

Definition 1 In PDN, the nodes denote the packages of a specific Java software system. The undirected edge between every pair of nodes denotes the coupling interaction between the corresponding packages. The coupling interactions between packages are extracted from the interactions of the classes they enclosed, i.e., a dependency between two classes in two separate packages implies a dependency between the two packages. Therefore, PDN can be described as

where V_p is the set of nodes in PDN (the subscript p denotes the software network is constructed at the package level) and E_p is the set of edges.

Each edge is also weighted with a value to signify the coupling strength between the packages on its two sides. The weight on each edge allows us to consider the coupling strength between the packages on its two sides. However, how to determine such weights is still a problem. In the current work, we use the dependencies between classes that the two packages enclose to quantify the coupling strength. To calculate the weight, we introduce another type of software network, namely class dependency network (CDN), to represent the classes and their dependencies. CDN can be described as follows.

Definition 2 In CDN, the nodes denote the classes of a specific Java software system and each class is represented by only one node. Undirected edges between two nodes indicate the use dependency between the corresponding classes, i.e., if class c₁ uses the services provided by class c₂, there is an edge between the nodes denoting the two classes. The edge (or the use dependency) between class A and B can be defined under the following four circumstances: (i) A inherits from B via the keyword extends; (ii) A realizes interface B via the keyword implements; (iii) B has a field with type of class A; and (iv) one method of A calls methods on an object of B. Therefore, CDN can be described as

where V_c is the set of all nodes in CDN (the subscript c denotes the software network is constructed at the class level) and E_c is the set of edges.

Therefore, if there is an edge between class A and class B in CDN and the two classes are defined in two different packages, there will be an edge between the two packages. On the basis of the CDN, we can calculate the weight on the edges between package i and j in PDN according to formula (3):

where w(i, j) is the weight on the edge between package i and j, R_mk denotes the set of all reachable nodes originated from the node of class m within a distance k along with the edges, getClass(i) returns the set of all classes package i contains, and |*| returns the number of elements in set *.

Figure 2 shows a simple code segment and its corresponding CDN and PDN. For illustration purpose, we take w(p1, p2) to show how to calculate the weight on the edge. As p1.classX in package p1 directly depends on p2.classY and p2.classZ in package p2, there is an edge between p1 and p2 in PDN. At the same time, R_p1.classX₁ = {p2.classY, p2.classZ}. Thus, w(p1, p2) = |{p2.classY, p2.classZ} ∩ {p2.classY, p2.classZ}| = 2.

Figure 2

A Simple Code Segment and Its Corresponding CDN and PDN.

2.3 The Weighted k-Core Decomposition Method

Here, we introduce the weighted k-core decomposition method (W_k-core) [11], which is a generalized version of the original k-core decomposition method and is applied for weighted networks. As the original k-core decomposition method [1, 4] is applied for unweighted networks, from now on, we will call it the unweighted k-core decomposition method (U_k-core). W_k-core differs from U_k-core mainly in its way of node degree calculation. W_k-core is based on a weighted version of the traditional node degree, which considers both the degree of a node and the weights of its edges. The weighted degree of node i, wDeg(i), is defined as

where wDeg(i) is the weighted degree of node i, Deg(i) is the degree of node i, and ∑j = 1Deg(i)wij is the sum over all the edge weight of node i. In the current work, we also discuss only the case where α = β = 1 as [11] does, which treats the weight and the node degree equally. Therefore, for what follows, wDeg(i) = Deg(i)∑j = 1Deg(i)wij. Therefore, in the unweighted networks where w_ij = 1, wDeg(i) is equivalent to the Deg(i), while in the weighted network, wDeg(i) is usually a decimal. We discretize these decimals by rounding to their closest integers.

On the basis of the weighted degree of a node, we can introduce some definitions of weighted k-cores as that of the original k-cores proposed in [1, 4]. Let us consider a graph G = (V, E) with |V| = n nodes and |E| = e edges; the definitions of weighted k-cores are shown as follows.

Definition 3 A subgraph H = (C, E|C) induced by the set C⊆V is a weighted k-core or a weighted core of order k if and only if the weighted degree of every node v∈ C induced in H is greater than or equal to k (i.e., ∀v∈ C, wDeg(v) ≥ k), and H is the maximum subgraph with this property.

W_k-core applies a similar pruning routine as the U_k-core. A weighted k-core of G can therefore be obtained by recursively removing all the nodes of weighted degree less than k, until all nodes in the remaining graph have weighted degree at least k.

Definition 4 A node i has weighted coreness k if it belongs to the weighted k-core but not to the weighted (k+ 1)-core. Furthermore, the maximum weighted coreness, k_max, is such that the k_max-core is not empty, but the (k_max+ 1)-core is. k_max is usually named as the graph coreness. Moreover, the k_max-core is also called the main core.

The weighted coreness of a node also denotes how deep in the core a node is [20]. Obviously, all the nodes of a connected graph belong to the weighted 1-core.

Definition 5 A weighted k-shell, WS_k, is composed by all the nodes whose weighted coreness is k and the edges between them. The weighted k-core is thus the union of all WS_c with c ≥ k.

For illustration purpose, we give an example to show how to divide a network into the weighted k-core structure (see Figure 3). It is a simple network with only five nodes and four edges (see the leftmost part of Figure 3). All edge weights equal to 1, except for the weight of the edge between nodes B and C, which equals 9. First, we calculate the weighted degree of all the nodes and remove from the network all nodes with weighted degree <1 (specifically node E). We obtain the weighted 1-core. Subsequently, we recalculate the weighted degree of the left nodes in weighted 1-core, and remove all nodes with a weighted degree <2 (specifically node D). We obtain the weighted 2-core. Again, this procedure is repeated iteratively until there are only nodes with weighted degree no less than 3 left on the network, and so on. This routine is applied until there are no nodes left in the network.

Figure 3

Illustration of the Layered Structure of a Network Obtained Using the Weighted k-Core Decomposition Method.

The text at the bottom of the figure denotes the weighted degree of the nodes in the corresponding networks.

3.1 Research Questions

Our experiment aims at addressing the following research questions:

• What is the difference between the results of W_k-core and U_k-core when applied to PDNs? W_k-core is a weighted version of U_k-core. We wish to know the difference between the results of the two methods in the identification of important packages when applied to real PDNs.

• What is the relation between the results of weighted coreness and other centrality metrics when applied to PDNs? Many centrality metrics have been proposed to rank the importance of a node in a software network. Therefore, we wish to know the relation between the results of the weighted coreness and other centrality metrics in the identification of important packages.

• How about the effectiveness of the weighted coreness in identifying important packages when compared with other centrality metrics? As there are many centrality metrics, we wish to know whether the weighted coreness is better in effectiveness in the identification of important packages.

• Can W_k-core find meaningful important packages in the software systems? W_k-core ranks the packages according to the weighted coreness from large to small. We wish to know whether the ranked packages make sense to the developer.

In the following sections, we provide details on the objects of study (Section 3.2), our experiment process and results (Section 3.3), and our analysis of the results (Section 3.4).

When performing case studies with new techniques aimed at understanding a software system, there basically exist two paths to follow when trying to validate the results. One path is to perform an extrinsic evaluation, where, e.g., a controlled experiment would serve as an evaluator. Another path is the intrinsic evaluation, where persons such as the original developers and maintainers serve as an oracle. Thus, in the current work, Sections 3.4.1, 3.4.2, and 3.4.3 follow the first path, while Section 3.4.4 follows the second path.

3.2 Objects of Study

Six open-source nontrivial Java systems are chosen as objects of our study. Azureus 3.0.1.4^[1] is a well-known P2P file-sharing client. Tomcat 6.0.18^[2]2 is a web server and servlet container. JMeter 2.0.1^[3] is a desktop application designed to load test functional behavior and measure performance. JFreeChart 1.0.12^[4] is a free Java chart library. XGen Source Code Generator (XGen) 0.5.0^[5] is a tool that creates text output from structured text input. Jakarta ECS 1.4.2^[6] is a Java API for generating elements for various markup languages. The reasons for selecting these specific projects are as follows:

• Their source code is open and publicly available, allowing the replication of the experiment.

• They are implemented in Java programming language that can be analyzed by our analysis tool.

• They have ever been selected as research subjects [13, 23, 25]. Using the same subjects lays a basis for comparing our approach with others.

• They originate from different application domains allowing, to some extent, the generalization of the conclusions.

The size characteristics of the examined software systems are shown in Table 1, where KLOC is the thousand lines of code, #P is the number of packages, #C is the number of classes, and #F is the number of features. The term “feature” is used to designate fields and methods. #P excludes the outer packages, #C includes the number of inner classes and interfaces, and KLOC is the practical lines of code, excluding the comment lines and blank lines.

3.3 Experiment Process and Results

We follow the steps shown in Figure 1 to identify the important packages in a specific software system. The PDNs for all the subject systems are all automatically built by our own developed software analysis tool SNAT [23]. SNAT can parse the source code or compiled Java code of Java projects, extract the relevant information, build the CDNs, and finally build the PDNs.

For illustration purpose, we show in Figure 4A–D only the CDNs and their corresponding PDNs extracted from Azureus and Tomcat. Enlarging the corresponding networks can give you more information about the network such as the class (or package) each node denotes and the dependency between every pair of classes (or packages). The positions of the nodes in CDNs and PDNs are all calculated using the original circular algorithm in Pajek.^[7]

Figure 4

Illustration of the CDNs and PDNs for Azureus and Tomcat.

In (A) and (C), the nodes denote the classes, while in (B) and (D), the nodes denote the packages. The notes beside the nodes are the name of the corresponding software entity that the node denotes. The values on the edges in (B) and (D) are the coupling strength. Here, we omit the isolated nodes.

We summarize some detailed statistical properties of the PDNs built from the subject software systems in Table 2, where N_N is the number of nodes, N_E is the number of edges, <k> is the average degree of network nodes, d is the diameter, C is the clustering coefficient, L is the average path length, and H is the network heterogeneity. For our analysis from here on, if not stated otherwise, when we talk about the network, we refer to the largest connected component (LCC), and whenever we discuss network properties these are calculated from the LCC. The definition of these parameters can be found in [9].

3.4 Analysis of the Results

In this section, we analyze the obtained results aiming at answering the four research questions presented in Section 3.1.

3.4.2 What Is the Relation between the Results of Weighted Coreness and Other Centrality Metrics when Applied to PDNs?

Our method evaluates the package importance of a specific software system by giving a weighted coreness. The greater the value is, the more important the package is. This process is essentially a rank of the important packages, i.e., the greater the value is, the higher the ranking is.

In statistics, a rank correlation coefficient is always used to measure the degree of similarity between two rankings, and can be used to assess the significance of the relation between two rankings. Kendall’s τ coefficient is one of the most popular rank correlation statistics [14]. There are three ways to calculate Kendall’s τ, i.e., Tau-a τ_A, Tau-b τ_B, and Tau-c τ_C coefficients. As there are many nodes with the same weighted coreness making them have a same rank, we use the Tau-b coefficient in the current work.

Let (x₁, y₁), (x₂, y₂), …, (x_n, y_n) be a set of observations of the joint random variables X and Y, respectively. Any pair of observations (x_i, y_i) and (x_j, y_j) is said to be concordant if the ranks for both elements agree: that is, if both x_i > x_j and y_i > y_j or if both x_i < x_j and y_i < y_j. They are said to be discordant if x_i > x_j and y_i < y_j or if x_i < x_j and y_i > y_j. If x_i = x_j or y_i = y_j, the pair is neither concordant nor discordant and is said to be tied. Then, the Kendall’s Tau-b τ_B coefficient is defined as

(5)τB = nc − nd(n0 − n1)(n0 − n2), (5)

where n₀ = n(n – 1)/2, n₁ = Σ_it_i(t_i – 1)/2, n₂ = Σ_ju_j(u_j – 1)/2, n_c is the number of concordant pairs, n_d is the number of discordant pairs, t_i is the number of tied values in the i^th group of ties for the first quantity, and u_j is the number of tied values in the j^th group of ties for the second quantity.

Figure 5 shows the relation between the weighted coreness and other four widely used centrality metrics (i.e., betweenness centrality, closeness centrality, degree centrality, and original coreness for unweighted networks). Moreover, τ_B is used to measure their rank correlations (see Table 4). For simplicity, from now on, we will use wCoreness to denote weighted coreness for weighted networks and use uCoreness to denote the original coreness for unweighted networks. As we can see from Table 4, generally wCoreness is positively correlated with other centrality metrics except in xGen and ECS. Such an exception may result from the small size (number of packages) of xGen and ECS, as there are only 21 and 13 packages in XGen and ECS, respectively.

Figure 5

The Relations between wCoreness and Betweenness, Closeness, Degree, and uCoreness Centrality on the Six Networks.

Each data point denotes a node.

Table 4

Rank Correlation between wCoreness and Other Four Centrality Metrics Using Kendall’s Tau-b.

Subject	Betweenness Centrality	Closeness Centrality	Degree Centrality	uCoreness
Azureus 3.0.1.4	0.527**	0.533**	0.787**	0.795**
Tomcat 6.0.18	0.507**	0.354**	0.780**	0.805**
JMeter 2.0.1	0.530**	0.428**	0.723**	0.697**
JFreeChart 1.0.12	0.482**	0.642**	0.845**	0.823**
XGen 0.5.0	0.380	0.501*	0.573**	0.608**
Jakarta ECS 1.4.2	0.054	–0.173	–0.173	–4.0

**Correlation is significant at the 0.01 level (two-tailed). *Correlation is significant at the 0.05 level (two-tailed).

Furthermore, it can also be seen from Table 4 that in Azureus, wCoreness has the strongest correlation with uCoreness and the weakest correlation with betweenness centrality; in Tomcat, wCoreness has the strongest correlation with uCoreness and the weakest correlation with closeness centrality; in JMeter, wCoreness has the strongest correlation with degree centrality and the weakest correlation with closeness centrality; in JFreeChart, wCoreness has the strongest correlation with degree centrality and the weakest correlation with betweenness centrality; in XGen, wCoreness has the strongest correlation with uCoreness and has no significant correlation with betweenness centrality; and in ECS, there is no significant correlation between wCoreness and the other centrality metrics. It can clearly be seen that, in different software systems, the correlation strength between wCoreness and other centrality metrics changes. However, which centrality metric does wCoreness have strongest correlation with? To compare the correlation strength between weighted coreness and other centrality metrics, we introduce the Friedman test, which is widely used to compare the performance of different algorithms in problem solving [12]. In the current work, the smaller the ranking value is, the stronger the correlation strength is. Table 5 shows the ranking of correlation strength between wCoreness and other centrality metrics. As shown, wCoreness has the strongest positive correlation with uCoreness (rank last) and the weakest correlation with betweenness centrality (rank first). It means that the ranking results of wCoreness is most similar to that of uCoreness, and most dissimilar to that of betweenness centrality.

Table 5

Ranking of the Correlation Strength.

Kendall’s Tau-b Coefficient	Ranking
wCoreness vs. Betweenness centrality	3.666666666666666
wCoreness vs. Closeness centrality	3.249999999999996
wCoreness vs. Degree centrality	1.75
wCoreness vs. uCoreness	1.3333333333333335

3.4.3 How about the Effectiveness of the Weighted Coreness in Identifying Important Packages when Compared with Other Centrality Metrics?

To evaluate the effectiveness of wCoreness and other centrality metrics, we examined the spreading influence of the top-ranked nodes by applying the SIR model, which has been extensively used in network research on epidemic spreading, economic crisis spreading, and rumor spreading [7, 10, 21].

There are three states in the SIR model, i.e., susceptible S, infected I, and recovered R. The individuals in S are susceptible to (not yet infected with) the disease. The individuals in I have been infected with the disease and are able to spread the disease to susceptible individuals. The individuals in R have been infected and then recovered from the disease, and are not able to be infected again or to transmit the infection to others. However, in the SIR model, the susceptible neighbors of an infected individual usually get infected with a fixed probability. As the PDN is a weight network, we introduced a probability that depends on the weight of the edges. Such a setting of the infection probability is very similar to that which has ever been introduced to simulate the spreading of an economic crisis [10]. It can be calculated by

(6)pij ∝ m ⋅ wij/∑iwij, (6)

where p_ij denotes the probability that infected node i infects its susceptible neighboring node j, w_ij is the weight on the edge between node i and node j, and m is an amplification parameter that determines the strength of the disease and can obtain any positive value. In software systems, the disease can be viewed as the error (or fault/defect).

Here, we will also introduce a variant of the SIR model that takes into account the weight of the edges that mediate the spreading [10]. Initially, we assign all nodes to be S. Then, the node that we want to investigate its influence is chosen and set to be I. This node will infect all its susceptible neighbors with probability p calculated according to formula (6), changing all the newly infected nodes from status S to I and the node that initiated the process to R. In the consecutive steps, such a process will be repeated, and all the infected nodes will infect their susceptible neighbors. The process stops when there is no infected node left.

For each selected node, we performed 1000 independent realizations of the variant version of the SIR model, and we calculated the average number of infected nodes. The number of infected nodes is used as a score to rank the importance of nodes. In the current work, we consider the values of m in different intervals for different software systems, i.e., for Azureus m ∈ [2, 10], for Tomcat m ∈ [15, 30], for JMeter m ∈ [15, 18], for JFreeChart m ∈ [1, 2.5], for XGen m ∈ [4, 10], and for Jakarta ECS m ∈ [1, 9].

Figure 6 shows that the number of infected nodes changes with the m. Here, the number of infected nodes is averaged over the top-n^W nodes ranked by each centrality metrics. The n^W for each system is shown in Table 3. It should be noticed that as n^U > n^W, the number of infected nodes of uCoreness is averaged over 1000 independent samplings of the nodes in the main core obtained by U_k-core. From Figure 6, we can see that, in general, the number of infected nodes grows with the increase of m. As m determines the strength of the error, with the increase of the error strength its influence potential also increases. We also observed that the nodes ranked by wCoreness are more able to initiate a severe outbreak in comparison with the nodes ranked by other four centrality metrics. The results are robust for all networks used in this study and for different values of m. It means that W_k-core can find the most influential nodes.

Figure 6

The Number of Infected Nodes Changes with the m.