Mgj Mark van den Brand

Process Mining Software Repositories

Software developers’ activities are in general recorded in software repositories such as version control systems, bug trackers and mail archives. While abundant information is usually present in such repositories, successful information extraction is often challenged by the necessity to simultaneously analyze different repositories and to combine the information obtained. We propose to apply process mining techniques, originally developed for business process analysis, to address this challenge. However, in order for process mining to become applicable, different software repositories should be combined, and “related” software development events should be matched: e.g., mails sent about a file, modifications of the file and bug reports that can be traced back to it. The combination and matching of events has been implemented in FRASR (Framework for Analyzing Software Repositories), augmenting the process mining framework ProM. FRASR has been successfully applied in a series of case studies addressing such aspects of the development process as roles of different developers and the way bug reports are handled.

Theil index for aggregation of software metrics values

We propose a new approach to aggregating software metrics from the micro-level of individual artifacts (e.g., methods, classes and packages) to the macro-level of the entire software system. The approach, Theil index, is a well-known econometric measure of inequality. The Theil index allows to study the impact of different categorizations of the artifacts, e.g., based on the development technology or developers teams, on the inequality of the metrics values measured. We apply the Theil index in a series of experiments. We have observed that the Theil index and the related notions provide valuable insights in organization and evolution of software systems, as well as in sources of inequality.

You can't control the unfamiliar: A study on the relations between aggregation techniques for software metrics

A popular approach to assessing software maintainability and predicting its evolution involves collecting and analyzing software metrics. However, metrics are usually defined on a micro-level (method, class, package), and should therefore be aggregated in order to provide insights in the evolution at the macro-level (system). In addition to traditional aggregation techniques such as the mean, median, or sum, recently econometric aggregation techniques, such as the Gini, Theil, Kolm, Atkinson, and Hoover inequality indices have been proposed and applied to software metrics. In this paper we present the results of an extensive correlation study of the most widely-used traditional and econometric aggregation techniques, applied to lifting SLOC values from class to package level in the 106 systems comprising the Qualitas Corpus. Moreover, we investigate the nature of this relation, and study its evolution on a subset of 12 systems from the Qualitas Corpus. Our results indicate high and statistically significant correlation between the Gini, Theil, Atkinson, and Hoover indices, i.e., aggregation values obtained using these techniques convey the same information. However, we discuss some of the rationale behind choosing between one index or another.

Who's who in Gnome: Using LSA to merge software repository identities

Understanding an individuals contribution to an ecosystem often necessitates integrating information from multiple repositories corresponding to different projects within the ecosystem or different kinds of repositories (e.g., mail archives and version control systems). However, recognising that different contributions belong to the same contributor is challenging, since developers may use different aliases. It is known that existing identity merging algorithms are sensitive to large discrepancies between the aliases used by the same individual: the noisier the data, the worse their performance. To assess the scale of the problem for a large software ecosystem, we study all Gnome Git repositories, classify the differences in aliases, and discuss robustness of existing algorithms with respect to these types of differences. We then propose a new identity merging algorithm based on Latent Semantic Analysis (LSA), designed to be robust against more types of differences in aliases, and evaluate it empirically by means of cross-validation on Gnome Git authors. Our results show a clear improvement over existing algorithms in terms of precision and recall on worst-case input data.

Using Metrics for Assessing the Quality of ASF+SDF Model Transformations

Model transformations are an essential part of Model Driven Engineering and are in many ways similar to traditional software artifacts. Therefore it is necessary to define and evaluate the quality of model transformations. We propose a set of six quality attributes to evaluate the quality of model transformations. We define 27 metrics for ASF+SDF model transformations to predict the quality attributes we propose. Metrics data has been collected from six heterogeneous model transformations automatically. The quality of the same transformations has been evaluated manually by several ASF+SDF experts. We assess whether the automatically collected metrics are appropriate predictors for the quality attributes by correlating the metrics data with the expert data. Based on the measurement results, we identify a set of predicting metrics for each of the quality attributes for model transformations.

Eclipse API usage: the good and the bad

Today, when constructing software systems, many developers build their systems on top of frameworks. Eclipse is such a framework that has been in existence for over a decade. Like many other evolving software systems, the Eclipse platform has both stable and supported interfaces (“good”) and unstable, discouraged and unsupported interfaces (“bad”). In this study, we investigate Eclipse interface usage by Eclipse third-party plug-ins (ETPs) based on whether they use bad interfaces or not. The investigations, based on empirical analysis present the following observations. First, we discovered that 44xa0% of the 512 analyzed Eclipse third-party plug-ins depend on “bad” interfaces and that developers continue to use “bad” interfaces. Second, we have observed that plug-ins that use or extend at least one “bad” interface are comparatively larger and use more functionality from Eclipse than those that use only “good” interfaces. Third, the findings show that the ETPs use a diverse set of “bad” interfaces. Fourth, we observed that the reason why the bad interfaces are being eliminated from the ETPs’ source code is, because (ETP developers believe) these non-APIs will cause incompatibilities when a version of the ETP is ported to new Eclipse SDK release. Finally, we observed that when developers eliminate problematic “bad” interfaces, they either re-implement the same functionality in their own API, find equivalent SDK good interfaces, or completely delete the entities in the ETPs’ source code that use the functionality from the “bad” interfaces.

Continuous Integration in a Social-Coding World: Empirical Evidence from GitHub

Continuous integration is a software engineering practice of frequently merging all developer working copies with a shared main branch, e.g., several times a day. With the advent of GitHub, a platform well known for its social coding features that aid collaboration and sharing, and currently the largest code host in the open source world, collaborative software development has never been more prominent. In GitHub development one can distinguish between two types of developer contributions to a project: direct ones, coming from a typically small group of developers with write access to the main project repository, and indirect ones, coming from developers who fork the main repository, update their copies locally, and submit pull requests for review and merger. In this paper we explore how GitHub developers use continuous integration as well as whether the contribution type (direct versus indirect) and different project characteristics (e.g., main programming language, or project age) are associated with the success of the automatic builds.

Model transformation analysis: staying ahead of the maintenance nightmare

Model-driven engineering (MDE) is a software engineering discipline that is gaining popularity, both in academia and industry. One of the integral concepts of MDE is model transformation. The prominent role of model transformations in MDE requires them to be treated in a similar way as traditional software artifacts. Numerous analysis techniques supporting the maintenance process exist for traditional software artifacts. However, few techniques tailored towards analyzing model transformations currently exist. We present in this paper three complementary techniques for the analysis of model transformations. These techniques are mainly focused on increasing the understanding of model transformations. Two of the proposed techniques have already been employed for the analysis of different kinds of software artifacts, viz. metrics, and structure and trace analysis. The third analysis technique, i.e., metamodel coverage analysis is specific for model transformations and does therefore not exist for different kinds of software artifacts.

An exercise in iterative domain-specific language design

We describe our experiences with the process of designing a domain-specific language (DSL) and corresponding model transformations. The simultaneous development of the language and the transformations has lead to an iterative evolution of the DSL. We identified four main influences on the evolution of our DSL: the problem domain, the target platforms, model quality, and model transformation quality.n Our DSL is aimed at modeling the structure and behavior of distributed communicating systems. Simultaneously with the development of our DSL, we implemented three model transformations to different formalisms: one for simulation, one for execution, and one for verification. Transformations to each of these formalisms were implemented one at the time, while preserving the validity of the existing ones. The DSL and the formalisms for simulation, execution, and verification have different semantic characteristics. We also implemented a number of model transformations that bridge the semantic gaps between our DSL and each of the three formalisms. In this paper, we describe our development process and how the aforementioned influences have caused our DSL to evolve.

By no means: a study on aggregating software metrics

Fault prediction models usually employ software metrics which were previously shown to be a strong predictor for defects, e.g., SLOC. However, metrics are usually defined on a microlevel (method, class, package), and should therefore be aggregated in order to provide insights in the evolution at the macro-level (system). In addition to traditional aggregation techniques such as the mean, median, or sum, recently econometric aggregation techniques, such as the Gini, Theil, and Hoover indices have been proposed. In this paper we wish to understand whether the aggregation technique influences the presence and strength of the relation between SLOC and defects. Our results indicate that correlation is not strong, and is influenced by the aggregation technique.