Otávio Augusto Lazzarini Lemos

An exploratory study of fault-proneness in evolving aspect-oriented programs

This paper presents the results of an exploratory study on the fault-proneness of aspect-oriented programs. We analysed the faults collected from three evolving aspect-oriented systems, all from different application domains. The analysis develops from two different angles. Firstly, we measured the impact of the obliviousness property on the fault-proneness of the evaluated systems. The results show that 40% of reported faults were due to the lack of awareness among base code and aspects. The second analysis regarded the fault-proneness of the main aspect-oriented programming (AOP) mechanisms, namely pointcuts, advices and intertype declarations. The results indicate that these mechanisms present similar fault-proneness when we consider both the overall system and concern-specific implementations. Our findings are reinforced by means of statistical tests. In general, this result contradicts the common intuition stating that the use of pointcut languages is the main source of faults in AOP.

Control and data flow structural testing criteria for aspect-oriented programs

Although it is claimed that, among other features, aspect-oriented programming (AOP) increases understandability and eases the maintenance burden, this technology cannot provide correctness by itself, and thus it also requires the use of systematic verification, validation and testing (VV&T) approaches. With the purpose of producing high quality software, many approaches to apply structural testing criteria for the unit testing of procedural and object-oriented (OO) programs have been proposed. Nevertheless, until now, few works have addressed the application of such criteria to test aspect-oriented programs. In this paper we define a family of control flow and data flow based testing criteria for aspect-oriented programs inspired by the implementation strategy adopted by AspectJ - an aspect-oriented extension of the Java language - and extending a previous work proposed for Java programs. We propose the derivation of a control and data flow model for aspect-oriented programs based upon the static analysis of the object code (the Java bytecode) resulted from the compilation/weaving process. Using this model, called aspect-oriented def-use graph (AODU), traditional and also aspect-oriented testing criteria are defined (called Control and Data Flow Structural Testing Criteria for Aspect-Oriented Programs - CDSTC-AOP). The main idea is that composition of aspect-oriented programs leads to new crosscutting interfaces in several modules of the system, which must be considered for coverage during structural testing. The implementation of a prototype tool - the JaBUTi/AJ tool - to support the proposed criteria and model is presented along with an example. Also, theoretical and practical questions regarding the CDSTC-AOP criteria are discussed.

CodeGenie: using test-cases to search and reuse source code

We present CodeGenie, a tool that implements a test-driven approachto search and reuse of code available on large-scale coderepositories. While using CodeGenie developers design test cases fora desired feature first, similar to Test-driven Development (TDD).However, instead of implementing the feature as in TDD, CodeGenieautomatically searches for it based on information available in thetests. To check the suitability of the candidate results in thelocal context, each result is automatically woven into thedevelopers project and tested using the original tests. Thedeveloper can then reuse the most suitable result. Later, reusedcode can also be unwoven from the project as wished. For the codesearching and wrapping facilities, CodeGenie relies on Sourcerer, anInternet-scale source code infrastructure that we have developed

Testing aspect-oriented programming Pointcut Descriptors

Pointcut Descriptors (PCDs) are used to specify sets of program join points with a common property where additional behavior should be applied. If PCDs are wrongly formulated, faults are injected into the program, because additional behavior will be applied to unintended join points or will fail to be applied to intended join points. In this paper we classify the types of faults that can occur in PCDs -- in terms of selected join points -- and present a two-step strategy to: 1) help the tester identifying extra join points selected by PCDs; and 2) help the tester identifying neglected join points that should be selected by PCDs in the first place. We focus on the first step but provide motivating examples and directions for both.

CodeGenie:: a tool for test-driven source code search

We present CodeGenie, a tool that implements a test-driven approach to search and reuse of code available on largescale code repositories. With CodeGenie, developers designtest cases for a desired feature first, similar to Test-driven Development (TDD). However, instead of implementing the feature from scratch, CodeGenie automatically searches foran existing implementation based on information available in the tests. To check the suitability of the candidate results in the local context, each result is automatically woven into the developers project and tested using the original tests. The developer can then reuse the most suitable result. Later, reused code can also be unwoven from the project as wished. For the code searching and wrapping facilities, CodeGenie relies on Sourcerer, an Internet-scale source code infrastructure that we have developed.

A test-driven approach to code search and its application to the reuse of auxiliary functionality

ContextSoftware developers spend considerable effort implementing auxiliary functionality used by the main features of a system (e.g., compressing/decompressing files, encryption/decription of data, scaling/rotating images). With the increasing amount of open source code available on the Internet, time and effort can be saved by reusing these utilities through informal practices of code search and reuse. However, when this type of reuse is performed in an ad hoc manner, it can be tedious and error-prone: code results have to be manually inspected and integrated into the workspace. ObjectiveIn this paper we introduce and evaluate the use of test cases as an interface for automating code search and reuse. We call our approach Test-Driven Code Search (TDCS). Test cases serve two purposes: (1) they define the behavior of the desired functionality to be searched; and (2) they test the matching results for suitability in the local context. We also describe CodeGenie, an Eclipse plugin we have developed that performs TDCS using a code search engine called Sourcerer. MethodOur evaluation consists of two studies: an applicability study with 34 different features that were searched using CodeGenie; and a performance study comparing CodeGenie, Google Code Search, and a manual approach. ResultsBoth studies present evidence of the applicability and good performance of TDCS in the reuse of auxiliary functionality. ConclusionThis paper presents an approach to source code search and its application to the reuse of auxiliary functionality. Our exploratory evaluation shows promising results, which motivates the use and further investigation of TDCS.

Applying test-driven code search to the reuse of auxiliary functionality

Software developers spend considerable effort implementing auxiliary functionality used by the main features of a system (e.g. compressing/decompressing files, encryption/decription of data, scaling/rotating images). With the increasing amount of open source code available on the Internet, time and effort can be saved by reusing these utilities through informal practices of code search and reuse. However, when this type of reuse is performed in an ad hoc manner, it can be tedious and error-prone: code results have to be manually inspected and extracted into the workspace. In this paper we introduce the use of test cases as an interface for automating code search and reuse and evaluate its applicability and performance in the reuse of auxiliary functionality. We call our approach Test-Driven Code Search (TDCS). Test cases serve two purposes: (1) they define the behavior of the desired functionality to be searched; and (2) they test the matching results for suitability in the local context. We present CodeGenie, an Eclipse plugin that performs TDCS using a code search engine called Sourcerer. Our evaluation presents evidence of the applicability and good performance of TDCS in the reuse of auxiliary functionality.

Integration testing of Object-Oriented and Aspect-Oriented programs: A structural pairwise approach for Java

Several testing approaches focus on finding faults in software units of implementation. A problem not addressed by unit testing is the interaction among units, with respect to the correctness of their interfaces. In this paper a structural integration testing approach for Object-Oriented (OO) and Aspect-Oriented (AO) Java programs is presented. To make the activity more feasible, we address the testing of pairs of units (i.e., methods and pieces of advice). A model called PWDU (PairWise Def-Use) graph to represent the flow of control and data between pairs of units is proposed. Based on the PWDU, the following family of testing criteria is defined: all-pairwise-integrated-nodes (control-flow based), all-pairwise-integrated-edges (control-flow based), and all-pairwise-integrated-uses (data-flow based). To evaluate the proposed approach, an implementation of the criteria in a testing tool is presented along with an example of usage and an exploratory study. The study with 7 AO programs that are also OO was conducted to investigate the cost of application and usefulness of the approach. Results provided evidence that the criteria are practical and useful for integration testing of OO and AO programs.

Thesaurus-based automatic query expansion for interface-driven code search

Software engineers often resort to code search practices to support software maintenance and evolution tasks, in particular code reuse. An issue that affects code search is the vocabulary mismatch problem: while searching for a particular function, users have to guess the exact words that were chosen by original developers to name code entities. In this paper we present an automatic query expansion (AQE) approach that uses word relations to increase the chances of finding relevant code. The approach is applied on top of Test-Driven Code Search (TDCS), a promising code retrieval technique that uses test cases as inputs to formulate the search query, but can also be used with other techniques that handle interface definitions to produce queries (interface-driven code search). Since these techniques rely on keywords and types, the vocabulary mismatch problem is also relevant. AQE is carried out by leveraging WordNet, a type thesaurus for expanding types, and another thesaurus containing only software-related word relations. Our approach is general but was specifically designed for non-native English speakers, who are frequently unaware of the most common terms used to name functions in software. Our evaluation with 36 non-native subjects - including developers and senior Computer Science students - provides evidence that our approach can improve the chances of finding relevant functions by 41% (recall improvement of 30%, on average), without hurting precision.

The Impact of Coupling on the Fault-Proneness of Aspect-Oriented Programs: An Empirical Study

Coupling in software applications is often used as an indicator of external quality attributes such as fault-proneness. In fact, the correlation of coupling metrics and faults in object oriented programs has been widely studied. However, there is very limited knowledge about which coupling properties in aspect-oriented programming (AOP) are effective indicators of faults in modules. Existing coupling metrics do not take into account the specificities of AOP mechanisms. As a result, these metrics are unlikely to provide optimal predictions of pivotal quality attributes such as fault-proneness. This impacts further by restraining the assessments of AOP empirical studies. To address these issues, this paper presents an empirical study to evaluate the impact of coupling sourced from AOP-specific mechanisms. We utilise a novel set of coupling metrics to predict fault occurrences in aspect-oriented programs. We also compare these new metrics against previously proposed metrics for AOP. More specifically, we analyse faults from several releases of three AspectJ applications and perform statistical analyses to reveal the effectiveness of these metrics when predicting faults. Our study shows that a particular set of fine-grained directed coupling metrics have the potential to help create better fault prediction models for AO programs.