Orla Greevy

Correlating features and code using a compact two-sided trace analysis approach

Software developers are constantly required to modify and adapt application features in response to changing requirements. The problem is that just by reading the source code, it is difficult to determine how classes and methods contribute to the runtime behavior of features. Moreover, dependencies between system features are not obvious, consequently software maintenance operations often result in unintended side effects. To tackle these problems, we propose a compact feature-driven approach (i.e., summarized trace information) based on dynamic analysis to characterize features and computational units of an application. We extract execution traces to achieve an explicit mapping between features and classes using two complementary perspectives. We apply our approach to two case studies and we report our findings.

Exploiting the Analogy Between Traces and Signal Processing

The main challenge of dynamic analysis is the huge volume of data, making it difficult to extract high level views. Most techniques developed so far adopt a finegrained approach to address this issue. In this paper we introduce a novel approach representing entire traces as signals in time. Drawing this analogy between dynamic analysis and signal processing, we are able to access a rich toolkit of well-established and ready-to-use analysis techniques. As an application of this analogy, we show how to fit a visualization of the complete feature space of a system on one page only: our approach visualizes feature traces as time plots, summarizes the trace signals and uses dynamic time warping to group them by similar features. We apply the approach on a case study, and discuss both common and unique patterns as observed on the visualization

Visualizing live software systems in 3D

The analysis of the runtime behavior of a software system yields vast amounts of information, making accurate interpretations difficult. Filtering or compression techniques are often applied to reduce the volume of data without loss of key information vital for a specific analysis goal. Alternatively, visualization is generally accepted as a means of effectively representing large amounts of data. The challenge lies in creating effective and expressive visual representations that not only allows for a global picture, but also enables us to inspect the details of the large data sets. We define the focus of our analysis to be the runtime behavior of features. Static structural visualizations of a system are typically represented in two dimensions. We exploit a third dimension to visually represent the dynamic information, namely object instantiations and message sends. We introduce a novel 3D visualization technique that supports animation of feature behavior and integrates zooming, panning, rotating and on-demand details. As proof of concept, we apply our visualization technique to feature execution traces of an example system.

Analyzing Software Evolution through Feature Views

Features encapsulate the domain knowledge of a software system and thus are valuable sources of information for a reverse engineer. When analyzing the evolution of a system, we need to know how and which features were modified to recover both the change intention and its extent, namely which source artifacts are affected. Typically, the implementation of a feature crosscuts a number of source artifacts. To obtain a mapping between features to the source artifacts, we exercise the features and capture their execution traces. However this results in large traces that are difficult to interpret. To tackle this issue we compact the traces into simple sets of source artifacts that participate in a features runtime behavior. We refer to these compacted traces as feature views. Within a feature view, we partition the source artifacts into disjoint sets of characterized software entities. The characterization defines the level of participation of a source entity in the features. We then analyze the features over several versions of a system and we plot their evolution to reveal how and hich features were affected by changes in the code. We show the usefulness of our approach by applying it to a case study where we address the problem of merging parallel development tracks of the same system.

Analyzing feature traces to incorporate the semantics of change in software evolution analysis

Many of the approaches that analyze software evolution consider a static perspective of a system. Static analysis approaches focus on the evolution of static software entities such as packages, classes and methods. Without knowledge of the roles software entities play in system features, it is difficult to interpret the motivation behind changes and extensions in the code. To tackle this problem, we propose an approach to software evolution analysis that exploits the relationships between features and software entities. Our definition of a feature is a unit of observable behavior of a software system. We define history measurements that summarize the evolution of software entities from a feature perspective. We show how we use our feature perspective of software evolution to interpret modifications and extensions to the code. We apply our approach on two case studies and discuss our findings.

Tracking Objects to Detect Feature Dependencies

The domain-specific ontology of a software system includes a set of features and their relationships. While the problem of locating features in object-oriented programs has been widely studied, runtime dependencies between features are less well understood. Features cannot be understood in isolation, since their behavior often depends on objects created and referenced in previously exercised features. It is difficult to spot runtime dependencies between features just by browsing source code. Hence, code modifications intended for one feature, often inadvertently affect other features. In this paper, we propose an approach to precisely identify dependencies between features based on a fine-grained dynamic analysis which captures details about how objects are referenced at runtime. The results of two case studies indicate that our approach helps software maintainers in understanding critical feature dependencies.

Exploiting Runtime Information in the IDE

Developers rely on the mechanisms provided by their IDE to browse and navigate a large software system. These mechanisms are usually based purely on a systems static source code. The static perspective, however, is not enough to understand an object-oriented programs behavior, in particular if implemented in a dynamic language. We propose to enhance IDEs with a programs runtime information (e.g., message sends and type information) to support program comprehension through precise navigation and informative browsing. To precisely specify the type and amount of runtime data to gather about a system under development, dynamically and on demand, we adopt a technique known as partial behavioral reflection. We implemented navigation and browsing enhancements to an IDE that exploit this runtime information in a prototype called Hermion. We present preliminary validation of our experimental enhanced IDE by asking developers to assess its usefulness to understand an unfamiliar software system.

Enriching Reverse Engineering with Annotations

Much of the knowledge about software systems is implicit, and therefore difficult to recover by purely automated techniques. Architectural layers and the externally visible features of software systems are two examples of information that can be difficult to detect from source code alone, and that would benefit from additional human knowledge. Typical approaches to reasoning about data involve encoding an explicit meta-model and expressing analyses at that level. Due to its informal nature, however, human knowledge can be difficult to characterize up-front and integrate into such a meta-model. We propose a generic, annotation-based approach to capture such knowledge during the reverse engineering process. Annotation types can be iteratively defined, refined and transformed, without requiring a fixed meta-model to be defined in advance. We show how our approach supports reverse engineering by implementing it in a tool called Metanool and by applying it to (i) analyzing architectural layering, (ii) tracking reengineering tasks, (iii) detecting design flaws, and (iv) analyzing features.

Feature driven browsing

Development environments typically present the software engineer with a structural perspective of an object-oriented system in terms of packages, classes and methods. From a structural perspective it is difficult to gain an understanding of how source entities participate in a systems features at runtime, especially when using dynamic languages such as Smalltalk. In this paper we evaluate the usefulness of offering an alternative, complementary feature-centric perspective of a software system when performing maintenance activities. We present a feature-centric environment combining interactive visual representations of features with a source code browser displaying only the classes and methods participating in a feature under investigation. To validate the usefulness of our feature-centric view, we conducted a controlled empirical experiment where we measured and compared the performance of subjects when correcting two defects in an unfamiliar software system with a traditional development environment and with our feature-centric environment. We evaluate both quantitative and qualitative data to draw conclusions about the usefulness of a feature-centric perspective to support program comprehension during maintenance activities.

How Developers Develop Features

Software systems are typically developed by teams of developers, with responsibilities for different parts of the code. Knowledge of how the developers collaborate, and how their responsibilities are distributed over the software artifacts is a valuable source of information when reverse engineering a system. Determining which developers are responsible for which software artifacts (e.g., packages or classes) is just one perspective. In this paper we complement the static perspective with the dynamic perspective of a system in terms of its features. We want to extract information about which developers are responsible for which features. To achieve these two perspectives, we correlate developer responsibilities both with a structural view of the system and with a feature view. We identify which developers are responsible for which features, and whether the responsibilities correspond with structural source code artifacts or with features. We apply our technique to two software projects developed by two teams of students as part of their course work, and to one large open source project