Ekwa Duala-Ekoko

Tracking Code Clones in Evolving Software

Code clones are generally considered harmful in software development, and the predominant approach is to try to eliminate them through refactoring. However, recent research has provided evidence that it may not always be practical, feasible, or cost-effective to eliminate certain clone groups. We propose a technique for tracking clones in evolving software. Our technique relies on the concept of abstract clone region descriptors (CRD), which describe clone regions within methods in a robust way that is independent from the exact text of the clone region or its location in a file. We present our definition of CRDs, and describe a complete clone tracking system capable of producing CRDs from the output of a clone detection tool, notify developers of modifications to clone regions, and support the simultaneous editing of clone regions. We report on two experiments and a case study conducted to assess the performance and usefulness of our approach.

Clonetracker: tool support for code clone management

Code clones are generally considered to be an obstacle to software maintenance. Research has provided evidence that it may not always be practical, feasible, or cost-effective to eliminate certain clone groups through refactoring. This paper describes CloneTracker, an Eclipse plug-in that provides support for tracking code clones in evolving software. With CloneTracker, developers can specify clone groups they wish to track, and the tool will automatically generate a clone model that is robust to changes to the source code, and can be shared with other collaborators of the project. When future modifications intersect with tracked clones, CloneTracker will notify the developer, provide support to consistently apply changes to a corresponding clone region, and provide support for updating the clone model. CloneTracker complements existing techniques by providing support for reusing knowledge about the location of clones in source code, and support for keeping track of clones when refactoring is not desirable.

Clone region descriptors: Representing and tracking duplication in source code

Source code duplication, commonly known as code cloning, is considered an obstacle to software maintenance because changes to a cloned region often require consistent changes to other regions of the source code. Research has provided evidence that the elimination of clones may not always be practical, feasible, or cost-effective. We present a clone management approach that describes clone regions in a robust way that is independent from the exact text of clone regions or their location in a file, and that provides support for tracking clones in evolving software. Our technique relies on the concept of abstract clone region descriptors (CRDs), which describe clone regions using a combination of their syntactic, structural, and lexical information. We present our definition of CRDs, and describe a clone tracking system capable of producing CRDs from the output of different clone detection tools, notifying developers of modifications to clone regions, and supporting updates to the documented clone relationships. We evaluated the performance and usefulness of our approach across three clone detection tools and five subject systems, and the results indicate that CRDs are a practical and robust representation for tracking code clones in evolving software.

Asking and answering questions about unfamiliar APIs: an exploratory study

The increasing size of APIs and the increase in the number of APIs available imply developers must frequently learn how to use unfamiliar APIs. To identify the types of questions developers want answered when working with unfamiliar APIs and to understand the difficulty they may encounter answering those questions, we conducted a study involving twenty programmers working on different programming tasks, using unfamiliar APIs. Based on the screen captured videos and the verbalization of the participants, we identified twenty different types of questions programmers ask when working with unfamiliar APIs, and provide new insights to the cause of the difficulties programmers encounter when answering questions about the use of APIs. The questions we have identified and the difficulties we observed can be used for evaluating tools aimed at improving API learning, and in identifying areas of the API learning process where tool support is missing, or could be improved.

Using structure-based recommendations to facilitate discoverability in APIs

Empirical evidence indicates that developers face significant hurdles when the API elements necessary to implement a task are not accessible from the types they are working with. We propose an approach that leverages the structural relationships between API elements to make API methods or types not accessible from a given API type more discoverable. We implemented our approach as an extension to the content assist feature of the Eclipse IDE, in a tool called API Explorer. API Explorer facilitates discoverability in APIs by recommending methods or types, which although not directly reachable from the type a developer is currently working with, may be relevant to solving a programming task. In a case study evaluation, participants experienced little difficulty selecting relevant API elements from the recommendations made by API Explorer, and found the assistance provided by API Explorer helpful in surmounting discoverability hurdles in multiple tasks and various contexts. The results provide evidence that relevant API elements not accessible from the type a developer is working with could be efficiently located through guidance based on structural relationships.

AspectOptima: A Case Study on Aspect Dependencies and Interactions

This paper presents AspectO ptima , a language independent, aspect-oriented framework consisting of a set of ten base aspects--each one providing a well-defined reusable functionality--that can be configured to ensure the ACID properties (Atomicity, Consistency, Isolation, and Durability) for transactional objects. The overall goal of AspectO ptima is to serve as a case study for aspect-oriented software development, particularly for evaluating the expressivity of AOP languages and how they address complex aspect interactions and dependencies. The ten base aspects of AspectO ptima are simple, yet have complex dependencies and interactions among each other. To implement different concurrency control and recovery strategies, these aspects can be composed and assembled into different configurations; some aspects conflict with each other, others have to adapt their run time behavior according to the presence or absence of other aspects. The design of AspectO ptima highlights the need for a set of key language features required for implementing reusable aspect-oriented frameworks. To illustrate the usefulness of AspectO ptima as a means for evaluating programming language features, an implementation of AspectO ptima in AspectJ is presented. The experiment reveals that AspectJ s language features do not directly support implementation of reusable aspect-oriented frameworks with complex dependencies and interactions. The encountered AspectJ language limitations are discussed, workaround solutions are shown, potential language improvements are proposed where appropriate, and some preliminary measurements are presented that highlight the performance impact of certain language features.

Impact analysis and visualization toolkit for static crosscutting in AspectJ

Understanding aspect-oriented systems, without appropriate tool support, is a difficult and a recognized problem in the research community. Surprisingly, little has been done to help developers understand the impact of the static crosscutting constructs of AspectJ on base programs. Questions of interest to developers such as: which statements in a base program are affected by a given inter-type declaration, or how has the behavior of the affected statements been modified, are still outstanding. This paper presents analysis techniques for inferring the impact of the static crosscutting constructs of AspectJ on base programs, and tools for visualizing the results of the analysis; thus improving the comprehension of AspectJ systems and guarding against unintended modifications. Our analyses are implemented as extensions to the AspectBench compiler, and integrated in the Eclipse IDE as a plugin. We present experiments on several open source systems to investigate the effectiveness and suitability of our analysis techniques and tools.

A detailed examination of the correlation between imports and failure-proneness of software components

Research has provided evidence that type usage in source files is correlated with the risk of failure of software components. Previous studies that investigated the correlation between type usage and component failure assigned equal blame to all the types imported by a component with a failure history, regardless of whether a type is used in the component, or associated to its failures. A failure-prone component may use a type, but it is not always the case that the use of this type has been responsible for any of its failures. To gain more insight about the correlation between type usage and component failure, we introduce the concept of a failure-associated type to represent the imported types referenced within methods fixed due to failures. We conducted two studies to investigate the tradeoffs between the equal-blame approach and the failure-associated type approach. Our results indicate that few of the types or packages imported by a failure-prone component are associated with its failures — less than 25% of the type imports, and less than 55% of the packages whose usage were reported to be highly correlated with failures by the equal-blame approach, were actually correlated with failures when we looked at the failure-associated types.