Marco Tulio Valente

Extracting relative thresholds for source code metrics

Establishing credible thresholds is a central challenge for promoting source code metrics as an effective instrument to control the internal quality of software systems. To address this challenge, we propose the concept of relative thresholds for evaluating metrics data following heavy-tailed distributions. The proposed thresholds are relative because they assume that metric thresholds should be followed by most source code entities, but that it is also natural to have a number of entities in the “long-tail” that do not follow the defined limits. In the paper, we describe an empirical method for extracting relative thresholds from real systems. We also report a study on applying this method in a corpus with 106 systems. Based on the results of this study, we argue that the proposed thresholds express a balance between real and idealized design practices.

Extracting Software Product Lines: A Case Study Using Conditional Compilation

Software Product Line (SPL) is a development paradigm that targets the creation of variable software systems. Despite the increasing interest in product lines, research in the area usually relies on small systems implemented in the laboratories of the authors involved in the investigative work. This characteristic hampers broader conclusions about industry-strength product lines. Therefore, in order to address the unavailability of public and realistic product lines, this paper describes an experiment involving the extraction of a SPL for ArgoUML, an open source tool widely used for designing systems in UML. Using conditional compilation we have extracted eight complex and relevant features from ArgoUML, resulting in a product line called ArgoUML-SPL. By making the extracted SPL publicly available, we hope it can be used to evaluate the various flavors of techniques, tools, and languages that have been proposed to implement product lines. Moreover, we have characterized the implementation of the features considered in our experiment relying on a set of product-line specific metrics. Using the results of this characterization, it was possible to shed light on the major challenges involved in extracting features from real-world systems.

A gentle introduction to OSGi

The Open Services Gateway Initiative (OSGi) is a framework that supports the implementation of component-based, service-oriented applications in Java. The framework man- ages the life-cycle of modules (called bundles in OSGi) and provides means to publish and search for services. Moreover, it supports the dynamic install and uninstall of bundles. Nowadays, OSGi is used in many application domains, including mobile phones, embedded devices, and application servers. In this paper, we provide a gentle introduction to the basic services provided by OSGi. The presentation is guided by a simple case study, involving the implementation of a Dictionary System.

Recommending Refactorings to Reverse Software Architecture Erosion

Architectural erosion is a recurrent problem faced by software architects. Despite this fact, the process is usually tackled in ad hoc way, without adequate tool support at the architecture level. To address this issue, we describe the preliminary design of a recommendation system whose main purpose is to provide refactoring guidelines for developers and maintainers during the task of reversing an architectural erosion process. The paper formally describes first recommendations proposed in our current research and results of their application in a web-based application.

Documenting APIs with examples: Lessons learned with the APIMiner platform

Software development increasingly relies on Application Programming Interfaces (APIs) to increase productivity. However, learning how to use new APIs in many cases is a nontrivial task given their ever-increasing complexity. To help developers during the API learning process, we describe in this paper a platform - called APIMiner - that instruments the standard Java-based API documentation format with concrete examples of usage. The examples are extracted from a private source code repository - composed by real systems - and summarized using a static slicing algorithm. We also describe a particular instantiation of our platform for the Android API. To evaluate the proposed solution, we performed a field study, when professional Android developers used the platform by four months.

Recommending Move Method refactorings using dependency sets

Methods implemented in incorrect classes are common bad smells in object-oriented systems, especially in the case of systems maintained and evolved for years. To tackle this design flaw, we propose a novel approach that recommends Move Method refactorings based on the set of static dependencies established by a method. More specifically, our approach compares the similarity of the dependencies established by a source method with the dependencies established by the methods in possible target classes. We evaluated our approach using systems from a compiled version of the Qualitas Corpus. We report that our approach provides an average precision of 60.63% and an average recall of 81.07%. Such results are, respectively, 129% and 49% better than the results achieved by JDeodorant, a well-known move method recommendation system.

Recommending automated extract method refactorings

Extract Method is a key refactoring for improving program comprehension. However, recent empirical research shows that refactoring tools designed to automate Extract Methods are often underused. To tackle this issue, we propose a novel approach to identify and rank Extract Method refactoring opportunities that are directly automated by IDE-based refactoring tools. Our approach aims to recommend new methods that hide structural dependencies that are rarely used by the remaining statements in the original method. We conducted an exploratory study to experiment and define the best strategies to compute the dependencies and the similarity measures used by the proposed approach. We also evaluated our approach in a sample of 81 extract method opportunities generated for JUnit and JHotDraw, achieving a precision of 48% (JUnit) and 38% (JHotDraw).

Why we refactor? confessions of GitHub contributors

Refactoring is a widespread practice that helps developers to improve the maintainability and readability of their code. However, there is a limited number of studies empirically investigating the actual motivations behind specific refactoring operations applied by developers. To fill this gap, we monitored Java projects hosted on GitHub to detect recently applied refactorings, and asked the developers to explain the reasons behind their decision to refactor the code. By applying thematic analysis on the collected responses, we compiled a catalogue of 44 distinct motivations for 12 well-known refactoring types. We found that refactoring activity is mainly driven by changes in the requirements and much less by code smells. Extract Method is the most versatile refactoring operation serving 11 different purposes. Finally, we found evidence that the IDE used by the developers affects the adoption of automated refactoring tools.

Qualitas.class corpus: a compiled version of the qualitas corpus

This paper documents a compiled version of the Qualitas Corpus named Qualitas.class Corpus. We provide compiled Java projects for the 111 systems included in the corpus. We also gathered a large amount of metrics data (such as measurements from complexity, coupling, and CK metrics) about the systems. By making Qualitas.class Corpus public, our goal is to assist researchers by removing the compilation effort when conducting empirical studies.

Predicting software defects with causality tests

Abstract In this paper, we propose a defect prediction approach centered on more robust evidences towards causality between source code metrics (as predictors) and the occurrence of defects. More specifically, we rely on the Granger causality test to evaluate whether past variations in source code metrics values can be used to forecast changes in time series of defects. Our approach triggers alarms when changes made to the source code of a target system have a high chance of producing defects. We evaluated our approach in several life stages of four Java-based systems. We reached an average precision greater than 50% in three out of the four systems we evaluated. Moreover, by comparing our approach with baselines that are not based on causality tests, it achieved a better precision.