Historical biogeography of Eastern Asian–Eastern North American disjunct Melaphidina aphids (Hemiptera: Aphididae: Eriosomatinae) on Rhus hosts (Anacardiaceae)

JOURNAL OF SOFTWARE: EVOLUTION AND PROCESS J. Softw. Evol. and Proc. 2016; 28:340–371 Published online 5 April 2016 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/smr.1774

Testing the theory of relative dependency from an evolutionary perspective: higher dependencies concentration in smaller modules over the lifetime of software products Yixin Bian1, Mohammed Aziz Parande2, Gunes Koru3 and Song Zhao1,*,† 1

College of Computer Science and Information Engineering, Harbin Normal University, Harbin 150025, China 2 Microsoft Corporation, Seattle, WA USA 3 Department of Information Systems, UMBC, Baltimore, MD 21250, USA

ABSTRACT Recent studies conducted on the single releases of multiple software products showed that dependencies concentrate on smaller modules, that is, smaller modules have more dependencies per source line of code. This phenomenon, called the Theory of Relative Dependency, explains why some earlier studies reported that smaller modules were proportionally more defect prone. It is important to test the Theory of Relative Dependency from multiple perspectives so that it can be used as an explanatory argument when garnering organizational support to give a higher quality assurance (QA) priority to smaller modules. In this study, we test the validity of this theory from an evolutionary perspective by examining the consecutive releases of a number of software products. Dependencies do concentrate over smaller modules regardless of the product age. Furthermore, continuous refactoring efforts are associated with increasing concentration of dependencies on smaller modules over product lifetime. Based on the consistent results, software managers and developers should consider giving a higher QA priority to smaller modules over the lifetime of a software product. In the projects where refactoring is adopted continuously, the QA priority on smaller modules should be further increased as the software product ages. Copyright © 2016 John Wiley & Sons, Ltd. Received 13 May 2015; Revised 21 February 2016; Accepted 23 February 2016 KEY WORDS:

software quality; software metrics; refactoring

1. INTRODUCTION Recent research results from multiple software products have reported that smaller modules have proportionally (per source line of code) more dependencies. This phenomenon, which is about an unequal concentration of dependencies with respect to module size, is called the Theory of Relative Dependency [1]. This theory serves as an explanatory mechanism behind the recent observations about a higher concentration of defects in smaller modules [2, 3] because of the consistently validated positive relationship between the dependencies and defect proneness of software modules [4–11]. While quality assurance (QA) resources, often limited in software projects, can be allocated to software modules based on their business importance or operational profiles, such prioritization decisions could also benefit from incorporating what has been learned in empirical software engineering research related to the structural characteristics and relative dependencies, and relative defect proneness of software modules, further improving software quality. The explanatory aspect of the Theory of Relative Dependency can be used by change agents in software organizations when making evidence-based arguments that smaller modules deserve higher levels of QA attention such as prioritized and focused source code inspections. In *Correspondence to: Song Zhao, College of Computer Science and Information Engineering, Harbin Normal University, Harbin 150025, China. † E-mail: [email protected] Copyright © 2016 John Wiley & Sons, Ltd.

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 341

knowledge organizations, successful change management requires obtaining the support and involvement of knowledge workers [12]. The attitudes and behaviors of software practitioners, who are knowledge workers, toward change will be more positive if they know the underlying reasons [13, 14]. Therefore, it becomes critical to thoroughly understand, investigate, and extend the evidence base supporting the Theory of Relative Dependency, which have been the specific aim and contribution of the research study whose results are reported in this paper. In the development of scientific knowledge, empirical testing and validation of theories plays an essential role [15]. The results from multiple studies can either increase our confidence in the earlier findings or lead to different explanations or research directions. Such a need has been expressed for software engineering [16] in order to be able to build a reliable empirical body of knowledge. Testing and validation studies can focus on the same conditions or take different perspectives to study relevant but different settings under which the earlier findings could still hold [17]. It can be noted that the recent results about the concentration of dependencies on smaller modules [1] were obtained from the single releases of software products. On the other hand, a software product under use evolves continuously to adapt to the changing environments and requirements [18]. Software evolution typically involves changes in the structure of software. For example, MacCormack et al. [19] analyzed the module dependencies for the successive versions of the Linux kernel; their data showed a rapid increase in the total number of dependencies over time as well as changes in product size. Therefore, from an evolutionary perspective, it becomes important to longitudinally investigate the aforementioned unequal concentration of dependencies with respect to module size by examining the consecutive releases of various software products. The following important research questions arise when the Theory of Relative Dependency is viewed from an evolutionary perspective: • Q1: Does the unequal concentration of dependencies with respect to module size always exist regardless of a product’s age? • Q2: How does the unequal concentration of dependencies with respect to module size change? Does it remain at the same levels, increase, or decrease over time? • Q3: Because structural improvements are necessary for long-lived software products, how is the adoption of refactoring as a project practice associated with the concentration inequality over successive software releases? The preceding questions are important because if software managers and developers know the answers, they can make better decisions about how to manage and allocate their limited QA resources effectively and efficiently. If the empirical evidence shows that dependency concentration on smaller modules changes and, say, increases over time, appropriate decisions can be made to increase the relative QA emphasis on smaller modules as a product ages. A similar decision can be considered for the projects adopting refactoring as an essential and continuous practice if, as suggested in [1], refactoring is associated with an increase in the concentration of dependencies on smaller modules. A previous workshop paper [20] reported our initial results of the first and second questions listed previously based on the data from successive software releases of one software product (KOffice). The final results reported in this paper are much more comprehensive because they come from the completed study that investigated all three research questions by measuring and analyzing the data from the consecutive releases of 20 large-scale software products, which have been in use for a long time period and undergone considerable evolution. These products cover a broad range of systems such as database systems, customer relationship management systems, content management software and so on. In the rest of the paper, we start by summarizing the related studies. Then, we discuss the methods adopted in this study. After that, we present our analysis results. Finally, we discuss the implications of our results and conclude the paper.

2. RELATED WORK 2.1. Software evolution Evolution is an inevitable trend [21] for software products under use. This trend includes improvement and adaptation to the changing environment, loss of undesired properties, and development of new Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

342

YIXIN BIAN ET AL.

ones [18]. In a series of studies performed by Belady and Lehman during the years from 1970 through 1975, 25 releases of the OS/360 IBM mainline operating system were analyzed [22, 23]. A substantial growth in the size of OS/360 was observed within a period of 3 to 4 years. A similar growth was observed for many systems including Windows, UNIX, and Netscape browser [23]. The growth of software systems can be slow at times, but there is a constant change over a long period [24, 25]. We also know that unless some work is done for the improvement, the overall structural quality of a software product deteriorates as it ages [18]. Hence, overall maintenance efforts spent per unit time typically increasing as a software product evolves [23–27]. 2.2. Module dependencies in evolving software As software grows, the number of modules and the dependencies among software modules increase. Often, some work needs to be done in order to reduce the dependencies [18, 23, 24, 28, 29]. It is beneficial to remove unwanted excess dependencies in order to reduce complexity and maintain a software system efficiently and effectively. Refactoring is used to change the design of an existing software system to improve its quality, especially its maintainability, extensibility, and reusability, while preserving its functionality [30]. Along with its other benefits [31–35], refactoring helps in improving the overall code quality and architecture by eliminating or reducing dependencies. Kim et al. showed that refactored modules experienced higher reduction in the number of inter-module dependencies after the quantitative analysis of Windows 7 version history [36]. Refactoring is an inherent and unavoidable activity in the software projects that produce long-lived software products serving useful business purposes [1]. Both continuous and intermittent refactoring activities can be performed in such projects. Typically, if refactoring is performed continuously, there are smaller structural improvements over time. Otherwise, it is necessary to apply relatively bigger structural improvements intermittently. For example, MacCormack et al. compared two different versions of the Mozilla browser: one right before a major refactoring initiative and another right after it [37]. The researchers concluded that the restructuring initiative reduced the overall dependencies and made the Mozilla browser more modular. Generally speaking, maintenance is more difficult in large software systems that include several modules interacting with each other resulting in dependencies. In a study conducted by MacCormack et al. [19], on component modularity, the authors hypothesized that dependency relationships would change for consecutive releases of a software system. After analyzing module dependency data from several versions of the Linux kernel, they reported that total dependencies increased rapidly. An increase in the number of dependencies is considered to be an increase in complexity for software modules [4, 24, 38, 39]. Many studies associated module dependencies with change proneness and defect proneness for software modules (e.g., [1, 40–43]). 2.3. Size-dependency relationship for software modules Koru and El Emam [1] conducted an empirical study to understand the functional form of the relationship between size and dependency for software modules. The authors collected data from 14 open source software (OSS) products, and extracted size and dependency metrics from the last available stable release for each product. They produced concentration curves and indexes to demonstrate the concentration of dependency with respect to size. For all products, their plots showed that dependency is concentrated more in smaller modules. That is, smaller modules are proportionally (per line of code) more dependent on other modules compared with larger ones. This phenomenon, called the Theory of Relative Dependency, suggests that in large-scale systems smaller modules are proportionally more dependent compared with larger ones [1]. This theory explains and solidifies the authors’ earlier findings about the concentration of defects in smaller modules [2, 3]. Size, because of its significance, has been used as an adjustment factor when evaluating quality (e.g. defect density measures), and it needs to be incorporated in quality prediction models because of its significant confounding effect [44, 45]. However, the functional form of the crucial relationship between size and defect proneness for software modules (henceforth, size-defect relationship) has not been well investigated or understood before our early research [2]. In that research, we found Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 343

that the concentration of defects in smaller modules (Theory of relative defect proneness) by collecting and analyzing module-level size and defect data from 10 open-source software products. Now, this study explains and solidifies our earlier findings about the concentration of defects in smaller modules from an evolutionary perspective by examining the consecutive releases of a large number of software projects. A recent literature [46] revaluated the Theory of Relative Defect-proneness, and their findings generally agree with the results of our previous research [2]. They found that this relationship, which is defect density decreases as module size increases, holds in medium and largesized modules, while defect density increases in small modules as module size increases. Although many studies confirmed that there was indeed a correlation between change coupling (dependency) and defects [42, 47, 48], in order to predict failure-prone software components, only dependency information is not enough. For example, literature [49] predicted post-release defect proneness using development history and dependency information. So the change trend of dependency density is not equal to the one of defect density. Our current work focuses on exploring the size–dependency relationship from an evolutionary perspective, and our finding is that dependency density always decreases as file size increases. In literature [1], the authors identified an isolated restructuring effort, which affected most of the system for one of the products. The concentration of coupling over smaller modules increased after this restructuring effort. This initial observation points to the possibility that continuous refactoring activities performed during the life of a product can result in the increase of dependency concentration in small modules. Therefore, taking an evolutionary perspective becomes important to test such a possibility because it would affect various decisions about the prioritization of QA activities. At the earlier stages of this study, Parande and Koru [20] investigated the concentration of dependencies with respect to module size from a longitudinal perspective for an OSS product, KOffice. This paper builds upon the experience and results obtained in [20], and it brings substantially more evidence obtained from other software products.

3. METHODS 3.1. Data sources Because of the empirical nature of our investigation, we collected module size and dependency data from long-lived and active OSS projects. Because the source code for the studied products is publicly available, this study is repeatable, and its results are reproducible. We excluded small or short-lived products because the analysis conducted on their data is more likely to be affected by intermittent data fluctuations. Although the Theory of Relative Dependency [1] was originally stated for large-scale products, because of the nature of this study, we examined the snapshots corresponding to consecutive releases over which some products grew from medium to large in size. We determined many long-lived software products written in C++ and Java from the Open Hub (formerly Ohloh) website (https://www.openhub.net/) as candidates. We chose these two languages because of their prominence as mature object-oriented languages among long-lived software products. For each candidate, we obtained high-level statistical information from the Open Hub website about product size and source-code commit history. To be able to obtain meaningful research results, we used the following criteria in product selection: 1. Having at least approximately 5 KSLOC and 10 KSLOC release sizes for the first and current releases, respectively. 2. Having at least 3 years of developments and source control history. 3. Still being developed by an active community and having an increasing development effort over years as indicated in the commit logs. Table I shows the 20 selected software products whose module size and dependency data are collected and analyzed in this study. It can be noted that the selected products show variation in terms of their functionality and application domains. For the selected products, the source codes for Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

344

YIXIN BIAN ET AL.

Table I. Software products included in the study. Product name Number of releases Main language Ant Audacity Avida Celestia Cmake Exult Findbugs Groovy Hipergate HSQL Hydrogen Jajuk Jaxen Kmeleon Lenya Pluto Qbittorrent Shareaza Tellico Vuze

34 19 21 17 28 21 7 9 9 7 6 69 16 6 19 10 44 23 47 31

Java C++ C++ C++ C++ C++ Java Java Java Java C++ Java Java C++ Java Java C++ C++ C++ Java

Website

Functionality

http://ant.apache.org http://audacity.sourceforge.net http://avida.devosoft.org http://celestia.sourceforge.net http://cmake.org http://exult.sourceforge.net http://findbugs.sourceforge.net http://groovy.codehaus.org http://www.hipergate.org http://hsqldb.org http://hydrogen-music.org http://www.jajuk.info http://jaxen.codehaus.org http://kmeleon.sourceforge.net http://lenya.apache.org http://portals.apache.org/pluto http://www.qbittorrent.org http://shareaza.sourceforge.net http://tellico-project.org http://vuze.com

Build tool Sound recording and editing Biocomputing Space simulation Cross-platform build tool Game engine Static code analysis Dynamic Language Customer relationships HyperSQL database Drum machine Advanced jukebox XPath library Lightweight web browser Content management Portlet container Torrent downloading P2P client Collection manager Bittorent application

all releases of the selected products were analyzed and measured. The data for each release were collected and analyzed separately as discussed next. 3.2. The representativeness and diversity of data sources In order to test individual hypothesis or evaluate individual tools in software engineering, there are multiple open-source projects available. However, more is not necessarily better and the selection of projects does count as well [50]. In this paper, we select the technology provided in literature [50] to test diversity of the projects. There are 20 projects in this paper, and 12 of them belong to Ohloh universe in literature [50]. Table II shows the representativeness of these collection systems by applying the outcomes of literature [50]. As shown in Table II, 7 out of 10 Java projects (Ant, Findbugs, Groovy, Hipergate, Jajuk, Lenya, and Pluto) were present in their Java universe and 5 projects (Audacity, Cmake, Hydrogen, Sahreaza and Tellico) were present in their C++ universe. The similarities between the C++ and Java projects Table II. The representativeness of 12 projects selected in this paper. Product name

Score Total lines of code (%) (%)

Ant Findbugs Groovy Hipergate Jajuk Lenya Pluto Audacity Cmake Hydrogen Shareaza Tellico

1.43 0.59 0.57 0.39 0.87 0.06 0.28 1.41 0.40 0.74 0.81 1.07

20.73 18.92 20.01 19.00 27.44 10.98 24.26 23.13 11.13 26.24 13.01 26.76

Contributors (12 months) (%)

Commits (12 months) (%)

90.71 85.39 21.52 79.96 85.39 93.75 79.96 59.08 6.10 93.75 79.96 90.71

33.49 16.07 10.25 36.02 29.06 39.58 15.05 30.27 4.04 28.81 36.08 29.33

Project age Project activity (%) (%) 20.39 20.39 20.39 23.36 20.39 20.39 20.39 20.39 20.39 23.36 20.39 20.39

32.86 40.16 26.96 40.16 40.16 26.96 32.86 32.86 40.16 40.16 32.86 40.16

The universe is the active Ohloh projects (the space is total lines of code, contributors, commits, project age, and project activity). Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 345

are as follows: First, the diversity of the seven Java projects is 4.19% and the five projects together cover 4.42% of the C++ universe diversity. Second, the maximum of one of the dimension, total lines of code, is 27.44%, which shows that the 12 projects having at least approximately 5 KSLOC and 10 KSLOC release sizes for the first and current releases, respectively. Third, the maximum of contributors is 93.75%, which presents that the 12 projects are still developed by an active community. Fourth, the maximum of commits is 39.58%, which presents that the 12 projects have an increasing development effort over years as indicated in the commit logs. Fifth, the score of the project age of all projects (C++ and Java) are more than 20.39%, which presents again the 12 projects selected in this research having at least 3 years of developments and source control history. The difference between the C++ and Java projects is that the minimum of project activity is 26.96%, which means that there were 25% more commits than in the prior 12 months in two of Java projects while there were less than or equal to 25% commits than in the prior 12 months in the five C++ projects. 3.3. Software metrics All of the products studied are object-oriented products. In object oriented analysis, design, and programming, classes serve as the main instruments of modularizing source code. Therefore, classes were accepted as modules and used as the unit of observation and measurement for this empirical study. UNDERSTAND [51], a source code analysis tool, was used to obtain size and dependency measurements at the class level. The following three metrics were used in this study: 1. Coupling Between Objects (CBO) 2. Depth of Inheritance Tree (DIT) 3. Source Lines of Code (SLOC) Coupling Between Objects (CBO) and DIT were used as measures of dependency; SLOC was used as a measure of size. CBO, DIT, and SLOC metrics have been widely used and validated in software engineering research [44, 52–54]. Modules with a high frequency of outgoing coupling dependencies (export coupling) may have a greater chance to cause surrounding dependent modules to become faulty [55]. Giger et al. [56] found that outgoing connections of the dependency graph are more related to bugs than incoming connections, and they find evidence that outgoing dependencies (i.e., method invocations) are indicators for the change proneness of a method and class, respectively. 3.3.1. Coupling Between Objects. For any class x, CBO is the count of other classes to which x is coupled (depends on). When x references the variables or calls the methods of another class, y, in order to achieve its own functionality, we say that x depends on y, or coupled to y [44, 52, 57]. This access (or reference) of x to y increments the CBO of x by 1. When calculating the CBO, only the application classes are considered; library calls (e.g., calls to a String object in Java), constant references, and interface implementations are not considered as coupling. Higher values of CBO might be associated with missed opportunities for effective reuse and inheritance [53, 57]. Classes with higher CBO values are typically more difficult to be understood, tested, and reused in other applications. A number of studies presented CBO as an important dependency metric [1, 2, 20, 44, 58]. 3.3.2. Depth of Inheritance. The depth of a class within an inheritance hierarchy is the maximum length from the class node to the root node. It is the level of the class in the hierarchy where the base class is at Level 1 [52]. A class is at level n if it has n-1 super classes. Inheritance is an important mechanism in object-oriented programming; however, it also results in the dependency of the child classes to their parents. In object-oriented programming, classes are considered to be logically cohesive development units, or modules, organized in an inheritance hierarchy. So we must consider DIT to better understand class dependencies. Indeed, Chidamber and his colleagues stated that DIT is a measure of how many ancestral classes can potentially affect this class, which exactly describes the dependencies of a child class to its ancestors. For this reason, it was reported that higher DIT is associated with higher levels of defect proneness for classes [59–61]. Many research studies used DIT as a measure of dependency (e.g., [1, 2, 20, 44, 58]). Recently, a study Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

346

YIXIN BIAN ET AL.

presented a contradictive conclusion that DIT was not suitable for predicting defect proneness [62]. Ahmet Okutan and Olcay Taner supported that DIT indicates the maximum length of a path from a class to the root class in an inheritance tree and is not a good indicator for both size and complexity, because the parent–child relationship does not contribute to the complexity if there is no caller– callee relationship between them, which is the case for most of the time. So DIT is not the best choice for defect prediction [63]. However, Gordon et al. pointed out some issues result from invisible dependencies between parent and child classes. A child cannot then be tested without its parent class because errors in behavior might easily propagate down the inheritance tree [64]. Therefore, DIT is an effective metrics on dependency, and there are many studies associated module dependencies with change proneness and defect proneness for software modules. In DIT, the deeper a class in the tree, the higher the number of methods that can be inherited; this makes its behavior more complex, more difficult to predict. So it would be advisable to focus the QA attention on the complex modules. According to our findings in this paper, dependencies concentrate on smaller modules. Therefore, a higher QA priority to smaller modules with limited amount of resources in software projects. 3.3.3. Source Lines of Code. While there is no perfect measure for software size, SLOC has been consistently used and validated in the software engineering literature because of its significant relationship with effort (e.g. [65]), change proneness (e.g., [40]), and defect proneness (e.g., [66]). Therefore, SLOC was used as the size measure in this study. The measurement tool, Understand for C++ [51], excluded the blank and comment lines while taking the measurements. 3.4. Measuring the concentration of dependencies with respect to module size 3.4.1. Concentration curve and concentration index. Concentration curve [67] is a tool used to visualize the concentration inequality of one variable with respect to another (e.g., Figure 1). The curve is obtained by tick marking the cumulative percentage of x along the x-axis for unique x values ordered from smallest to largest, from left to right; identifying the corresponding cumulative percentage of ys on the y-axis; and finally, placing dots on the x–y plane and connecting them. Simple statistical plotting tools can be used to produce these plots automatically. Concentration index, derived from the concentration curve, is a frequently used metric as a measure of concentration inequality [67, 68]. The concentration index is adopted in this study because it is an appropriate metric to quantify the concentration inequality of module dependencies with respect to module size. Generally, concentration index quantifies the concentration level of one variable with respect to another. Often denoted using C, concentration index is obtained after plotting the related concentration curve. By definition [68], concentration index (C), which measures the magnitude of concentration inequality, is twice as much as the area between the concentration curve and the equality line (also known as diagonal or 45o line). In our research, when a concentration curve, C, hovers above the concentration equality line (diagonal), C gets closer to zero meaning that dependencies are equally 1

1 Concentration equality line First Release Last Release

0.9

0.9

0.8

0.8

0.7

0.7

0.6

0.6

0.5

0.5

0.4

0.4

0.3

0.3

0.2

0.2

0.1

0.1

0

0

0.1

0.2

0.3

0.4

0.5

0.6

(a) CBO

0.7

0.8

0.9

1

0

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

(b) DIT

Figure 1. Concentration curves for Avida. Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 347

concentrated in smaller and larger modules. C < 0 means a higher concentration of dependencies in larger modules; C > 0 means a higher concentration of dependencies in smaller modules. And the greater the value of C is the higher dependencies concentrate in smaller modules. Drawing a concentration curve can result in areas both above and below the equality line. In calculating the area, different signs (positive and negative) are assigned to the areas above and below the equality line. When there is perfect concentration equality, the curve becomes aligned with the equality line, and C becomes zero. Because C is obtained from a sample, a point estimate and its 95% confidence interval can be obtained for C. The method to calculate the confidence interval can be found in [68]. Concentration curve is a generalization of the Lorenz curve, which is a graphical representation of the proportionality of a distribution and the corresponding concentration coefficient is a generalization of the Gini index. The Lorenz curve and the Gini index both have been used in the research domain of software engineering [69–71]. Additional discussion about the use of concentration curves and indices within the context of software engineering can be found in [1–3] along with some examples. In this paper, we use concentration curves and indexes to assess and quantify the concentration of dependencies on smaller modules. The cumulative percentages of size are represented on the x-axis; the cumulative percentage of dependencies is represented on the y-axis. For each release of each product, the unique size values are sorted along the x-axis from left to right, smallest to largest, and the cumulative size percentages corresponding to them are marked on the x-axis. For each marking on the x-axis, the corresponding y value is marked by calculating the cumulative dependency. The intersections of x and y values produce concentration curves. We draw two concentration curves for each product: one using CBO and SLOC, the other using DIT and SLOC. Then, we calculate two concentration index values, CCBO and CDIT, respectively. This process is repeated for each successive release for every product studied to observe the evolutionary progress of dependency concentration. 3.5. Understanding the adoption of refactoring In our investigation of Q3, we needed to know whether the selected projects adopted refactoring as a continuous practice. In an earlier study [1], there was limited evidence showing that an isolated refactoring activity slightly increased the concentration of dependencies on smaller modules. According to this initial finding, the projects where refactoring is adopted as a continuous practice would be more likely to show an increasing concentration of dependencies in smaller modules over their lifetime. We took a qualitative approach to methodically investigate whether refactoring was adopted as a practice in an ongoing manner in the selected projects. A qualitative approach was preferred because it was not feasible to detect and count all of the individual source code changes applied for refactoring purposes to obtain quantitative data. Because there were no dependencies between the qualitative and quantitative (obtaining metrics, measuring concentration inequality, etc.) tasks of the study, we were able to perform them separately in parallel. Triangulation of the qualitative data obtained from different sources was preferred because it allows cross-checking the evidence obtained [72]. Therefore, qualitative data was obtained from multiple sources to understand refactoring was adopted as a continuous practice: First, we identified and contacted the main developers, that is, the most active and experienced developers in their projects. Second, we examined the public change logs and source code commit messages stored in the project source code repositories. Third, we reviewed the project history, plans, and roadmaps posted on the project website. For all projects, we were able to obtain data in two ways: one is from the main developers and the other is to read the change logs, project plans, and the commit messages over the life of the project. In order to cross-check the accuracy of the developers’ reports, we compared them with the evidence obtained from other sources. After a lot of efforts for selecting skilled developers, we contracted the main developers of the projects who are familiar with or have good experiences in the history of the projects. The information was obtained via email. We sent 15 emails1 and a total of nine responses were received, giving a response rate of 60%. Two responses were repeated and two were invalid 1 The question sent to the developers:Dear Sir/Madam,In my research, I have identified that some versions in Cmake have been refactored. However, we do not know which version have been refactored and which not? Your opinion helped me identify the versions which experienced refactoring.Thanks to you for your attention and time.

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

348

YIXIN BIAN ET AL.

for they did not provide valid refactoring/restructuring information. Thus, the remaining six answers formed the basis of the analysis. The information was obtained via email exchanges including data in plain text format whose interpretation was straightforward and required no coding or further analysis. Because these developers were intimately familiar with the history of the projects, the information obtained from them is often highly relevant and accurate. For additional validation, we also used an automated tool, Ref-Finder [73] to detect the traces of refactoring activities from one release to another.

4. RESULTS 4.1. Q1: Unequal concentration of dependencies with respect to module size over product lifetime The concentration curves for all releases of all products rise above the concentration equality line (diagonal), which indicates a higher concentration of dependencies in smaller modules over the lifetime of the products. Because of space considerations, such concentration curves are shown for one of the products, Avida, in Figure 1. Only the curves for the first and last releases are shown to prevent the plots from being obstructed by many lines. Table VI (Appendix) shows the point estimates and 95% confidence intervals for CCBO and CDIT: The point estimates for all releases of all products are positive, indicating a higher concentration of dependencies in smaller modules. Except for the CCBO in some earlier releases of Celestia, Pluto, and Hydrogen, the 95% confidence intervals for both CCBO and CDIT also fall above zero in all releases of all products. In the later releases of those products, the 95% confidence intervals were also above zero. Our results for Q1 generally validate the results obtained in our earlier study from KOffice [20]. Therefore, according to the evidence in this study, we can state the following: 1. Smaller modules are proportionally more dependent on other modules. 2. This unequal concentration of dependencies with respect to module size exists over the lifetime of a product. 4.2. Q2: Changes in unequal concentration of dependencies with respect to module size For each product, we plotted CCBO and CDIT over successive releases. One such plot produced for Avida can be seen in Figure 2, where the increase in the concentration metrics is clearly visible over time. However, such an increasing trend was not observed for all products. Table III shows the CCBO and CDIT values for

Figure 2. Concentration index values for CBO and DIT of Avida, CCBO and CDIT, respectively. CBO, Coupling Between Objects; DIT, Depth of Inheritance Tree. Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 349

Table III. Comparing first and last releases of the open-source software products. Products

First release

Last release

Total CBO CCBOTotal DIT CDIT Classes SLOC Total CBO CCBO Total DIT CDIT Classes SLOC Ant 236 FindBugs 5,411 Groovy 1,813 Hipergate 579 HSQL 191 Jajuk 807 Jaxen 528 Lenya 1,128 Pluto 814 Vuze 18,707 Audacity 112 Avida 280 Celestia 157 Cmake 573 Exult 170 Hydrogen 611 Kmeleon 146 Qbittorrent 128 Shareaza 3,694 Tellico 860

0.40 0.28 0.53 0.33 0.17 0.30 0.18 0.24 0.11 0.33 0.48 0.17 0.12 0.37 0.45 0.06 0.08 0.29 0.12 0.23

206 2,162 1,016 354 69 285 323 665 374 5,338 18 21 9 96 45 117 40 18 513 125

0.51 110 8,244 4,485 0.22 0.60 1,245 83,048 7,747 0.25 0.81 590 68,949 5,198 0.48 0.63 209 25,823 2,557 0.31 0.51 55 14,159 1,802 0.28 0.55 176 12,254 4,589 0.33 0.60 169 8,791 622 0.26 0.56 364 24,901. 2,871 0.18 0.53 233 15,525 828 0.10 0.70 4130 320,610 31,311 0.36 0.65 29 4,707 2,717 0.35 0.51 69 8,645 3,595 0.58 0.64 56 5,943 2,104 0.24 0.62 124 19,063 2,375 0.39 0.72 72 5,756 2,698 0.33 0.57 112 16,680 1,017 0.11 0.50 45 6,739 487 0.17 0.66 18 4,321 601 0.20 0.45 398 116,937 3,629 0.18 0.55 104 16,640 160 2,726

2,674 2736 2,791 1,100 485 1,334 335 1,279 447 8,271 393 427 428 445 714 163 146 85 812 400

0.61 0.61 0.80 0.68 0.69 0.62 0.65 0.52 0.60 0.72 0.66 0.89 0.76 0.72 0.72 0.59 0.63 0.63 0.53 0.54

1,180 1,529 1,282 667 320 793 178 524 268 6,632 406 605 452 361 473 149 144 88 523 336

106,346 110,031 123,925 109,831 66,770 50,550 11,495 36,281 17,885 544,611 78,875 58,518 58,216 86,559 67,160 29,288 21,506 18,450 162,003 44,135

CBO, Coupling Between Objects; DIT, Depth of Inheritance Tree; SLOC, Source Lines of Code.

the first and last releases for all the products. For some products, one of the two metrics decreased while the other increased or they stayed at about the same levels for some others. In an earlier study [1], we had observed that an isolated refactoring activity increased the concentration of dependencies in smaller modules. Therefore, we further explored whether the refactoring practices in the selected projects can be associated with certain patterns of changes in CCBO and CDIT. 4.3. Q3: Relationship with Refactoring As a result of our qualitative investigation process explained in Section 5, we learned that, in Avida, Celestia, Cmake, HSQL, Hydrogen, Shareaza, and Vuze, refactoring was applied continuously together with the other development and maintenance activities. For example, the developers of HSQL indicated that restructuring has been performed all the time. This information was supported by the evidence from the developers’ change/release logs as well as the Ref-Finder results (Table IV2). Another product, Avida, also experienced continuous refactoring. The change log of Avida showed that Avida was actively developed and refactored: The Avida 2.x series was in the process of refactoring and evolution in preparation for a shift to Avida 3.0. The structure and architecture of Avida had been redesigned and would begin to gradually take shape.3 The refactoring information of the other products where refactoring was adopted continuously was shown in Table VII in the Appendix. For the other projects, the developers indicated that refactoring took place intermittently as developers found an opportunity for refactoring. The projects, Tellico, Lenya, Audacity, Ant, and Findbugs were applied intermittent refactoring. For example, the change log of Lenya showed that there were a few refactoring activities in its version 1.2 and 2.0. These log information can be checked in Table VIII in the Appendix. The results obtained from the tool, Ref-Finder, are consistent with the change log (Table IV). 2 According to the website of Lenya: http://lenya.apache.org/index/roadmap.html#releases. Major releases are used for Feature/RC/Alpha, for example, 2.0 and minor releases, are used for bug fixes, for example, 1.2.2. In addition, it is possible that there are new features and bug fixing in the version RC/Alpha shown in Table IV. For example, the product Lenya 2.0 was labeled feature, but there are bug fixing in this release according to its changes index, http://lenya. apache.org/index/changes/2007/12.html. For example, the following information comes from the website, http://lenya. apache.org/index/changes/ 2007/12.html.‘007-12-20 2.0 use servlet helper to obtain webapp URL from request. This should fix bug 44111’ 3 http://programerror.com/software/avida/

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

350

YIXIN BIAN ET AL.

Table IV. The number of refactoring detected with Ref-Finder for the projects written in Java where refactoring is adopted continuously. Product

Release type

Release no

Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant HSQL HSQL HSQL HSQL HSQL HSQL Groovy Groovy Groovy Groovy Groovy Groovy Findbugs Findbugs Findbugs Findbugs Findbugs Findbugs Hipergate Hipergate Hipergate Hipergate Hipergate Hipergate Hipergate Pluto Pluto Pluto Pluto Pluto Pluto Pluto Pluto Pluto Lenya Lenya Lenya Lenya Lenya Lenya Lenya

Feature Feature Feature Feature Bug Bug Bug Bug Bug Feature Bug Bug Bug Bug Bug Feature Bug Feature Feature Feature Bug Bug Bug Feature Feature Feature Feature Bug Feature Bug Feature Feature Bug Fix Bug Fix Bug Fix Bug Fix Feature Feature Feature Feature Feature Feature Feature Feature Feature Bug Bug Bug Bug Bug Bug Feature RC RC RC Feature Bug Bug Bug

1.1 1.2 1.3 1.4 1.4.1 1.5.1 1.5.2 1.5.3 1.5.4 1.6.0 1.6.1 1.6.2 1.6.3 1.6.4 1.6.5 1.7.0 1.7.1 1.8.0 1.6.1 1.7.0 1.7.1 1.7.2.11 1.7.3.3 1.8.0.10 1.0 1.5.8 1.6.8 1.6.9 1.7.3 1.7.4 1.2.1 1.3.4 1.3.5 1.3.6 1.3.7 1.3.8 1.0.5 1.1.0 2.0.17 2.1.20 3.0.40 4.0.12 4.0.14 1.0.1 1.1.0 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6 1.1.7 2.0.1 1.2rc1 1.2rc2 1.2rc3 1.2 1.2.1 1.2.2 1.2.3

Number of detected refactoring 354 23 108 10 0 23 0 0 72 4 16 63 2 0 372 122 100 19 825 60 40 11 25 64 24 940 7 560 35 135 667 371 14 94 162 n/a 7 2 10 31 29 1 n/a 1 n/a 0 0 0 0 0 0 0 9 54 4 47 5 16 2 (Continues)

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 351

Table IV. (Continued) Product

Release type

Release no

Number of detected refactoring

Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jaxen Jaxen Jaxen Jaxen Jaxen Jaxen Jaxen Jaxen

Bug Bug Alpha Feature RC RC RC RC RC RC Feature Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Feature Bug Bug Feature Feature Feature Feature Feature RC Beta Beta Beta Beta Beta Beta Feature

1.2.4 1.2.5 1.4aplha1 1.4rc1 2.0rc1 2.0rc2 2.0rc3 2.0rc4 2.0rc5 2.0rc6 2.0 2.0.1 2.0.2 0.31 0.32 0.3.3.5 0.3.4.1 1.0.1 1.0.2 1.0.3 1.0.4 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6 1.2 1.2.1 1.2.2 1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.0rc1 1.1beta2 1.1beta5 1.1beta6 1.1beta7 1.1beta8 1.1beta9 1.1

22 410 8 0 0 0 0 0 0 0 2 5 0 17 162 127 479 6 54 4 74 3 4 n/a 1 0 37 n/a 1 n/a n/a n/a n/a n/a n/a 7 7 0 61 3 3 8 0

As shown in Figure 1, the first release of concentration curves is above the last release for Avida, which underwent continuous refactoring. Similarily, Figure 2 shows an increasing trend of its concentration index values of CCBO and CDIT over successive releases. Table V shows the two metrics over all of the successive releases. It is noticeable that both CCBO and CDIT values present an increase with the version upgrade for the products that underwent continuous refactoring. For example, the CCBO and CDIT of Shareaza are 0.12 and 0.46 in version 2.1.1. In version 2.2.3, they are both 0.16 and 0.52, and these values increase to 0.18 and 0.53, respectively, in version 2.5.2. While the other projects that the refactoring took place intermittently, CCBO and CDIT values exhibit different trends, which can be seen in Table VI (Appendix). For instance, CCBO and CDIT values of Tellico and Lenya both show a decrease in the last release; however, CCBO decrease and CDIT increase for Audacity, Ant, and Findbugs. Therefore, based on our results, there is an association between continuous practice of refactoring and increasing concentration of dependencies in smaller modules over time. Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

352

YIXIN BIAN ET AL.

Table V. Dependency concentration in smaller classes over successive releases for continuous refactoring: concentration index values for CBO and DIT; CCBO and CDIT are presented with their point estimates and 95% confidence intervals (in brackets). Product

Release type

Release no

Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake

Feature Feature Feature Feature Feature Bug Bug Feature Bug Feature Bug Bug Bug Bug Feature Feature Bug Bug Bug Feature Feature Feature Bug Bug Bug Bug Bug Feature Bug Bug Feature Feature Bug Bug Feature Bug Feature Feature Feature Feature Feature Feature Feature Feature Feature Bug Bug Bug Bug Feature Bug Bug Bug Bug Bug Bug Bug Feature

1.0.1 1.3 1.4 1.6 2.2.0 2.2.1 2.2.2 2.3.0 2.3.1 2.4.0 2.4.1 2.4.2 2.4.3 2.4.4 2.5.0 2.6.0 2.6.1 2.6.2 2.6.3 2.7.0 2.8.0 1.0.3 1.0.4 1.0.5 1.0.6 1.0.7 1.0.8 1.1.0 1.1.1 1.1.2 1.2.4 1.3.0 1.3.1 1.3.2 1.4.0 1.4.1 1.5.0 1.6.0 1.2 1.4.7 1.6.7 1.8.3 2.0.6 2.2.3 2.3.0 2.3.1 2.3.2 2.3.3 2.3.4 2.4.0 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.4.7 2.6.0

CCBO

CDIT

0.17[0.04,0.3] 0.16[0.05,0.27] 0.19[0.08,0.31] 0.24[0.14,0.35] 0.38[0.34,0.43] 0.38[0.34,0.43] 0.38[0.34,0.43] 0.38[0.34, 0.43] 0.5 [0.31,0.69] 0.5 [0.31, 0.69] 0.5 [0.31, 0.69] 0.5 [0.31, 0.69] 0.5[0.31, 0.69] 0.5[0.31, 0.69] 0.46[0.24, 0.68] 0.55[0.33, 0.77] 0.55[0.33, 0.77] 0.55[0.33, 0.77] 0.54[0.33, 0.76] 0.57[0.35, 0.78] 0.58[0.36, 0.8] 0.12[-0.03, 0.28] 0.15[-0.04, 0.35] 0.17[-0.03, 0.36] 0.26[0.11, 0.42] 0.26 [0.11, 0.41] 0.26[0.12, 0.4] 0.25[0.13, 0.37] 0.26[0.14, 0.37] 0.26[0.15, 0.37] 0.27[0.17, 0.36] 0.26[0.18, 0.34] 0.26[0.18, 0.34] 0.27[0.2, 0.34] 0.26[0.19, 0.33] 0.26[0.19, 0.33] 0.27[0.21, 0.34] 0.24[0.18, 0.31] 0.37[0.32, 0.42] 0.39[0.34, 0.44] 0.37[0.33, 0.42] 0.4 [0.35, 0.44] 0.43[0.38, 0.48] 0.37[0.32, 0.41] 0.38[0.33, 0.42] 0.38[0.33, 0.42] 0.38[0.33, 0.42] 0.38[0.33, 0.42] 0.35[0.3, 0.39] 0.35[0.3, 0.39] 0.36[0.31, 0.41] 0.36[0.31, 0.41] 0.36[0.31, 0.41] 0.37[0.32, 0.42] 0.37[0.32, 0.42] 0.37[0.32, 0.42] 0.37[0.32, 0.41] 0.38[0.34, 0.41]

0.51[0.26,0.76] 0.58[0.3,0.85] 0.72[0.53,0.92] 0.8[0.68,0.92] 0.76[0.7,0.83] 0.76[0.7,0.83] 0.76[0.7,0.83] 0.76 [0.7,0.83] 0.81[0.72, 0.89] 0.81[0.72, 0.89] 0.81[0.72, 0.89] 0.81[0.72, 0.89] 0.81[0.73, 0.89] 0.81[0.73, 0.89] 0.82[0.7, 0.94] 0.87[0.71, 1.02] 0.87[0.71, 1.02] 0.87[0.71, 1.02] 0.85[0.69, 1.02] 0.88[0.77, 1] 0.89[0.77, 1.02] 0.64[0.34, 0.93] 0.62[0.33, 0.91] 0.62[0.33, 0.91] 0.84[0.74, 0.93] 0.84[0.78, 0.91] 0.84 [0.77, 0.91] 0.85[0.79, 0.92] 0.85[0.78, 0.92] 0.84[0.77, 0.91] 0.76[0.68, 0.84] 0.77[0.71, 0.83] 0.77[0.72, 0.83] 0.77[0.71, 0.82] 0.77[0.72, 0.83] 0.77[0.72, 0.83] 0.74[0.68, 0.8] 0.76[0.71, 0.82] 0.62[0.52, 0.72] 0.64[0.54, 0.75] 0.68[0.58, 0.77] 0.68[0.59, 0.77] 0.71[0.63, 0.8] 0.73[0.65, 0.8] 0.72[0.62, 0.83] 0.72[0.62, 0.82] 0.72[0.64, 0.8] 0.72[0.64, 0.8] 0.71[0.63, 0.79] 0.71[0.62,0.8] 0.72[0.61, 0.82] 0.71[0.61, 0.82] 0.71[0.6,0.82] 0.71[0.6,0.82] 0.71[0.6, 0.82] 0.71[0.6, 0.82] 0.71[0.6, 0.82] 0.7[0.61, 0.8] (Continues)

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 353

Table V. (Continued) Product

Release type

Release no

CCBO

CDIT

Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake HSQL HSQL HSQL HSQL HSQL HSQL HSQL Hydrogen Hydrogen Hydrogen Hydrogen Hydrogen Hydrogen Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze

Bug Bug Bug Bug Feature Bug Bug Bug Feature Feature Bug Bug Bug Feature Bug Feature Bug Bug Feature Bug Feature Feature Bug Bug Bug Feature Bug Bug Bug Bug Bug Feature Bug Bug Bug Bug Bug Bug Feature Bug Feature Feature Bug Bug Feature Feature Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Feature

2.6.1 2.6.2 2.6.3 2.6.4 2.8.0 2.8.1 2.8.2 2.8.3rc1 1.6.1 1.7.0 1.7.1 1.7.2.11 1.7.3.3 1.8.0.10 1.8.1.3 0.9.3 0.9.3.1 0.9.4.2 0.9.4 0.9.4.1 0.9.5RC1 2.0.0 2.0.3 2.0.4 2.0.5 2.1.0 2.1.1 2.1.2 2.1.3 2.1.3.2 2.1.4 2.2 2.2.1 2.2.3 2.2.4 2.2.5 2.2.5.4 2.2.5.5 2.3 2.3.1 2.4 2.5 2.5.1 2.5.2 2.5.4 3.0.0.6 3.0.0.8 3.0.1.0 3.0.1.2 3.0.1.4 3.0.1.6 3.0.2.0 3.0.2.2 3.0.3.0 3.0.3.4 3.0.4.0 3.0.4.2 3.0.5.0 3.0.5.2 3.1.0.0

0.38[0.34, 0.41] 0.38[0.34, 0.42] 0.39[0.35, 0.42] 0.39[0.35, 0.42] 0.39[0.36, 0.42] 0.39[0.36, 0.42] 0.39[0.35,0.42] 0.39[0.35, 0.42] 0.17[0.03, 0.32] 0.2[0.07, 0.33] 0.21[0.07, 0.35] 0.25[0.18, 0.33] 0.25[0.18, 0.33] 0.28[0.21, 0.35] 0.28[0.21, 0.35] 0.06 [-0.01, 0.13] 0.06[-0.01, 0.13] 0.09[0.02, 0.15] 0.09[0.02, 0.15] 0.09[0.02, 0.15] 0.11[0.05, 0.17] 0.12 [0.08, 0.16] 0.12[0.09, 0.16] 0.12 [0.09,0.16] 0.12[0.09, 0.16] 0.13[0.09, 0.16] 0.12[0.09, 0.16] 0.13[0.09, 0.16] 0.13[0.09, 0.16] 0.13[0.09, 0.16] 0.13[0.09, 0.16] 0.13[0.09, 0.16] 0.13[0.09, 0.16] 0.16[0.12, 0.2] 0.16[0.12, 0.2] 0.16[0.12, 0.2] 0.15[0.12, 0.19] 0.16[0.12, 0.19] 0.16[0.12, 0.19] 0.16[0.12, 0.19] 0.17[0.12, 0.22] 0.18[0.13, 0.23] 0.18[0.13, 0.22] 0.18[0.13, 0.22] 0.33[0.3, 0.37] 0.33[0.3, 0.37] 0.34[0.3, 0.37] 0.34[0.3, 0.37] 0.34[0.3, 0.37] 0.34[0.3, 0.37] 0.34[0.3, 0.37] 0.34[0.3, 0.37] 0.33[0.3, 0.37] 0.33[0.3, 0.37] 0.33[0.3,0.37] 0.33[0.3, 0.37] 0.34[0.3,0.37] 0.34[0.3, 0.37] 0.34[0.31, 0.38] 0.34[0.31, 0.38]

0.7[0.6, 0.8] 0.7[0.6, 0.8] 0.7[0.61, 0.8] 0.7[0.61, 0.8] 0.7[0.61, 0.8] 0.71[0.61, 0.8] 0.71[0.62, 0.81] 0.72[0.61, 0.82] 0.51[0.18, 0.84] 0.63[0.47, 0.79] 0.61[0.46, 0.76] 0.66[0.54, 0.78] 0.66[0.55, 0.78] 0.69[0.58, 0.8] 0.69[0.58, 0.8] 0.57[0.37, 0.78] 0.57[0.37, 0.78] 0.58[0.33, 0.82] 0.58[0.33, 0.82] 0.58[0.33, 0.82] 0.59[0.36, 0.82] 0.45[0.33, 0.57] 0.45[0.33, 0.57] 0.45 [0.33,0.57] 0.45[0.33, 0.57] 0.45[0.33, 0.57] 0.46[0.34,0.57] 0.46[0.34, 0.58] 0.46[0.34, 0.58] 0.46[0.34, 0.58] 0.46[0.34, 0.58] 0.46[0.34, 0.58] 0.46[0.34, 0.58] 0.52[0.42, 0.62] 0.53[0.43, 0.63] 0.53[0.44, 0.63] 0.54[0.44, 0.63] 0.54 [0.44, 0.63] 0.53[0.44, 0.63] 0.54[0.44, 0.63] 0.53[0.44, 0.63] 0.53[0.44, 0.62] 0.53[0.44, 0.62] 0.53[0.44, 0.62] 0.7[0.66, 0.73] 0.7[0.66, 0.73] 0.7[0.67, 0.73] 0.7[0.67, 0.73] 0.7[0.67, 0.73] 0.7[0.67, 0.73] 0.7 [0.67, 0.73] 0.7[0.67, 0.73] 0.7 [0.67, 0.73] 0.7[0.67, 0.73] 0.7[0.67, 0.73] 0.7 [0.67,0.73] 0.7[0.67, 0.73] 0.71[0.68, 0.74] 0.71[0.68, 0.74] 0.71[0.68, 0.74] (Continues)

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

354

YIXIN BIAN ET AL.

Table V. (Continued) Product

Release type

Release no

Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze

Feature Bug Feature Bug Bug Bug Bug Feature Bug Bug Bug Bug Feature Bug Bug

4.0.0.0 4.0.0.2 4.3.0.4 4.3.0.6 4.3.1.0 4.3.1.2 4.3.1.4 4.4.0.0 4.4.0.2 4.4.0.4 4.4.0.6 4.4.10 4.5.0.0 4.5.0.2 4.5.0.4

CCBO

CDIT

0.35[0.32, 0.38] 0.35[0.32, 0.38] 0.36[0.32, 0.39] 0.36[0.33, 0.39] 0.36[0.33, 0.39] 0.36[0.33, 0.39] 0.36[0.33, 0.39] 0.36[0.33, 0.39] 0.36[0.33, 0.39] 0.36[0.33, 0.39] 0.36[0.33, 0.39] 0.36[0.32, 0.39] 0.36[0.32, 0.39] 0.36[0.32, 0.39] 0.36[0.33, 0.39]

0.71[0.68, 0.74] 0.71[0.68, 0.74] 0.72[0.69, 0.74] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69,0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75]

CBO, Coupling Between Objects; DIT, Depth of Inheritance Tree.

5. DISCUSSION The primary finding is that dependencies are concentrated more in smaller modules over product lifetimes [20]. The finding is strikingly consistent within this study because it applies to all releases of all products whose data were analyzed. The projects where refactoring is adopted as a continuous practice would be more likely to show an increasing concentration of dependencies in smaller modules over their lifetime. Therefore, the findings in this study are consistent with the earlier observations made for the single snapshots of multiple products [1]. Because of the accumulating evidence, it would be appropriate for the software practitioners to consider directing the quality assurance activities, which have been traditionally targeted on larger modules [44, 74, 75] toward smaller modules. Such a strategy will be useful if the QA costs spent per line of code are the same for all sizes of modules. Certainly, making process changes in real-life software organizations will require considering various other issues including the cultural ones. It has been repeatedly shown that already formed beliefs and perceptions play a very important role when it comes to adopting new ideas and practices [76, 77]. It is likely that considering structural characteristics of software modules within a larger context will make more convincing cases within the organization. Some other important contextual factors affecting QA prioritization would be the business importance of software modules, the experience and skill levels of the developers/teams who produce or maintain software modules, and the complexity of the domain problems solved or the workflows implemented. While further research in the future is needed to understand the underlying mechanisms, our findings show that continuous application of refactoring is associated with an increase in the concentration of dependencies in smaller modules. It might be that some essential refactoring operations result in smaller modules with higher dependencies per line of code. For example, one of the frequently performed refactoring techniques is ‘Extract Method’ [32], which means extracting one part of an existing method as a new method and replacing the extracted part with a new procedure call [78]. This technique, a common way of reducing repetitions in writing code, is traditionally known as ‘function extraction’ or ‘procedure extraction’. For C language,‘procedure extraction’ was often used to reduce the clones. The two original clone fragments, which have no relationship before refactoring, are coupled with each other by ‘procedure extraction’ after refactoring (in C language, a procedure was regarded as a module). That is the original two relative longer fragments, which have no relationship change three relative shorter fragments, which are coupled with each other after extracting activity. Therefore, the extract method can contribute to concentrate the dependencies in smaller modules. The refactoring tools embedded in modern Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 355

integrated development environments, such as Eclipse, support procedure extraction to a certain degree in order to help programmers apply this technique more easily and more frequently. According to our findings, agile development projects placing special emphasis on continuous refactoring might see an increase in the dependency concentration in smaller modules over the life cycle of their products. However, it is also important to note that refactoring is essential and useful because of its system-wide benefits (e.g., reducing the overall product size). Our findings are only about the effect of refactoring on dependency concentration with respect to module size. To be clear, software practitioners must be advised to apply refactoring; our findings only have implications in terms of the effectiveness and efficiency of focused QA activities often performed with limited amount of resources in software projects.4

6. THREATS TO VALIDITY Although our experimental results are quite encouraging because of their consistency, as in any empirical studies, there are a number of factors that might potentially have an effect on the validity of our results: Construct validity: It is possible to derive other metrics to measure size and dependency of software modules apart from SLOC, CBO, and DIT. However, these metrics have been widely used and validated in many research studies in the software engineering literature [44, 53, 54, 57, 79]. Additional metrics can be collected in other studies, and the results obtained using those metrics could be used to compare with ours. Internal validity: There are no significant threats to the internal validity of our results. The first reason is that our data collection process is complete and consistent. The analysis process relies on established quantitative methods (concentration curves and indices [67]), and it is objective. The second reason is that the tool we used for source code measurement, Understand for C++, is a highly mature and reliable tool [51]. External validity: External validity is concerned with whether the results reported in this paper apply to other products. Our results have been obtained from many releases of a large number of software products, which allow us to draw meaningful conclusions. The selected products are still alive and they continue to evolve. Their source code and data are publicly available in the online repositories.

7. FUTURE RESEARCH DIRECTIONS A related future research direction would be about understanding how the cost of conducting QA is associated with module size. As mentioned earlier, the QA costs spent per line of code will have an impact on whether/how practitioners can benefit from the findings reported in this research. If such costs do not depend on module size or if they are lower for smaller modules, then it is easier to make a case that the current practices should be changed according to our results. If such costs are higher for smaller modules, then calculating the cost–benefit ratio will be more complex. To the best of our knowledge, there has been no study so far assessing the costs of QA with respect to module size. Our study points to an association between continuous refactoring and an increasing concentration of dependencies in smaller modules over time. Future studies can focus on refactoring to possibly 4 For example, software inspections focusing on smaller modules are likely to reveal more defects because of a higher concentration of dependencies in smaller modules.

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

356

YIXIN BIAN ET AL.

figure out how different refactoring operations affect the observed phenomenon. Such studies can possibly shed light on cause–effect relationships, which can result in more precise QA recommendations for different modules or sub-systems based on the type of refactoring operations applied in the system.

8. CONCLUSION Our analysis conducted on all releases of 20 software products shows that dependencies concentrate in smaller modules over the lifetime of these products. The observations made in this study are consistent with those from our earlier research that examined an OSS product, KOffice from a longitudinal analysis [20], and further validate the Theory of Relative Dependency from an evolutionary perspective. We also observed that, in the projects where refactoring was adopted as a continuous practice, the concentration inequality in smaller modules increased over time. Software engineering literature has repeatedly shown that refactoring activities reduce the overall dependencies in the system. Our findings add more information to the research showing a general increase in dependency concentration post-refactoring effort. This shows that even though overall dependencies have reduced, smaller modules have become proportionally more dependent. This makes smaller modules leading candidates for the QA activities. Because module dependencies have been consistently associated with defect proneness of software modules, the findings from this study provide an explanation regarding why smaller modules have more defects per line of code as reported in earlier studies.5 This study confirms the conclusions drawn in those earlier studies that software managers and practitioners should focus their limited QA resources on smaller modules in order to obtain the highest return on investment. Such a QA focus is appropriate over the lifetime of a software product. The evidence also shows that, if refactoring is adopted as a continuous practice in a project, it is appropriate to further increase the QA focus on smaller modules as the product matures. Refactoring is never applied without unit test. By running Jester before and after refactorings, Arie van Deursen and Leon Moonen found that the changes did not affect test coverage [82]. That is after refactoring, a larger module is broken down to smaller ones, but a smaller module is not more likely testable than larger ones. Therefore, it would be still advisable to focus the QA attention on the smaller modules with limited amount of resources in software projects. Even though earlier studies repeatedly demonstrated that savings are possible by focusing QA efforts on smaller modules, the empirical evidence obtained from an evolutionary perspective, which serves as an explanation, had been missing before this study. Because process changes consume organizational resources and require the support and participation of the knowledge workers in an organization, the explanations provided by this study constitute useful arguments that can be used by change agents when they advocate for more cost-effective QA practices in their organizations. Future replicated studies on the same and other systems such as Eclipse would be useful to further validate and generalize our research results. In such studies, it would be preferable focusing on multiple software products that evolved and grew substantially over years.

5

However, Lindvall has showed that large classes are more change prone than small classes [80] and a frequently changed part of the code has been demonstrated to be associated with defects [81] Even though larger modules or classes in any software system contain more code and are more change prone than smaller modules, our findings imply that, given limited and a fixed amount of resources, focusing on the smaller modules would lead to more effective defect detection. That is, practitioners should allocate their limited resources to the most defect prone source code modules in their system [46].

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 357

APPENDIX A Table VI. Dependency concentration in smaller classes over successive releases: concentration index values for CBO and DIT; CCBO and CDIT are presented with their point estimates and 95% confidence intervals (in brackets). Product

Release type

Release no

Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk

Feature Bug Bug Bug Bug Bug Feature Bug Feature Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Feature Bug Bug Bug Bug Feature Bug Bug Bug Bug Bug Feature Bug Bug Feature Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Feature Bug Bug Bug Bug Bug Bug Feature Bug

0.1 0.1.2 0.1.3 0.1.4 0.1.5 0.1.6 0.2 0.2.1 0.3 0.3.1 0.3.2 0.3.3 0.3.3.1 0.3.3.2 0.3.3.3 0.3.3.4 0.3.3.5 0.3.4 0.3.4.1 1 1.0.1 1.0.2 1.0.3 1.0.4 1.1 1.1.1 1.1.2 1.1.4 1.1.5 1.1.6 1.2 1.2.1 1.2.2 1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 1.3.6 1.3.7 1.3.8 1.3.9 1.3.10 1.3.11 1.4 1.4.1 1.4.2 1.4.3 1.4.4 1.4.5 1.4.6 1.5 1.5.1

CCBO

CDIT

0.3[0.2,0.39] 0.29[0.2,0.38] 0.29[0.2,0.38] 0.29[0.2,0.38] 0.29[0.2,0.38] 0.29[0.2,0.38] 0.28[0.18,0.37] 0.28[0.19,0.37] 0.3[0.22,0.39] 0.33[0.25,0.4] 0.33[0.26,0.41] 0.32[0.24,0.39] 0.32[0.24,0.39] 0.32[0.24,0.39] 0.32[0.24,0.39] 0.32[0.24,0.4] 0.32[0.24,0.4] 0.32[0.24,0.4] 0.32[0.24,0.4] 0.3[0.23,0.38] 0.3[0.23,0.38] 0.3[0.23,0.38] 0.32[0.24,0.39] 0.32[0.24,0.39] 0.35[0.29,0.41] 0.35[0.29,0.41] 0.35[0.29,0.41] 0.35[0.29,0.41] 0.35[0.29,0.41] 0.35[0.29,0.41] 0.35[0.29,0.41] 0.35[0.29,0.41] 0.35[0.29,0.41] 0.35[0.29,0.41] 0.35[0.29,0.41] 0.35[0.29,0.41] 0.35[0.29,0.41] 0.35[0.29,0.4] 0.35[0.29,0.4] 0.35[0.29,0.4] 0.35[0.29,0.4] 0.35[0.29,0.4] 0.35[0.29,0.4] 0.35[0.29,0.4] 0.35[0.29,0.4] 0.33[0.28,0.38] 0.34[0.29,0.39] 0.34[0.29,0.38] 0.34[0.29,0.38] 0.34[0.29,0.38] 0.33[0.28,0.38] 0.33[0.29,0.38] 0.33[0.29,0.38] 0.34[0.29,0.38]

0.55[0.44,0.66] 0.56[0.45,0.66] 0.55[0.45,0.66] 0.55[0.45,0.66] 0.56[0.45,0.66] 0.56[0.45,0.66] 0.55[0.44,0.66] 0.55[0.45,0.66] 0.58[0.48,0.68] 0.58[0.49,0.68] 0.59[0.49,0.68] 0.58[0.49,0.68] 0.59[0.49,0.68] 0.59[0.49,0.68] 0.59[0.49,0.68] 0.59[0.49,0.68] 0.59[0.49,0.68] 0.59[0.5,0.69] 0.59[0.5,0.69] 0.59[0.5,0.68] 0.59[0.5,0.68] 0.59[0.5,0.68] 0.59[0.51,0.68] 0.59[0.51,0.68] 0.63[0.56,0.7] 0.63[0.56,0.7] 0.63[0.56,0.7] 0.63[0.56,0.7] 0.63[0.56,0.7] 0.63[0.56,0.7] 0.63[0.57,0.69] 0.63[0.57,0.69] 0.64[0.57,0.7] 0.63[0.57,0.68] 0.63[0.57,0.68] 0.63[0.57,0.68] 0.62[0.57,0.68] 0.62[0.57,0.68] 0.62[0.57,0.68] 0.62[0.56,0.68] 0.62[0.56,0.68] 0.62[0.56,0.68] 0.62[0.56,0.68] 0.62[0.56,0.68] 0.62[0.56,0.68] 0.64[0.58,0.69] 0.64[0.59,0.69] 0.64[0.59,0.69] 0.64[0.59,0.69] 0.64[0.59,0.69] 0.64[0.59,0.69] 0.64[0.59,0.69] 0.64[0.59,0.68] 0.64[0.59,0.68] (Continues)

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

358

YIXIN BIAN ET AL.

Table VI. (Continued) Product

Release type

Release no

CCBO

CDIT

Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Jajuk Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Ant Audacity Audacity Audacity Audacity Audacity Audacity Audacity Audacity Audacity Audacity Audacity

Bug Bug Feature Bug Bug Feature Bug Bug Bug Bug Feature Bug Bug Bug Bug Feature Feature Beta Beta Bdta Feature Beta Beta Feature Beta Bug Beta Beta Beta RC Feature Beta Bug Bug Bug Bug Beta Beta Beta Feature Bug Bug Bug Bug Bug Feature Bug Feature Bug Feature Feature Feature Feature Bug Feature Bug Bug Bug Feature Bug

1.5.2 1.5.3 1.6 1.6.1 1.6.2 1.7 1.7.1 1.7.2 1.7.3 1.7.4 1.8 1.8.1 1.8.2 1.8.3 1.8.4 1.1 1.2 1.3Beta1 1.3Beta2 1.3Beta3 1.3 1.4Beta1 1.4Beta2 1.4 1.4.1Beta1 1.4.1 1.5Beta1 1.5Beta2 1.5Beta3 1.5rc1 1.5 1.5.1Beta1 1.5.1 1.5.2 1.5.3 1.5.4 1.6Beta1 1.6Beta2 1.6Beta3 1.6.0 1.6.1 1.6.2 1.6.3 1.6.4 1.6.5 1.7.0 1.7.1 1.8.0 1.8.1 0.8 0.98 1 1.1 1.1.1 1.2.0 1.2.1 1.2.2 1.2.3 1.3.0 1.3.2

0.34[0.29,0.38] 0.33[0.29,0.38] 0.34[0.3,0.39] 0.34[0.3,0.39] 0.34[0.3,0.39] 0.33[0.29,0.37] 0.33[0.29,0.38] 0.33[0.29,0.38] 0.33[0.29,0.38] 0.33[0.29,0.38] 0.33[0.29,0.38] 0.34[0.29,0.38] 0.33[0.29,0.38] 0.33[0.29,0.38] 0.33[0.29,0.38] 0.4[0.24,0.55] 0.31[0.21,0.41] 0.37[0.31,0.44] 0.37[0.31,0.44] 0.37[0.31,0.44] 0.37[0.31,0.44] 0.30[0.25,0.36] 0.30[0.25,0.36] 0.3[0.25,0.36] 0.3[0.25,0.36] 0.3[0.25,0.36] 0.25[0.2,0.29] 0.25[0.21,0.3] 0.25[0.21,0.29] 0.25[0.2,0.29] 0.25[0.2,0.29] 0.25[0.2,0.29] 0.25[0.2,0.29] 0.25[0.2,0.29] 0.25[0.2,0.29] 0.25[0.2,0.29] 0.24[0.2,0.27] 0.24[0.2,0.27] 0.24[0.2,0.27] 0.24[0.2,0.27] 0.23[0.2,0.27] 0.23[0.19,0.26] 0.23[0.19,0.26] 0.23[0.19,0.26] 0.23[0.19,0.26] 0.22[0.18,0.25] 0.22[0.19,0.25] 0.22[0.19,0.26] 0.22[0.19,0.26] 0.48[-0.05,1.01] 0.43[0.28,0.58] 0.44[0.3,0.59] 0.42[0.31,0.52] 0.42[0.33,0.52] 0.33[0.27,0.39] 0.33[0.27,0.39] 0.32[0.26,0.38] 0.32[0.26,0.38] 0.37[0.32,0.42] 0.34[0.29,0.38]

0.64[0.59,0.68] 0.64[0.59,0.68] 0.63[0.59,0.68] 0.63[0.59,0.68] 0.63[0.59,0.68] 0.62[0.58,0.66] 0.62[0.58,0.66] 0.62[0.58,0.66] 0.62[0.58,0.66] 0.62[0.58,0.66] 0.62[0.58,0.66] 0.62[0.58,0.66] 0.62[0.58,0.66] 0.62[0.58,0.66] 0.62[0.58,0.66] 0.51[0.42,0.60] 0.51[0.42,0.60] 0.57[0.49,0.64] 0.57[0.49,0.64] 0.57[0.49,0.64] 0.57[0.49,0.64] 0.53[0.42,0.63] 0.53[0.42,0.63] 0.53[0.42,0.63] 0.53[0.42,0.63] 0.53[0.42,0.63] 0.54[0.45,0.64] 0.54[0.45,0.64] 0.54[0.45,0.64] 0.55[0.45,0.64] 0.55[0.45,0.64] 0.55[0.45,0.64] 0.55[0.45,0.64] 0.54[0.45,0.64] 0.54[0.45,0.64] 0.54[0.45,0.64] 0.57[0.49,0.65] 0.57[0.49,0.65] 0.57[0.49,0.65] 0.57[0.49,0.65] 0.57[0.49,0.65] 0.57[0.49,0.66] 0.58[0.5,0.66] 0.58[0.5,0.66] 0.58[0.5,0.66] 0.59[0.51,0.67] 0.59[0.51,0.66] 0.61[0.53,0.68] 0.61[0.53,0.68] 0.65[0.46,0.85] 0.75[0.65,0.86] 0.76[0.65,0.87] 0.69[0.55,0.83] 0.69[0.58,0.79] 0.58[0.49,0.67] 0.53[0.49,0.66] 0.58[0.5,0.66] 0.59[0.51,0.67] 0.59[0.51,0.67] 0.61[0.55,0.67] (Continues)

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 359

Table VI. (Continued) Product

Release type

Release no

Audacity Audacity Audacity Audacity Audacity Audacity Audacity Audacity Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Avida Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Celestia Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake

Bug Bug Bug Bug Bug Bug Bug Bug Feature Feature Feature Feature Feature Bug Bug Feature Bug Feature Bug Bug Bug Bug Feature Feature Bug Bug Bug Feature Feature Feature Bug Bug Bug Bug Bug Feature Bug Bug Feature Feature Bug Bug Feature Bug Feature Feature Feature Feature Feature Feature Feature Feature Feature Bug Bug Bug Bug Feature Bug Bug

1.3.3 1.3.4 1.3.5 1.3.6 1.3.7 1.3.8 1.3.9 1.3.12 1.0.1 1.3 1.4 1.6 2.2.0 2.2.1 2.2.2 2.3.0 2.3.1 2.4.0 2.4.1 2.4.2 2.4.3 2.4.4 2.5.0 2.6.0 2.6.1 2.6.2 2.6.3 2.7.0 2.8.0 1.0.3 1.0.4 1.0.5 1.0.6 1.0.7 1.0.8 1.1.0 1.1.1 1.1.2 1.2.4 1.3.0 1.3.1 1.3.2 1.4.0 1.4.1 1.5.0 1.6.0 1.2 1.4.7 1.6.7 1.8.3 2.0.6 2.2.3 2.3.0 2.3.1 2.3.2 2.3.3 2.3.4 2.4.0 2.4.1 2.4.2

CCBO

CDIT

0.32[0.27,0.36] 0.31[0.27,0.36] 0.31[0.27,0.36] 0.31[0.27,0.36] 0.32[0.28,0.36] 0.32[0.28,0.36] 0.34[0.3,0.39] 0.35[0.31,0.39] 0.17[0.04,0.3] 0.16[0.05,0.27] 0.19[0.08,0.31] 0.24[0.14,0.35] 0.38[0.34,0.43] 0.38[0.34,0.43] 0.38[0.34,0.43] 0.38[0.34, 0.43] 0.5 [0.31,0.69] 0.5 [0.31, 0.69] 0.5 [0.31, 0.69] 0.5 [0.31, 0.69] 0.5[0.31, 0.69] 0.5[0.31, 0.69] 0.46[0.24, 0.68] 0.55[0.33, 0.77] 0.55[0.33, 0.77] 0.55[0.33, 0.77] 0.54[0.33, 0.76] 0.57[0.35, 0.78] 0.58[0.36, 0.8] 0.12[-0.03, 0.28] 0.15[-0.04, 0.35] 0.17[-0.03, 0.36] 0.26[0.11, 0.42] 0.26[0.11, 0.41] 0.26[0.12, 0.4] 0.25[0.13, 0.37] 0.26[0.14, 0.37] 0.26[0.15, 0.37] 0.27[0.17, 0.36] 0.26[0.18, 0.34] 0.26[0.18, 0.34] 0.27[0.2, 0.34] 0.26[0.19, 0.33] 0.26[0.19, 0.33] 0.27[0.21, 0.34] 0.24[0.18, 0.31] 0.37[0.32, 0.42] 0.39[0.34, 0.44] 0.37[0.33, 0.42] 0.4 [0.35, 0.44] 0.43[0.38, 0.48] 0.37[0.32, 0.41] 0.38[0.33, 0.42] 0.38[0.33, 0.42] 0.38[0.33, 0.42] 0.38[0.33, 0.42] 0.35[0.3, 0.39] 0.35[0.3, 0.39] 0.36[0.31, 0.41] 0.36[0.31, 0.41]

0.61[0.54,0.67] 0.61[0.55,0.67] 0.62[0.55,0.68] 0.61[0.55,0.67] 0.61[0.55,0.68] 0.63[0.57,0.69] 0.65[0.6,0.71] 0.66[0.61,0.71] 0.51[0.26,0.76] 0.58[0.3,0.85] 0.72[0.53,0.92] 0.8[0.68,0.92] 0.76[0.7,0.83] 0.76[0.7,0.83] 0.76[0.7,0.83] 0.76 [0.7,0.83] 0.81[0.72, 0.89] 0.81[0.72, 0.89] 0.81[0.72, 0.89] 0.81[0.72, 0.89] 0.81[0.73, 0.89] 0.81[0.73, 0.89] 0.82[0.7, 0.94] 0.87[0.71, 1.02] 0.87[0.71, 1.02] 0.87[0.71, 1.02] 0.85[0.69, 1.02] 0.88[0.77, 1] 0.89[0.77, 1.02] 0.64[0.34, 0.93] 0.62[0.33, 0.91] 0.62[0.33, 0.91] 0.84[0.74, 0.93] 0.84[0.78, 0.91] 0.84 [0.77, 0.91] 0.85[0.79, 0.92] 0.85[0.78, 0.92] 0.84[0.77, 0.91] 0.76[0.68, 0.84] 0.77[0.71, 0.83] 0.77[0.72, 0.83] 0.77[0.71, 0.82] 0.77[0.72, 0.83] 0.77[0.72, 0.83] 0.74[0.68, 0.8] 0.76[0.71, 0.82] 0.62[0.52, 0.72] 0.64[0.54, 0.75] 0.68[0.58, 0.77] 0.68[0.59, 0.77] 0.71[0.63, 0.8] 0.73[0.65, 0.8] 0.72[0.62, 0.83] 0.72[0.62, 0.82] 0.72[0.64, 0.8] 0.72[0.64, 0.8] 0.71[0.63, 0.79] 0.71[0.62,0.8] 0.72[0.61, 0.82] 0.71[0.61, 0.82] (Continues)

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

360

YIXIN BIAN ET AL.

Table VI. (Continued) Product

Release type

Release no

CCBO

CDIT

Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Cmake Exult Exult Exult Exult Exult Exult Exult Exult Exult Exult Exult Exult Exult Exult Exult Exult Exult Exult Exult Exult Exult FindBugs FindBugs FindBugs FindBugs FindBugs FindBugs FindBugs Groovy Groovy Groovy Groovy Groovy Groovy Groovy Groovy Groovy Hipergate Hipergate Hipergate Hipergate Hipergate Hipergate Hipergate Hipergate Hipergate

Bug Bug Bug Bug Bug Feature Bug Bug Bug Bug Feature Bug Bug Bug Feature Bug Bug Feature Bug Bug Feature Bug Feature Alpha Alpha Alpha Alpha Alpha RC RC Feature Beta Beta Beta Feature Feature Feature Bug fix Bug fix Bug fix Bug fix Bug fix Feature Feature Feature Bug Feature Bug Bug Beta Beta Feature Feature Feature Feature Bug Feature Feature Bug Feature

2.4.3 2.4.4 2.4.5 2.4.6 2.4.7 2.6.0 2.6.1 2.6.2 2.6.3 2.6.4 2.8.0 2.8.1 2.8.2 2.8.3rc1 0.1 0.11 0.12 0.2 0.25 0.26 0.3 0.35 0.4 0.90alpha1 0.92alpha3 0.93alpha4 0.94alpha5 0.96beta1 0.98rc1 0.991rc2 1 1.1beta1 1.1beta2 1.1beta3 1.2 1.2.1 1.3.4 1.3.5 1.3.6 1.3.7 1.3.8 1.3.9 1 1.5.8 1.6.8 1.6.9 1.7.3 1.7.4 1.7.5 1.8.0beta1 1.8.0beta2 1.0.5 1.1.0 2.0.17 2.1.17 2.1.20 3.0.40 4.0.12 4.0.14 5.5

0.36[0.31, 0.41] 0.37[0.32, 0.42] 0.37[0.32, 0.42] 0.37[0.32, 0.42] 0.37[0.32, 0.41] 0.38[0.34, 0.41] 0.38[0.34, 0.41] 0.38[0.34, 0.42] 0.39[0.35, 0.42] 0.39[0.35, 0.42] 0.39[0.36, 0.42] 0.39[0.36, 0.42] 0.39[0.35,0.42] 0.39[0.35, 0.42] 0.45[0.33, 0.57] 0.4[0.29, 0.51] 0.37[0.25, 0.48] 0.34[0.23, 0.44] 0.35[0.26, 0.43] 0.35[0.27, 0.42] 0.34[0.27, 0.41] 0.33[0.27, 0.39] 0.34[0.28, 0.4] 0.34[0.29, 0.39] 0.34[0.3, 0.38] 0.3[0.26, 0.34] 0.32[0.29, 0.36] 0.33[0.29, 0.37] 0.32[0.28, 0.37] 0.33[0.29, 0.37] 0.33[0.29, 0.37] 0.32[0.28, 0.36] 0.32[0.28, 0.36] 0.32[0.29, 0.36] 0.33[0.29, 0.37] 0.28 [0.23, 0.33] 0.27[0.23, 0.31] 0.26[0.22, 0.3] 0.26[0.22, 0.3] 0.26[0.22, 0.3] 0.26[0.22, 0.29] 0.25[0.22, 0.29] 0.53[0.42,0.64] 0.47[0.37,0.54] 0.48[0.4,0.56] 0.48[0.4, 0].56 0.47[0.39,0.55] 0.47[0.39,0.55] 0.47[0.39,0.55] 0.48[0.4, 0.56] 0.48[0.4,0.56] 0.33[0.22, 0.44] 0.37[0.31, 0.43] 0.4[0.35, 0.45] 0.3[0.26, 0.34] 0.3[0.26, 0.34] 0.31[0.26, 0.37] 0.31[0.26, 0.37] 0.31[0.26, 0.37] 0.31[0.26, 0.36]

0.71[0.6,0.82] 0.71[0.6,0.82] 0.71[0.6, 0.82] 0.71[0.6, 0.82] 0.71[0.6, 0.82] 0.7[0.61, 0.8] 0.7[0.6, 0.8] 0.7[0.6, 0.8] 0.7[0.61, 0.8] 0.7[0.61, 0.8] 0.7[0.61, 0.8] 0.71[0.61, 0.8] 0.71[0.62, 0.81] 0.72[0.61, 0.82] 0.72[0.6, 0.84] 0.63[0.47, 0.78] 0.62[0.47, 0.77] 0.61[0.48, 0.74] 0.51[0.38, 0.65] 0.5[0.37, 0.64] 0.59[0.48, 0.7] 0.62[0.53, 0.71] 0.64[0.55, 0.72] 0.65[0.58, 0.72] 0.71[0.65, 0.77] 0.71[0.65, 0.77] 0.72[0.66, 0.79] 0.72[0.66, 0.79] 0.74[0.66, 0.81] 0.74[0.67, 0.81] 0.74[0.67, 0.81] 0.72[0.65, 0.78] 0.72[0.65, 0.78] 0.72[0.65, 0.78] 0.72 [0.65, 0.79] 0.6[0.55, 0.65] 0.6[0.55, 0.65] 0.6[0.55, 0.65] 0.6[0.55, 0.65] 0.6[0.55, 0.65] 0.6[0.55, 0.65] 0.61[0.56, 0.66] 0.81[0.72, 0.9] 0.79[0.7, 0.88] 0.8[0.74, 0.86] 0.8[0.74, 0.86] 0.8[0.73, 0.87] 0.8[0.73, 0.87] 0.8[0.73,0.87] 0.8[0.73, 0.87] 0.8[0.73, 0.87] 0.63[0.52, 0.74] 0.59[0.5, 0.69] 0.63[0.54, 0.72] 0.69[0.64, 0.74] 0.69[0.64, 0.74] 0.67[0.6, 0.75] 0.68[0.6, 0.75] 0.68[0.6, 0.75] 0.68[0.61, 0.75] (Continues)

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 361

Table VI. (Continued) Product

Release type

Release no

CCBO

CDIT

HSQL HSQL HSQL HSQL HSQL HSQL HSQL Hydrogen Hydrogen Hydrogen Hydrogen Hydrogen Hydrogen Jaxen Jaxen Jaxen Jaxen Jaxen Jaxen Jaxen Jaxen Jaxen Jaxen Jaxen Jaxen Jaxen Jaxen Jaxen Jaxen Kmeleon Kmeleon Kmeleon Kmeleon Kmeleon Kmeleon Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Lenya Pluto Pluto Pluto Pluto

Feature Feature Bug Bug Bug Feature Bug Feature Bug Bug Feature Bug Feature Beta Beta Beta RC Beta Beta Beta Beta Beta Beta Beta Beta Beta Feature Bug Bug Feature Feature Feature Feature Bug Feature RC RC RC Feature Bug Bug Bug Bug Bug Alpha Feature RC RC RC RC RC RC Feature Bug Bug Bug Feature Feature Bug Bug

1.6.1 1.7.0 1.7.1 1.7.2.11 1.7.3.3 1.8.0.10 1.8.1.3 0.9.3 0.9.3.1 0.9.4.2 0.9.4 0.9.4.1 0.9.5RC1 1.0beta10 1.0beta7 1.0beta9 1.0rc1 1.1beta2 1.1beta5 1.1beta6 1.1beta7 1.1beta8 1.1beta9 1.1beta10 1.1beta11 1.1beta12 1.1 1.1.1 1.1.2 0.5 0.82 0.9 1 1.02 1.5Beta 1.2rc1 1.2rc2 1.2rc3 1.2 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.4alpha1 1.4rc1 2.0rc1 2.0rc2 2.0rc3 2.0rc4 2.0rc5 2.0rc6 2 2.0.1 2.0.2 2.0.3 1.0.1 1.1.0 1.1.2 1.1.3

0.17[0.03, 0.32] 0.2[0.07, 0.33] 0.21[0.07, 0.35] 0.25[0.18, 0.33] 0.25[0.18, 0.33] 0.28[0.21, 0.35] 0.28[0.21, 0.35] 0.06 [-0.01, 0.13] 0.06[-0.01, 0.13] 0.09[0.02, 0.15] 0.09[0.02, 0.15] 0.09[0.02, 0.15] 0.11[0.05, 0.17] 0.18[0.04, 0.32] 0.18[0.04, 0.31] 0.18[0.05, 0.32] 0.18[0.04, 0.31] 0.27[0.15, 0.4] 0.29[0.17, 0.4] 0.27[0.15, 0.38] 0.26[0.15, 0.37] 0.26[0.15, 0.37] 0.26[0.14, 0.37] 0.26[0.15, 0.36] 0.26[0.16, 0.37] 0.26[0.14, 0.37] 0.26[0.14, 0.37] 0.26[0.14, 0.37] 0.26[0.14, 0.37] 0.08[0, 0.16] 0.17[0.05, 0.28] 0.18[0.06,0.3] 0.19[0.09, 0.29] 0.23[0.13, 0.34] 0.17[0.06, 0.27] 0.24 [0.17,0.31] 0.22[0.15, 0.29] 0.24[0.17, 0.3] 0.24 [0.18, 0.3] 0.22[0.16, 0.29] 0.25[0.19, 0.31] 0.23[0.18, 0.29] 0.24[0.18, 0.29] 0.25[0.18, 0.31] 0.24[0.18, 0.3] 0.19[0.15, 0.23] 0.19[0.15, 0.23] 0.19[0.15, 0.23] 0.19[0.15, 0.23] 0.19[0.15, 0.23] 0.19[0.15, 0.23] 0.19[0.15, 0.23] 0.19[0.15, 0.23] 0.19[0.15, 0.23] 0.19[0.15, 0.23] 0.18[0.14, 0.22] 0.11[0.02, 0.2] 0.02[-0.07, 0.11] 0.02[-0.06, 0.1] 0.02[-0.06, 0.1]

0.51[0.18, 0.84] 0.63[0.47, 0.79] 0.61[0.46, 0.76] 0.66[0.54, 0.78] 0.66[0.55, 0.78] 0.69[0.58, 0.8] 0.69[0.58, 0.8] 0.57[0.37, 0.78] 0.57[0.37, 0.78] 0.58[0.33, 0.82] 0.58[0.33, 0.82] 0.58[0.33, 0.82] 0.59[0.36, 0.82] 0.6 [0.51,0.68] 0.52[0.42, 0.62] 0.6[0.51, 0.68] 0.59[0.51, 0.67] 0.64[0.56, 0.71] 0.64 [0.56,0.72] 0.64[0.56, 0.72] 0.64[0.56, 0.72] 0.64[0.57, 0.72] 0.64[0.57, 0.72] 0.64[0.57, 0.72] 0.64[0.57, 0.71] 0.65[0.58, 0.73] 0.65[0.58, 0.73] 0.65[0.58, 0.73] 0.65[0.58, 0.73] 0.5[0.37, 0.63] 0.58[0.4,0.76] 0.57[0.42, 0.72] 0.63[0.53, 0.72] 0.64[0.55, 0.73] 0.63[0.55, 0.72] 0.56[0.48, 0.63] 0.54[0.46, 0.62] 0.54[0.48, 0.61] 0.55[0.48, 0.62] 0.55[0.48, 0.61] 0.55[0.49, 0.62] 0.55[0.48, 0.62] 0.55[0.48, 0.61] 0.55[0.47, 0.62] 0.56[0.47, 0.64] 0.51[0.45, 0.58] 0.52[0.47, 0.58] 0.52[0.46, 0.58] 0.52[0.46, 0.58] 0.52[0.46, 0.58] 0.52[0.46, 0.58] 0.52[0.46, 0.58] 0.51[0.45, 0.57] 0.52[0.47, 0.58] 0.52[0.46, 0.58] 0.52[0.46, 0.58] 0.53[0.46, 0.6] 0.49[0.36, 0.62] 0.48[0.35, 0.6] 0.48[0.35, 0.6] (Continues)

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

362

YIXIN BIAN ET AL.

Table VI. (Continued) Product

Release type

Release no

Pluto Pluto Pluto Pluto Pluto Pluto Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Qbittorrent Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza

Bug Bug Bug Bug Feature Bug Feature Bug Feature Bug Bug Bug Bug Feature Bug Feature Bug Bug Bug Bug Feature Bug Feature Bug Bug Bug Feature Bug Bug Bug Bug Bug Feature Bug Bug Bug Bug Feature Bug Bug Bug Bug Bug Bug Bug Bug Feature Bug Feature Bug Feature Bug Bug Bug Feature Bug Bug Bug Bug Bug

1.1.4 1.1.5 1.1.6 1.1.7 2.0.1 2.0.2 0.92 0.93 1.1.0 1.1.1 1.1.2 1.1.3 1.1.4 1.2.0rc1 1.2.1 1.3.0 1.3.1 1.3.3 1.3.4 1.3.5 1.4.0 1.4.1 1.5.0 1.5.3 1.5.4 1.5.6 2.0.0 2.0.2 2.0.3 2.0.5 2.0.6 2.0.7 2.1.0 2.1.1 2.1.2 2.1.4 2.1.6 2.2.0 2.2.10 2.2.11 2.2.1 2.2.2 2.2.5 2.2.6 2.2.8 2.2.9 2.3.0 2.3.1 2.4.0 2.4.2 2.0.0 2.0.3 2.0.4 2.0.5 2.1.0 2.1.1 2.1.2 2.1.3 2.1.3.2 2.1.4

CCBO

CDIT

0.06[-0.02, 0.15] 0.06[-0.02, 0.14] 0.07[-0.01, 0.15] 0.07[-0.01, 0.15] 0.1[0.01, 0.19] 0.1[0.01, 0.19] 0.29[0.16, 0.42] 0.3[0.17, 0.42] 0.22[0.11, 0.33] 0.22[0.11, 0.33] 0.22[0.11, 0.33] 0.22[0.11, 0.33] 0.22[0.11, 0.33] 0.26[0.15, 0.38] 0.26[0.15, 0.38] 0.23[0.12, 0.35] 0.23[0.12, 0.34] 0.23[0.11, 0.34] 0.23[0.11, 0.34] 0.23[0.11, 0.34] 0.23 [0.12, 0.35] 0.23[0.12, 0.35] 0.24[0.15, 0.33] 0.24[0.15, 0.34] 0.24[0.15, 0.34] 0.24[0.15, 0.34] 0.22[0.14, 0.3] 0.22[0.14, 0.3] 0.22[0.14, 0.3] 0.21[0.13, 0.3] 0.22[0.13, 0.3] 0.22[0.13, 0.3] 0.24[0.14, 0.33] 0.23[0.14, 0.33] 0.23[0.14, 0.32] 0.23[0.15, 0.32] 0.23[0.15, 0.32] 0.2[0.11, 0.28] 0.2[0.11, 0.28] 0.2[0.11, 0.28] 0.2[0.11, 0.28] 0.2[0.12, 0.29] 0.2[0.11, 0.29] 0.2[0.11, 0.29] 0.2[0.11, 0.29] 0.2[0.11, 0.28] 0.18[0.1, 0.26] 0.18[0.1, 0.27] 0.2[0.12, 0.28] 0.2[0.12, 0.28] 0.12 [0.08, 0.16] 0.12[0.09, 0.16] 0.12 [0.09,0.16] 0.12[0.09, 0.16] 0.13[0.09, 0.16] 0.12[0.09, 0.16] 0.13[0.09, 0.16] 0.13[0.09, 0.16] 0.13[0.09, 0.16] 0.13[0.09, 0.16]

0.49[0.37, 0.6] 0.49[0.38, 0.6] 0.49[0.38, 0.6] 0.49[0.38, 0.6] 0.6[0.46, 0.73] 0.6[0.46, 0.73] 0.66[0.43, 0.89] 0.67[0.43, 0.9] 0.57[0.4,0.75] 0.57[0.4, 0.75] 0.57[0.4, 0.75] 0.58[0.4, 0.75] 0.57[0.4, 0.75] 0.61[0.44, 0.78] 0.61[0.44, 0.78] 0.59[0.42, 0.76] 0.59[0.42, 0.76] 0.59[0.41, 0.76] 0.59[0.41, 0.76] 0.59[0.41, 0.76] 0.6[0.42, 0.77] 0.6[0.42, 0.77] 0.59[0.45, 0.73] 0.59[0.45, 0.74] 0.59[0.45, 0.74] 0.59[0.45, 0.74] 0.59[0.47, 0.71] 0.59[0.47, 0.71] 0.59[0.47, 0.71] 0.59[0.46, 0.71] 0.59[0.46, 0.71] 0.59[0.46, 0.71] 0.6[0.48, 0.73] 0.61[0.48, 0.73] 0.6[0.48, 0.73] 0.6[0.48, 0.73] 0.6[0.48, 0.73] 0.6[0.47, 0.72] 0.61[0.5, 0.72] 0.61[0.5, 0.72] 0.6[0.48, 0.72] 0.6[0.49, 0.72] 0.6[0.48, 0.72] 0.6[0.49, 0.72] 0.6[0.49, 0.72] 0.61[0.5,0.72] 0.62[0.52, 0.73] 0.62[0.52, 0.73] 0.63[0.52, 0.74] 0.63[0.52, 0.74] 0.45[0.33, 0.57] 0.45[0.33, 0.57] 0.45 [0.33,0.57] 0.45[0.33, 0.57] 0.45[0.33, 0.57] 0.46[0.34,0.57] 0.46[0.34, 0.58] 0.46[0.34, 0.58] 0.46[0.34, 0.58] 0.46[0.34, 0.58] (Continues)

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 363

Table VI. (Continued) Product

Release type

Release no

Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Shareaza Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico Tellico

Feature Bug Bug Bug Bug Bug Bug Feature Bug Feature Feature Bug Bug Feature Bug Bug Bug Bug Bug Bug Bug Bug Bug Feature Bug Bug Bug Feature Bug Bug Bug Bug Bug Bug Feature Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Feature Bug Bug Bug Bug Bug Feature Feature Bug Feature Feature

2.2 2.2.1 2.2.3 2.2.4 2.2.5 2.2.5.4 2.2.5.5 2.3 2.3.1 2.4 2.5 2.5.1 2.5.2 0.12 0.13 0.13.1 0.13.2 0.13.3 0.13.4 0.13.5 0.13.6 0.13.7 0.13.8 1 1.0.1 1.0.2 1.0.3 1.1 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6 1.2.0 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.2.6 1.2.7 1.2.8 1.2.9 1.2.10 1.2.11 1.2.12 1.2.13 1.2.14 1.3.0 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 2 2.1 2.1.1 2.2 2.3

CCBO

CDIT

0.13[0.09, 0.16] 0.13[0.09, 0.16] 0.16[0.12, 0.2] 0.16[0.12, 0.2] 0.16[0.12, 0.2] 0.15[0.12, 0.19] 0.16[0.12, 0.19] 0.16[0.12, 0.19] 0.16[0.12, 0.19] 0.17[0.12, 0.22] 0.18[0.13, 0.23] 0.18[0.13, 0.22] 0.18[0.13, 0.22] 0.23[0.15, 0.31] 0.23[0.16, 0.3] 0.23[0.16, 0.3] 0.24[0.17, 0.3] 0.24[0.17, 0.3] 0.24[0.17, 0.3] 0.24[0.17,0.31] 0.24[0.17, 0.31] 0.24[0.17, 0.31] 0.24[0.17, 0.31] 0.22 [0.17, 0.27] 0.22[0.16, 0.27] 0.22[0.16, 0.27] 0.22[0.16, 0.27] 0.18[0.13, 0.23] 0.21[0.15, 0.26] 0.21[0.16, 0.26] 0.21[0.16, 0.26] 0.21[0.16, 0.26] 0.21[0.16, 0.26] 0.21[0.16, 0.26] 0.2[0.15, 0.24] 0.2[0.16, 0.25] 0.2[0.16, 0.25] 0.21[0.16, 0.25] 0.21[0.16, 0.25] 0.2[0.16, 0.25] 0.2[0.15, 0.24] 0.2[0.15, 0.24] 0.2[0.15, 0.24] 0.2[0.15, 0.24] 0.2[0.15, 0.24] 0.2[0.15, 0.24] 0.2[0.15, 0.24] 0.2[0.15, 0.24] 0.2[0.15, 0.24] 0.19[0.15, 0.24] 0.19[0.15, 0.23] 0.19[0.15, 0.23] 0.19[0.15, 0.23] 0.19[0.15, 0.23] 0.21[0.16, 0.25] 0.16[0.12, 0.21] 0.16[0.11, 0.2] 0.16[0.11, 0.2] 0.18[0.13, 0.22] 0.18[0.14, 0.22]

0.46[0.34, 0.58] 0.46[0.34, 0.58] 0.52[0.42, 0.62] 0.53[0.43, 0.63] 0.53[0.44, 0.63] 0.54[0.44, 0.63] 0.54 [0.44, 0.63] 0.53[0.44, 0.63] 0.54[0.44, 0.63] 0.53[0.44, 0.63] 0.53[0.44, 0.62] 0.53[0.44, 0.62] 0.53[0.44, 0.62] 0.55[0.42, 0.68] 0.54[0.41, 0.68] 0.54[0.41, 0.68] 0.55[0.41, 0.68] 0.55[0.41, 0.68] 0.55[0.42, 0.68] 0.55[0.41, 0.68] 0.55[0.42, 0.68] 0.55[0.41, 0.68] 0.55[0.42, 0.68] 0.54[0.43, 0.64] 0.54[0.43, 0.64] 0.54[0.43, 0.64] 0.54[0.43, 0.64] 0.52[0.43, 0.62] 0.54[0.44, 0.64] 0.54[0.45, 0.64] 0.54[0.45, 0.64] 0.55[0.45, 0.64] 0.55[0.45, 0.64] 0.55[0.45, 0.64] 0.55[0.47, 0.63] 0.56[0.48, 0.64] 0.56[0.48, 0.64] 0.56[0.48, 0.64] 0.56[0.48, 0.64] 0.56[0.48, 0.64] 0.55[0.47, 0.63] 0.55[0.47, 0.63] 0.55[0.47, 0.63] 0.55[0.47, 0.64] 0.55[0.47, 0.64] 0.55[0.47, 0.64] 0.56[0.48, 0.64] 0.56[0.47, 0.64] 0.56[0.47, 0.64] 0.56[0.48, 0.65] 0.56[0.48, 0.64] 0.56[0.48, 0.64] 0.56[0.49, 0.64] 0.56[0.49, 0.64] 0.56[0.49, 0.63] 0.54[0.47, 0.61] 0.54[0.46, 0.61] 0.54[0.46, 0.61] 0.54[0.47, 0.61] 0.54[0.47, 0.61] (Continues)

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

364

YIXIN BIAN ET AL.

Table VI. (Continued) Product

Release type

Release no

Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze Vuze KChart KChart KChart KChart KChart KChart KChart KChart KChart KChart KChart KChart KChart KChart KChart KChart KChart KChart KChart KChart KWord KWord KWord KWord KWord KWord KWord KWord KWord

Feature Feature Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Bug Feature Feature Bug Feature Bug Bug Bug Bug Feature Bug Bug Bug Bug Feature Bug Bug Feature Feature Feature Bug fix Feature Bug fix Bug fix Bug fix Bug fix Bug fix Feature Bug fix Bug fix Feature Bug fix Bug fix Feature Bug fix Bug fix Bug fix Feature Feature Feature Bug fix Feature Bug fix Bug fix Bug fix Bug fix

2.5.4 3.0.0.6 3.0.0.8 3.0.1.0 3.0.1.2 3.0.1.4 3.0.1.6 3.0.2.0 3.0.2.2 3.0.3.0 3.0.3.4 3.0.4.0 3.0.4.2 3.0.5.0 3.0.5.2 3.1.0.0 4.0.0.0 4.0.0.2 4.3.0.4 4.3.0.6 4.3.1.0 4.3.1.2 4.3.1.4 4.4.0.0 4.4.0.2 4.4.0.4 4.4.0.6 4.4.10 4.5.0.0 4.5.0.2 4.5.0.4 1.0 1.1 1.2 1.2.1 1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 1.4.0 1.4.1 1.4.2 1.5.0 1.5.1 1.5.2 1.6.0 1.6.1 1.6.2 1.6.3 1.0 1.1 1.2 1.2.1 1.3 1.3.1 1.3.2 1.3.3 1.3.4

CCBO

CDIT

0.33[0.3, 0.37] 0.33[0.3, 0.37] 0.34[0.3, 0.37] 0.34[0.3, 0.37] 0.34[0.3, 0.37] 0.34[0.3, 0.37] 0.34[0.3, 0.37] 0.34[0.3, 0.37] 0.33[0.3, 0.37] 0.33[0.3, 0.37] 0.33[0.3,0.37] 0.33[0.3, 0.37] 0.34[0.3,0.37] 0.34[0.3, 0.37] 0.34[0.31, 0.38] 0.34[0.31, 0.38] 0.35[0.32, 0.38] 0.35[0.32, 0.38] 0.36[0.32, 0.39] 0.36[0.33, 0.39] 0.36[0.33, 0.39] 0.36[0.33, 0.39] 0.36[0.33, 0.39] 0.36[0.33, 0.39] 0.36[0.33, 0.39] 0.36[0.33, 0.39] 0.36[0.33, 0.39] 0.36[0.32, 0.39] 0.36[0.32, 0.39] 0.36[0.32, 0.39] 0.36[0.33, 0.39] 0.37[0.24, 0.50] 0.52[0.42, 0.62] 0.47[0.38, 0.56] 0.47[0.38, 0.56] 0.52[0.44, 0.60] 0.52[0.44, 0.60] 0.52[0.42, 0.62] 0.52[0.42, 0.62] 0.52[0.42, 0.62] 0.52[0.42, 0.62] 0.51[0.43, 0.60] 0.51[0.43, 0.60] 0.51[0.42, 0.60] 0.51[0.43, 0.60] 0.51[0.43, 0.60] 0.51[0.43, 0.60] 0.51[0.42, 0.60] 0.52[0.42, 0.62] 0.52[0.42, 0.62] 0.52[0.42, 0.62] 0.17[0.07, 0.26] 0.14[0.06, 0.22] 0.19[0.13, 0.26] 0.19[0.13, 0.26] 0.31[0.27, 0.34] 0.31[0.27, 0.34] 0.31[0.27, 0.34] 0.31[0.27, 0.34] 0.31[0.27, 0.34]

0.7[0.66, 0.73] 0.7[0.66, 0.73] 0.7[0.67, 0.73] 0.7[0.67, 0.73] 0.7[0.67, 0.73] 0.7[0.67, 0.73] 0.7 [0.67, 0.73] 0.7[0.67, 0.73] 0.7 [0.67, 0.73] 0.7[0.67, 0.73] 0.7[0.67, 0.73] 0.7 [0.67,0.73] 0.7[0.67, 0.73] 0.71[0.68, 0.74] 0.71[0.68, 0.74] 0.71[0.68, 0.74] 0.71[0.68, 0.74] 0.71[0.68, 0.74] 0.72[0.69, 0.74] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69,0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.72[0.69, 0.75] 0.64[0.46, 0.81] 0.61[0.43, 0.79] 0.66[0.51, 0.81] 0.66[0.5, 0.82] 0.7[0.56, 0.84] 0.7[0.56, 0.84] 0.61[0.43, 0.79] 0.61[0.43, 0.79] 0.61[0.43, 0.79] 0.61[0.43, 0.79] 0.7[0.57, 0.83] 0.7[0.57, 0.83] 0.7[0.57, 0.83] 0.67[0.55, 0.8] 0.67[0.55, 0.8] 0.67[0.55, 0.8] 0.67[0.54, 0.8] 0.67[0.55, 0.79] 0.67[0.55, 0.79] 0.67[0.55, 0.79] 0.53[0.37, 0.68] 0.49[0.38, 0.60] 0.55[0.46, 0.65] 0.55[0.46, 0.65] 0.72[0.65, 0.78] 0.71[0.65, 0.78] 0.71[0.65, 0.78] 0.71[0.65, 0.78] 0.71[0.65, 0.78] (Continues)

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 365

Table VI. (Continued) Product

Release type

Release no

KWord KWord KWord KWord KWord KWord KWord KWord KWord KWord KWord Kivio Kivio Kivio Kivio Kivio Kivio Kivio Kivio Kivio Kivio Kivio Kivio Kivio Kivio Kivio Kivio Kivio Kivio Kivio KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KPresenter KSpread KSpread KSpread KSpread KSpread KSpread KSpread KSpread KSpread KSpread

Bug fix Feature Bug fix Bug fix Feature Bug fix Bug fix Feature Bug fix Bug fix Bug fix Feature Feature Bug fix Feature Bug fix Bug fix Bug fix Bug fix Bug fix Feature Bug fix Bug fix Feature Bug fix Bug fix Feature Bug fix Bug fix Bug fix Feature Feature Feature Bug fix Feature Bug fix Bug fix Bug fix Bug fix Bug fix Feature Bug fix Bug fix Feature Bug fix Bug fix Bug fix Bug fix Bug fix Bug fix Feature Feature Feature Bug fix Feature Bug fix Bug fix Bug fix Bug fix Bug fix

1.3.5 1.4.0 1.4.1 1.4.2 1.5.0 1.5.1 1.5.2 1.6.0 1.6.1 1.6.2 1.6.3 1.0 1.2 1.2.1 1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 1.4.0 1.4.1 1.4.2 1.5.0 1.5.1 1.5.2 1.6.0 1.6.1 1.6.2 1.6.3 1.0 1.1 1.2 1.2.1 1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 1.4.0 1.4.1 1.4.2 1.5.0 1.5.1 1.5.2 1.6.0 1.6.1 1.6.2 1.6.3 1.0 1.1 1.2 1.2.1 1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5

CCBO

CDIT

0.31[0.27, 0.34] 0.3[0.26, 0.33] 0.3[0.26, 0.33] 0.3[0.26, 0.33] 0.31[0.27, 0.34] 0.31[0.27, 0.34] 0.31[0.27, 0.34] 0.31[0.27, 0.34] 0.31[0.27, 0.34] 0.31[0.27, 0.34] 0.31[0.27, 0.34] 0.15[0.07, 0.23] 0.16[0.08, 0.24] 0.16[0.08, 0.24] 0.18[0.10, 0.26] 0.18[0.10, 0.26] 0.18[0.10, 0.26] 0.18[0.10, 0.26] 0.18[0.10, 0.26] 0.18[0.10, 0.26] 0.21[0.13, 0.29] 0.21[0.13, 0.29] 0.21[0.13, 0.29] 0.21[0.15, 0.29] 0.21[0.15, 0.29] 0.21[0.15, 0.29] 0.21[0.15, 0.29] 0.21[0.15, 0.29] 0.21[0.15, 0.29] 0.21[0.15, 0.29] 0.26[0.16, 0.36] 0.28[0.19, 0.37] 0.32[0.27, 0.37] 0.32[0.27, 0.37] 0.30[0.25, 0.36] 0.30[0.25, 0.36] 0.30[0.25, 0.36] 0.30[0.25, 0.36] 0.30[0.25, 0.36] 0.30[0.25, 0.36] 0.29[0.24, 0.34] 0.29[0.24, 0.34] 0.29[0.24, 0.34] 0.27[0.21, 0.32] 0.27[0.21, 0.32] 0.27[0.21, 0.32] 0.27[0.22, 0.32] 0.27[0.21, 0.32] 0.27[0.21, 0.32] 0.27[0.21, 0.32] 0.38[0.30, 0.46] 0.34[0.27, 0.42] 0.35[0.29, 0.41] 0.35[0.29, 0.41] 0.36[0.31, 0.41] 0.36[0.31, 0.41] 0.36[0.31, 0.41] 0.36[0.31, 0.41] 0.36[0.31, 0.41] 0.36[0.31, 0.41]

0.71[0.65, 0.78] 0.71[0.64, 0.78] 0.71[0.64, 0.78] 0.71[0.64, 0.78] 0.69[0.61, 0.77] 0.69[0.61, 0.77] 0.69[0.61, 0.77] 0.69[0.61, 0.77] 0.69[0.61, 0.77] 0.69[0.61, 0.77] 0.69[0.61, 0.77] 0.51[0.41, 0.61] 0.57[0.46, 0.69] 0.57[0.46, 0.69] 0.58[0.44, 0.71] 0.58[0.44, 0.72] 0.58[0.44, 0.72] 0.58[0.44, 0.72] 0.58[0.44, 0.72] 0.58[0.44, 0.72] 0.59[0.46, 0.72] 0.59[0.46, 0.72] 0.59[0.46, 0.72] 0.59[0.46, 0.72] 0.59[0.46, 0.72] 0.59[0.46, 0.72] 0.59[0.46, 0.72] 0.59[0.46, 0.72] 0.59[0.46, 0.72] 0.59[0.46, 0.72] 0.68[0.58, 0.78] 0.71[0.62, 0.81] 0.71[0.64, 0.77] 0.71[0.64, 0.77] 0.71[0.64, 0.77] 0.71[0.64, 0.77] 0.71[0.64, 0.77] 0.71[0.64, 0.77] 0.71[0.64, 0.77] 0.71[0.64, 0.77] 0.69[0.63, 0.76] 0.69[0.63, 0.76] 0.69[0.63, 0.76] 0.70[0.63, 0.77] 0.70[0.63, 0.77] 0.70[0.63, 0.77] 0.70[0.63, 0.77] 0.70[0.63, 0.77] 0.70[0.63, 0.77] 0.70[0.63, 0.77] 0.69[0.62, 0.77] 0.69[0.62, 0.76] 0.70[0.63, 0.77] 0.70[0.63, 0.77] 0.74[0.56, 0.91] 0.74[0.56, 0.91] 0.74[0.56, 0.91] 0.74[0.56, 0.91] 0.74[0.56, 0.91] 0.74[0.56, 0.91] (Continues)

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

366

YIXIN BIAN ET AL.

Table VI. (Continued) Product

Release type

Release no

KSpread KSpread KSpread KSpread KSpread KSpread KSpread KSpread KSpread KSpread

Feature Bug fix Bug fix Feature Feature Feature Feature Feature Feature Feature

1.4.0 1.4.1 1.4.2 1.5.0 1.5.1 1.5.2 1.6.0 1.6.1 1.6.2 1.6.3

CCBO

CDIT

0.34[0.28, 0.41] 0.34[0.28, 0.41] 0.34[0.28, 0.41] 0.36[0.31, 0.42] 0.36[0.31, 0.42] 0.36[0.31, 0.42] 0.36[0.31, 0.42] 0.36[0.31, 0.42] 0.36[0.31, 0.42] 0.36[0.31, 0.42]

0.74[0.59, 0.88] 0.74[0.59, 0.88] 0.74[0.59, 0.88] 0.76[0.63, 0.89] 0.76[0.63, 0.89] 0.76[0.63, 0.89] 0.76[0.63, 0.88] 0.76[0.63, 0.88] 0.76[0.63, 0.88] 0.76[0.63, 0.88]

CBO, Coupling Between Objects; DIT, Depth of Inheritance Tree.

Table VII. Selected examples of evidence about refactoring obtained from development logs. Product

Release No

Celestia 1.2.4

1.3.0 1.3.2 1.4.0

1.4.1 1.5.0

1.5.1

1.6.0 1.6.1 Cmake

Refactoring information

Website

This corresponds to the very latest SuSE http://sourceforge.net/mailarchive/forum. distribution (8.1), which underwent a large php?set = custom&vie wmonth = amount of restructuring. 200301&viewday = &forum_name = celestia-developers&style = nested&max_rows = 75&submit = Change + View Package reorganization: celestia is now the http://ftp master.metadata.debian.org/ KDE frontend changelogs/main/c/celestia / celestia_1.6.0 + dfsg-2_changelog Added lua scripting, cel urls, new settings http://sourceforge.net/mailarchive/forum.php manager, refactoring ? forum_name = cele stia-cvs&max_rows = 25&style = nested&viewmonth = 200412 I expect that this refactoring will be around for http://sourceforge.net/mailarchive/forum.php a while and that it will be smoother from now ? set = custom&viewmonth = 200512&vie on wday = &forum_name = celestiadevelopers&style = nested&max_rows = 75&submit = Change +View I do not understand what repos restructuring https://mailman.archlinux.org/pipermail/archhas to do here dev-public/2007-November.txt We should postpone any significant http://sourceforge.net/mailarchive/forum. restructuring until after 1.4.1 php?forum_name = celestia de velopers&max_rows = 25&offset = 9&style = nested&viewmonth = 200601 This change was primarily a refactoring to http://sf.lixin.me/apps/trac/celestia/changeset/ make future development easier and improve 4098 / trunk/celestia/src/celestia/favorites.cpp performance be eliminating redundant frame - > universal conversions of the observer position This topic will stay sticky for 2 weeks. After http://www.shatters.net/forum/viewtopic.php this time a decision will be made and the ? f = 2&t = 15370 restructuring will start. Code optimization and reorganization. http://www.shatters.net/celestia/161changes. txt I am not really sure that there is an identifiable from an email of its developer period of time in CMake’s history where little or no functional enhancement was made. CMake is constantly being enhanced in one way or another… redesign happens as we (Continues)

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 367

Table VII. (Continued) Product

Release No

HSQL

1.7.1 1.7.2

1.7.3

1.8.0 1.8.10 Hydrogen 0.9.3 0.9.4 0.9.5 Shareaza 2.1 2.2 2.3

2.4 2.5 2.5.3 2.5.5 Vuze

3.0.2.2

3.0.4.0

Refactoring information go, in smaller chunks, as needed for the most part. (1) Some structural changes without major functional change were made between v. 1.7.0 and 1.7.1 (you can find the tags in CVS repository). (2) Major restructuring has been performed all the time because those versions, but always as a rewrite of parts of the code to improve functionality. fredt@users 20020920 — patch 1.7.1 — refactoring to cut memory footprint There are lots of code enhancements which were originally developed for HyperXtremeSQL (http://www.hxsql.com). These include a rewritten implementation of Cache and related functionality and some refactorings aimed at better separation of concerns HSQL, codebase for transactions refactoring

fredt@users — 20050102 patch 1.8.0 — refactoring and clearer separation of concerns Raid refactoring for easier to extend

Website

An email of its developer

http://www.oschina.net/code/explore/hsqldb2.0.0/src/org/hsqldb/RowAVLDisk.java http://sourceforge.net/mailarchive/forum.php ? forum_name = hsqldbdevelopers&max_rows = 25&style = nested&viewmonth = 200501

http://sourceforge.net/mailarchive/forum. php?forum_name = hsqldb-devel opers&max_rows = 25&style = nested&viewmonth = 200502 http://kickjava.com/src/org/hsqldb/persist/ Log.java.htm https://github.com/rvadali/fb-raid-refactoring/ blob/master/lib/hsqldb-1.8.0.10.LICENSE. txt] http://blog.gmane.org/gmane.comp.audio. hydrogen.devel/month = 20091001/page = 10

I strongly believe in refactoring. However, I believe in refactoring done in small easy steps, not in total rewrites. 2007-09-08 Refactoring part II http://cgit.asynk.ch/cgi-bin/cgit/hydrogen/ log/extra/hydrogenSynth Jeremy cleaned up a lot of code and refactored http://blog.gmane.org/gmane.comp.audio. many classes. hydrogen.devel/page=11 Search/Search more code neatened up and http://sourceforge.net/apps/mediawiki/ improved. shareaza/index.php ? title = ChangeLog2.1 Renamed ‘Complete Files’ queue to ‘All [http://sourceforge.net/apps/mediawiki/ Files’ shareaza/index.php ? title = ChangeLog2.2 Redesigned multiply waiting-for-stop-and- http://sourceforge.net/apps/mediawiki/ terminate-thread-otherwise lines to single shareaza/index.php ? title = ChangeLog2.3 separate function CloseThread() and fixed thread handler leak in case of forcible termination. 3. Code: Refactored working thread code. http://sourceforge.net/apps/mediawiki/ Stage one: Network shareaza/index.php ? title = ChangeLog2.4 Redesigned BitTorrent tracker handling code [http://sourceforge.net/apps/mediawiki/ shareaza/index.php ? title = ChangeLog2.5 Optimized download status text code (in http://sf.lixin.me/apps/phpbb/shareaza/ download window and in remote interface) viewtopic.php ? f = 2&t = 748 1. Refactored chat code (removed/renamed http://sourceforge.net/apps/mediawiki/ chat window classes, fixed connection bugs, shareaza/index.php ? title = ChangeLog2.5.5 updated translations and skins) Because of refactoring, the Tracker Templates http://forums.whirlpool.net.au/archive/ and IRC have been moved to a separate 462471 plugin. This is it. Revised piece picking code to deal better with some edge cases and snubbed peers

(Continues)

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

368

YIXIN BIAN ET AL.

Table VII. (Continued) Product

Release No

3.1.0.0 4.0–4.1

4.1–4.2

4.2–4.3

4.4–4.5

Refactoring information

Website

http://wiki.vuze.com/w/ Version_3_Changelog#3.0.2.2_ _August_30.2C_2007 Column menu option to disable fast renaming http://forums.whirlpool.net.au/archive/ in files view, changed fast rename to behave 462471 more like the windows explorer. In Azureus (now called Vuze) 4.0 –4.1, there http://www.jot.fm/issues/issue_2012_08/ are 6526 classes; among them, 49 have had article7.pdf an add parameter refactoring and 38 have had a remove parameter refactoring. In Azureus (now called Vuze) 4.1 -4.2, there http://www.jot.fm/issues/issue_2012_08/ are 6892 classes; among them, 0 have had an article7.pdf add parameter refactoring and 20 have had a remove parameter refactoring. In Azureus (now called Vuze) 4.2 –4.3, there http://www.jot.fm/issues/issue_2012_08/ are 6447 classes; among them, 120 have had article7.pdf an add parameter refactoring and 79 have had a remove parameter refactoring. In Azureus (now called Vuze) 4.4 –4.5, there http://www.jot.fm/issues/issue_2012_08/ are 7270 classes; among them, 51 have had article7.pdf an add parameter refactoring and 27 have had a remove parameter refactoring.

Table VIII. Selected examples about evidence of refactoring from products where refactoring was applied intermittently. Product

Release No

Tellico

2.0

Lenya

1.2 2.0

Audacity 1.3.4 Findbugs 1.3.9

Refactoring information

Website

Image handling was refactored and should be significantly more robust Refactor the link detection so that the linkrewriter can be subclassed more easily. Refactoring: extracted method getExecutableEvent(). Refactoring of the TrackPanel, possibly as described in Track Panel Refactor. Lots of internal changes moving toward FindBugs 2.0, but these features are undocumented, not yet officially supported, and subject to radical changes before FindBugs 2.0 is released.

http://tellico-project.org/changelog http://lenya.apache.org/index/ changes/2005/01.html http://lenya.apache.org/index/ changes/2005/01.html http://sourcecodebrowser.com/ audacity/1.3.4/todo.html http://www.softpedia.com/ progChangelog/FindBugsChangelog-121743.html

ACKNOWLEDGEMENTS

We thank the associate editor and the anonymous reviewers for their useful and constructive feedback. This work was supported by the Nature Science Foundation of Heilongjiang Province, China (Nos. F201321 and F201231). REFERENCES 1. Koru AG, Emam KE. The theory of relative dependency: higher coupling concentration in smaller modules. IEEE Software 2010; 27(2):81–89. 2. Koru AG, Emam KE, Zhang D, Liu H, Mathew D. Theory of relative defect proneness. Empirical Software Engineering 2008; 13:473–498. 3. Koru AG, Liu H, Zhang D, Emam KE. Testing the theory of relative defect proneness for closed-source software. Empirical Software Engineering 2010; 15:577–598. Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 369 4. Card DN, Aggresti WW. Measuring software design complexity. Journal of Systems and Software 1988; 8(3):185–197. 5. Perry DE, Evangelist WM. An empirical study of software interface faults. Proceedings of the Twentieth Annual Hawaii International Conference on Systems Sciences, January 1987, Volume II, 1985; 113–126. 6. Perry DE. Programmer productivity in the inscape environment. The Proceedings of GLOBECOM 86, 1986; 428–434. 7. Perry DE, Evangelist WM. An empirical study of software interface faults – an update. In Twentieth Annual Hawaii International Conference on Systems Sciences (HICSS-20), 2, 1987; 113–126. 8. Perry DE, Stieg CS. Software faults in evolving a large, real-time system: a case study. In 4th European Software Engineering Conference – ESEC93, 1993; 48–67. 9. Basili VR, Perricone BT. Software errors and complexity: an empirical investigation. Communications of the ACM 1984; 27(1):42–52. 10. Basili VR, Briand LC, Melo WL. A validation of object-oriented design metrics as quality indicators. IEEE Transactions on Software Engineering 1996; 22(10):751–761. 11. Briand LC, Wst J, Daly JW, Porter DV. Exploring the relationships between design measures and software quality in object-oriented systems. Journal of Systems and Software 2000; 51(3):245–273. 12. Drucker PF. Management Challenges for the 21st Century. Routledge: London, England, 2000. 13. Humphrey WS. TSP: Leading a Development Team. Pearson Education: New York, USA, 2006. 14. Humphrey WS. TSP(SM) Coaching Development Teams. Pearson Education: New York, USA, 2006. 15. Popper K. The Logic of Scientific Discovery, 2nd edn. Routledge Classics: London, England, 1959, Reprint 2007. 16. Shull F, Carver J, Travassos GH, Maldonado JC, Conradi R, Basili VR. Replicated studies: building a body of knowledge about software reading techniques. Lecture notes on empirical software engineering. World Scientific Publishing Co., Inc: Singapore, 2003; 39–84. 17. Lindsay RM, Ehrenberg ASC. The design of replicated studies. The American Statistician 1993; 47(3):217–228. 18. Lehman MM. On understanding laws, evolution, and conservation in the large-program life cycle. Journal of Systems and Software 1984; 1:213–221. 19. MacCormack A, Rusnak J, Baldwin CY. The impact of component modularity on design evolution: evidence from the software industry. Harvard Business School Technology & Operations Mgt. Unit Research Paper, No. 08-038, 2007. 20. Parande MA, Koru AG. A longitudinal analysis of the dependency concentration in smaller modules for open-source software products. IEEE International Conference on Software Maintenance (ICSM), 2010; 1–5. 21. Godfrey MW, German DM. The past, present, and future of software evolution. Frontiers of Software Maintenance, 2008; 129–138. 22. Belady LA, Lehman MM. A model of large program development. IBM Systems Journal 1976; 15(3): 225–252. 23. Endres A, Rombach D. A Handbook of Software and Systems Engineering: Empirical Observations, Laws and Theories. Addison Wesley: Boston, MA, USA, 2003. 24. Gall H, Jazayeri M, Klsch RR, Trausmuth G. Software evolution observations based on product release history. Proceedings of the international conference on software maintenance, 1997; 160–166. 25. Godfrey MW, Tu Q. Evolution in open source software: a case study. International Conference on Software Maintenance, 2000; 131–142. 26. Mens T, Wermelinger M, Ducasse S, et al. Challenges in software evolution. Proceedings of the Eighth International Workshop on Principles of Software Evolution, 2005; 13–22. 27. Li W, Delugach H. Software metrics and application domain complexity. Asia Pacific and International Computer Science Conference, 1997; 513–514. 28. Lehman MM. Laws of software evolution revisited. Proceedings of the 5th European Workshop on Software Process Technology, 1996; 108–124. 29. Lehman MM, Ramil JF. Software evolution: background, theory, practice. Information Processing Letters 2003; 88:33–44. 30. Liu H, Ma Z, Shao W, Niu Z. Schedule of Bad smell detection and resolution: a new way to save effort. IEEE Transactions on Software Engineering 2012; 38:220–235. 31. Bourqun F, Keller RK. High-impact refactoring based on architecture violations. Proceedings of the 11th European Conference on Software Maintenance and Reengineering, 2007; 149–158. 32. Fowler M. Refactoring: Improving the Design of Existing Code. Addison Wesley: Boston, MA, USA, 1999. 33. Gall H, Hajek K, Jazayeri M. Detection of logical coupling based on product release history. Proceedings of the International Conference on Software Maintenance, 1998; 190–198. 34. Erb S. A survey of software refactoring tools. Master’s thesis, Baden-Wrttemberg Cooperative State University, Karlsruhe, 2010. 35. Opdyke WF. Refactoring: a program restructuring aid in designing object- oriented application frameworks. PhD thesis, University of Illinois at Urbana- Champaign, 1992. 36. Kim M, Zimmermann T, Nagappan N. A field study of refactoring challenges and benefits. Proceedings of the 20th International Symposium on Foundations of Software Engineering, November 2012; 50:1–50:11. 37. MacCormack A, Rusnak J, Baldwin CY. Exploring the structure of complex software designs: an empirical study of open source and proprietary code. Management Science 2006; 52:1015–1030.

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

370

YIXIN BIAN ET AL.

38. Gyimothy T, Ferenc R, Siket I. Empirical validation of object-oriented metrics on open source software for fault prediction. IEEE Transactions on Software Engineering 2005; 31:897–910. 39. Banker RD, Datar SM, Kemerer CF, Zweig D. Software complexity and maintenance costs. Communications of the ACM 1993; 36:81–94. 40. Koru G, Liu H. Identifying and characterizing change-prone classes in two large-scale open-source products. Journal of Systems and Software 2007; 80(1):63–73. 41. Selby RW, Basili VR. Analyzing error-prone system structure. IEEE Transactions on Software Engineering 1991; 17 (2):141–152. 42. Schneidewind NF. Methodology for validating software metrics. IEEE Transactions on Software Engineering 1992; 18(5):410–422. 43. Offutt J, Abdurazik A, Schach SR. Quantitatively measuring object-oriented couplings. Software Quality Control 2008; 16(4):489–512. 44. Emam KE, Benlarbi S, Goel N, Rai SN. The confounding effect of class size on the validity of object-oriented metrics. IEEE Transactions on Software Engineering 2001; 27(7):630–650. 45. Xu J, Ho D, Capretz LF. An empirical validation of object-oriented design metrics for fault prediction. Journal of Computer Science 2008; 4(7):571–577. 46. Syer MD, Adams B. Replicating and revaluating the theory of relative defect-proneness. IEEE Transactions on Software Engineering 2015; 41(2):176–197. 47. D’Ambros M, Lanza M, Robbes R. On the relationship between change coupling and software defects. 6th Working Conference on Reverse Engineering, 2009; 135–144. 48. Hall T, Beecham S, Bowes D, Gray D, Counsell S. A systematic literature review on fault prediction performance in software engineering. IEEE Transactions on Software Engineering 2012; 38(6):1276–1304. 49. Bird C, Nagappan N, Gall H, Murphy B, Devanbu P. Putting it all together: using socio-technical networks to predict failures. 20th International Symposium on Software Reliability Engineering, 2009; 109–119. 50. Nagappan M, Zimmermann T, Bird C. Diversity in software engineering research. Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering, ESEC/FSE, New York, USA, 2013. ACM; 466–476. 51. Inc Scientific Toolworks. Understand for C++: user guide and reference manual. Technical report, Scientific Toolworks, Inc., 2003. 52. Chidamber SR, Kemerer CF. Towards a metrics suite for object oriented design. ACM SIGPLAN Notices 1991; 26:197–211. 53. Chidamber SR, Darcy DP, Kemerer CF. Managerial use of metrics for object-oriented software: an exploratory analysis. IEEE Transactions on Software Engineering 1998; 24(8):629–639. 54. Subramanyam R, Krishnan MS. Empirical analysis of CK metrics for object-oriented design complexity: implications for software defects. IEEE Transactions on Software Engineering 2003; 29(4):297–310. 55. Burrows R, Ferrari FC, Lemos OAL et al. The impact of coupling on the fault-proneness of aspect-oriented programs: an empirical study. IEEE 21st International Symposium on Software Reliability Engineering (ISSRE), Nov 2010; 329–338. 56. Giger E, Pinzger M, Gall HC. Can we predict types of code changes: an empirical analysis. 9th IEEE Working Conference on Mining Software Repositories (MSR), June 2012; 217–226. 57. Chidamber SR, Kemerer CF. A metrics suite for object oriented design. IEEE Transactions on Software Engineering 1994; 20(6):476–493. 58. Krishnapriya V, Ramar K. Exploring the difference between object oriented class inheritance and interfaces using coupling measures. International Conference on Advances in Computer Engineering (ACE), 2010; 207–211. 59. Kung D, Gao J, Hsia P et al. Change impact identification in object oriented software maintenance. Proceedings International Conference on Software Maintenance, 1994; 202–211. 60. Wilde N, Huitt R. Maintenance support for object-oriented programs. IEEE Transactions on Software Engineering 1992; 18:1038–1044. 61. Selvarani R, Nair TRG, Prasad VK. Estimation of defect proneness using design complexity measurements in objectoriented software. International Conference on Signal Processing Systems, 2009; 766–770. 62. Menzies T, Butcher A, Cok D, et al. Local versus global lessons for defect prediction and effort estimation. IEEE Transactions on Software Engineering June 2013; 39(6):822–834. 63. Okutan A, Yıldız OT. Software defect prediction using Bayesian networks. Empirical Software Engineering 2012; 19(1):154–181. 64. Gordon JS, Roggio RF. A comparison of software testing using the object oriented paradigm and traditional testing. Journal of Information Systems Applied Research 2014; 7(2):39–49. 65. Boehm B, Clark B, Horowitz E, et al. Cost models for future software life cycle processes: COCOMO 2.0. Annals of Software Engineering 1995; 1:57–94. 66. Koru AG, Liu H. Building effective defect-prediction models in practice. IEEE Software 2005; 22(6):23–29. 67. Wagstaff A, Paci P, van Doorslaer E. On the measurement of inequalities in health. Social Science & Medicine 1991; 33(5):545–557. 68. Kakwani N, Wagstaff A, Doorslaer EV. Socioeconomic inequalities in health: measurement, computation, and statistical inference. Journal of Econometrics 1997; 77(1):87–103. 69. Robles G, Koch S, Gonzlez-Barahona JM. Remote analysis and measurement of libre software systems by means of the CVSAnalY tool. IET Conference Proceedings, January 2004; 51–55. Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr

TESTING THE THEORY OF RELATIVE DEPENDENCY FROM AN EVOLUTIONARY PERSPECTIVE 371 70. Vasa R, Lumpe M, Branch P, Nierstrasz O. Comparative analysis of evolving software systems using the gini coefficient. IEEE International Conference on Software Maintenance, ICSM, Sept 2009; 179–188. 71. Vasilescu B, Serebrenik A, van den Brand M. You can’t control the unfamiliar: a study on the relations between aggregation techniques for software metrics. 27th IEEE International Conference on Software Maintenance (ICSM), 2011; 313–322. 72. O’Donoghue T, Punch K. Qualitative Educational Research in Action Doing and Reflecting. RoutledgeFalmer: London, 2003. 73. Prete K, Rachatasumrit N, Sudan N, Kim M. Template-based reconstruction of complex refactorings. The 26th IEEE International Conference on Software Maintenance, September, 2010. 74. Fenton N, Bieman J. Software Metrics: A Rigorous and Practical Approach, 2nd edn. CRC Press: Boston, 1996. 75. van der Meulen MJP, Revilla MA. Correlations between internal software metrics and software dependability in a large population of small C/C++ programs. 18th IEEE International Symposium on Software Reliability Engineering. IEEE, 2007; 203–208. 76. Fishbein M, Ajzen I. Belief, Attitude, Intention and Behavior: An Introduction to Theory and Research. AddisonWesley: Boston, MA, USA, 1975. 77. Rogers EM. Diffusion of Innovations, 5th edn. Free Press: New York, 2003. 78. Murphy-Hill E, Parnin C, Black AP. How we refactor, and how we know it. Proceedings of the 31st International Conference on Software Engineering, ICSE, Washington, DC, USA, 2009; 287–297. 79. Emam KE, Melo W, Machado JC. The prediction of faulty classes using object-oriented design metrics. Journal of Systems and Software 2001; 56(1):63–75. 80. Lindvall M. Are large C++ classes change prone? Software Practice and Experience 1998; 28:1551–1558. 81. Nagappan N, Ball T. Use of relative code churn measures to predict system defect density. Proceedings of the 27th International Conference on Software Engineering, ICSE. ACM, 2005; 284–292. 82. Deursen AV, Moonen L. The video store revisited thoughts on refactoring and testing. Third Int’l Conference eXtreme Programming and Flexible Processes in Software Engineering, 2002; 71–76.

Copyright © 2016 John Wiley & Sons, Ltd.

J. Softw. Evol. and Proc. 2016; 28:340–371 DOI: 10.1002/smr