Today, refactoring reconstruction techniques are snapshot-based: they compare two revisions from a source code management system and calculate the shortest path of edit operations to go from the one to the other. An inherent risk with snapshot-based approaches is that a refactoring may be concealed by later edit operations acting on the same source code entity, a phenomenon we call refactoring masking. In this paper, we performed an experiment to find out at which point refactoring masking occurs and confirmed that a snapshot-based technique misses refactorings when several edit operations are performed on the same source code entity. We present a way of reconstructing refactorings using fine grained changes that are recorded live from an integrated development environment and demonstrate on two cases ---PMD and Cruisecontrol--- that our approach is more accurate in a significant number of situations than the state-of-the-art snapshot-based technique RefFinder.
Incremental Mutation Testing attempts to make mutation testing less expensive by applying it incrementally to a system as it evolves. This approach fits current trends of iterative software development with the main idea being that by carrying out mutation analysis in frequent bite-sized chunks focused on areas of the code which have changed, one can build confidence in the adequacy of a test suite incrementally. Yet this depends on how precisely one can characterise the effects of a change to a program. The original technique uses a naive approach whereby changes are characterised only by syntactic changes. In this paper we propose bolstering incremental mutation testing by using control flow analysis to identify semantic repercussions which a syntactic change will have on a system. Our initial results based on two case studies demonstrate that numerous relevant mutants which would have otherwise not been considered using the naive approach, are now being generated. However, the cost of identifying these mutants is significant when compared to the naive approach, although it remains advantageous when compared to traditional mutation testing so long as the increment is sufficiently small.
The paper presents the first empirical study to examine econometric time series volatility modeling in the software evolution context. The econometric volatility concept is related to the conditional variance of a time series rather than the conditional mean targeted in conventional regression analysis. The software evolution context is motivated by relating these variance characteristics to the proximity of operating system releases, the theoretical hypothesis being that volatile characteristics increase nearby new milestone releases. The empirical experiment is done with a case study of FreeBSD. The analysis is carried out with 12 time series related to bug tracking, development activity, and communication. A historical period from 1995 to 2011 is covered under a daily sampling frequency. According to the results the time series dataset contains visible volatility characteristics, but these cannot be explained by the time windows around the six observed major FreeBSD releases. The paper consequently contributes to the software evolution research field with new methodological ideas, as well as with both positive and negative empirical results.
With the advent of agile processes and their emphasis on continuous integration, automated tests became the prominent driver of the development process. When one of the thousands of tests fails, the corresponding fault should be localised as quickly as possible as development can only proceed when the fault is repaired. In this paper we propose a heuristic named SPEQTRA which mines the execution traces of a series of passing and failing tests, to localise the class which contains the fault. SPEQTRA produces ranking of classes that indicates the likelihood of classes to be at fault. We compare our spectrum based fault localisation heuristic with the state of the art (AMPLE) and demonstrate on a small yet representative case (NanoXML) that the ranking of classes proposed by SPEQTRA is significantly better than the one of AMPLE.
Evolving an Application Programming Interface (API) is a delicate activity, as modifications to them can significantly impact their users. The increasing use of APIs means that software development organisations must take an empirical and scientific approach to the way they manage the evolution of their APIs. If no attempt at analysing or quantifying the evolution of an API is made, there will be a diminished understanding of the evolution, and possible improvements to the maintenance strategy will be difficult to identify. We believe that long-standing software evolution theories can provide additional insight to the field of APIs, and can be of great use to companies maintaining APIs. In this case study, we conduct a qualitative investigation to understand what drives the evolution of an industry company's existing API, by examining two versions of the API interface. The changes were analysed based on two software evolution theories, and the extent to which we could reverse engineer the change decisions was determined by interviewing an architect of the API. The results of this analysis show that the largest driving force of the APIs evolution was the desire for new functionality. Our findings which show that changes happen sporadically, rather than continuously, appear to show that the law of Conservation of Organisational Stability was not a considerable factor for the evolution of the API. We also found that it is possible to reverse engineer change decisions and in doing so, identified that the feedback loop of an API is an important area of improvement.
It is established that the internal quality of software is a key determinant of the total cost of ownership of that software. The objective of this research is to determine the impact that the development team’s size has on the internal structural attributes of a codebase and, in doing so, we consider the impact that the team’s size may have on the internal quality of the software that they produce. In this paper we leverage the wealth of data available in the open-source domain by mining detailed data from 1000 projects in GoogleCode and, coupled with one of the most established of object-oriented metric suites, we isolate and identify the effect that the development team size has on internal structural attributes of the software produced. We will find that some measures of functional decomposition are enhanced when we compare projects authored by fewer developers against those authored by a larger number of developers while measures of cohesion and complexity are degraded.
This paper proposes a method of estimating a product evolution graph based on Kolmogorov complexity. The method EEGL applies lossless compression to the source code of products, then, presumes a derivation relationship between two products when the increase of information between the two products is small. An evaluation experiment confirms that EEGL and an existing method PRET tends to produce different errors when estimating evolution graph results.
It is often observed that the majority of the development work of an Open Source Software (OSS) project is contributed by a core team, i.e., a small subset of the pool of active devel- opers. In fact, recent work has found that core development teams follow the Pareto principle — roughly 80% of the code contributions are produced by 20% of the active developers. However, those findings are based on samples of between one and nine studied systems. In this paper, we revisit prior studies about core developers using 2,496 projects hosted on GitHub. We find that even when we vary the heuristic for detecting core developers, and when we control for system size, team size, and project age: (1) the Pareto principle does not seem to apply for 40%-87% of GitHub projects; and (2) more than 88% of GitHub projects have fewer than 16 core developers. Moreover, we find that when we control for the quantity of contributions, bug fixing accounts for a similar proportion of the contributions of both core (18%-20%) and non-core developers (21%-22%). Our findings suggest that the Pareto principle is not compatible with the core teams of many GitHub projects. In fact, several of the studied GitHub projects are susceptible to the “bus factor,” where the impact of a core developer leaving would be quite harmful.
In software configuration management using a version control system, developers have to follow the commit policy of the project. However, preparing changes according to the policy are sometimes cumbersome and time-consuming, in particular when applying large refactoring consisting of multiple primitive refactoring instances. In this paper, we propose a technique for re-organizing changes by recording editing operations of source code. Editing operations including refactoring operations are hierarchically managed based on their types provided by an integrated development environment. Using the obtained hierarchy, developers can easily configure the granularity of changes and obtain the resulting changes based on the configured granularity. We confirmed the feasibility of the technique by applying it to the recorded changes in a large refactoring process.
Design degradation has long been assessed by means of structural analyses applied on successive versions of a software system. More recently, repository mining techniques have been developed in order to uncover rich historical information of software projects. In this paper, we leverage such information and propose an approach to assess design degradation that is programming language agnostic and relies almost exclusively on commit metadata. Our approach currently focuses on the assessment of two particular design smells: rigidity and fragility. Rigidity refer to designs that are difficult to change due to ripple effects and fragility refer to designs that tend to break in different areas every time a change is performed. We conducted an evaluation of our approach in the project Apache Maven 1 and the results indicated that our approach is feasible and that the project suffered from increasing fragility.
While requirements for open source projects originate from a variety of sources like e.g. mailing lists or blogs, typically, they eventually end up as feature requests in an issue tracking system. When analyzing how these issue trackers are used for requirements evolution, we witnessed a high percentage of duplicates in a number of high-prole projects. Further investigation of six open source projects and their users led us to a number of important observations and a categorization of the root causes of these duplicates. Based on this, we propose a set of improvements for future issue tracking systems.
Previous research efforts have proposed various techniques for supporting code clone removal. They identify removal candidates based on the states of the source code in the latest version. However, those techniques suggest many code clones that are not suited for removal in addition to appropriate candidates. That is because the presence of code clones do not necessarily motivate developers to remove them if they are stable and do not require simultaneous modifications. In this paper, we propose a new technique that identifies removal candidates based on past records of code modifications. By using the proposed technique, we can identify code clones that actually required simultaneous modifications in the past.
Multi-tenant systems represent a class of software-as-a-service (SaaS) applications in which several groups of users, i.e. the tenants, share the same resources. This resource sharing results in multiple business organizations using the same base application, yet, requiring specific adaptations or extensions for their specific business models. Each configuration must be tended to during evolution of a multi-tenant system, because the existing application is mended, or because new tenants request additional features. In order to facilitate the understanding of multi-tenant systems, we propose to use a runtime topology augmented with user and version information, to help understand usage patterns exhibited by tenants of the different components in the system. We introduce Serviz, our implementation of the augmented runtime topology, and evaluate it through a field user study to see to which extent Serviz aids in the analysis and understanding of a multi-tenant system.
Many researchers have conducted a variety of research related to clone evolution. In order to grasp how clones have evolved, clones must be tracked. However, conventional clone tracking techniques are not feasible to track clones if they moved to another location in the source code. Consequently, in this research, we propose a new clone tracking technique. The proposed technique is an enhanced version of clone tracking with clone region descriptor (CRD) proposed by Duala-Ekoko and Robillard. The proposed technique can track clones even if they moved to another location. We have implemented a software tool based on the proposed technique, and applied it to two open source systems. In the experiment, we confirmed that the proposed technique could track 44 clone groups, which the conventional CRD tracking could not track. The accuracy of the tracking for those clones was 91%.
Computer games are a genre of software systems that in many ways differs from more traditional applications. In particular, when designing games, the end result of game development resembles work of art rather than that of engineering, emphasizing the need for creativity and artistic abilities. However, as technology, tools, methods, and artifacts that are used in the development of games are to a large extent similar to those used in the development of more traditional system, games should conform to the basic laws of software, including software evolution. In this paper, we reflect the principles of software evolution distilled by Manny Lehman in the form of laws of software evolution to the game domain. We present how the laws can be interpreted and applied in games projects, and argue that many of the laws apply to many games, but not all laws apply to all games. The way the game is evolved especially has an effect on the applicable laws as changes in games can be emerging, reactive or pre-planned.
Understanding and minimizing the impact of software changes on performance are both challenging and essential when developing software. Unfortunately, current code execution profilers do not offer efficient abstractions and adequate representations to keep track of performance across multiple versions. Consequently, understanding the cause of a slow execution stemming from a software evolution is often realized in an ad hoc fashion. We have designed Rizel, a code profiler that identifies the root of performance variations thanks to an expressive and intuitive visual representation. Rizel highlights variation of executions and time distribution between multiple software versions. Rizel is available for the Pharo programming language under the MIT License.
Model-driven engineering (MDE) is a software engineering discipline focusing on models as the primary artifacts in the software development process while programs are mainly generated by means of model-to-code transformations. In particular, modeling languages tailored to specific application domains promise to increase the productivity and quality of software development. Nevertheless due to e.g. evolving requirements, modeling languages and their meta-models evolve which means that existing models have to be migrated correspondingly. In our approach, such co-evolutions are specified as related graph transformations ensuring well-typed model migration results. Based on our earlier work on co-transformations, we now consider the automatic deduction of migration rule schemes from given meta-model evolution rules. Rule schemes form the basis for user customizations on a high abstraction level. A rule scheme deduction algorithm is presented and several customized migration schemes for different co-evolution examples are discussed.
Characterising and measuring software developed in multiple languages is a problem for practitioners. Rather than a language-based approach, we avoid difficulties related to syntax, semantics and language paradigms by looking directly at relative shared information content to perform these tasks. Measuring, for each language, the relative number of bits of shared binary information between artefacts representative of consecutive releases of the project using a common tool permits the direct comparison of evolution results for the multiple languages. This paper presents a case study of the program suite called git, written in C, perl and Bourne shell. The study uses this method to show that, for git, code in scripting languages does not prototype later C, Bourne shell and C code are written together and that the languages' code contributions occur concurrently.
Much work has been done on the subject of what happens to software architecture during maintenance activities. There seems to be a consensus that it degrades during the evolution of the software. More recent work shows that this degradation occurs even during development activities: design decisions are either adjusted or forgotten. Some studies have looked into the causes of this degradation, but these have mostly done so at a very high level. This study examines three projects at code level. Three architectural pre-implementation designs are compared with their post-implementation design counterparts, with special attention paid to the causes of the changes. We found many negative changes causing anti-patterns, at the package, class, and method levels. After analysis of the code, we were able to find the specific reasons for the poor design decisions. Although the underlying causes are varied, they can be grouped into three basic categories: knowledge problems, artifact problems, and management problems. This categorization shows that anti-pattern causes are varied and are not all due to the developers. The main conclusion is that promoting awareness of anti-patterns to developers is insufficient to prevent them since some of the causes escape their grasp.
