Previous research in computer science shows that developers spend a large fraction of their time navigating through source code. Improving developers ’ effectiveness in navigating code thus should yield significant productivity improvements. Previous research in a number of fields suggests that a more breadth-first approach to problem solving should be more successful than a more depth-first approach. Unfortunately, modern Integrated Development Environments (IDEs) do not support a breadth-first search well because they do not help developers keep track of exploration paths well. We implemented an IDE that allows developers to track different exploration paths more easily, and ran a user study with seven subjects. To our surprise, subjects used the tool to mark waypoints instead of to facilitate a more breadth-first search. Intrigued, we examined more closely techniques for finding a starting point and for tracing relationships from there. We describe our findings, including common difficulties our subjects encountered, and propose a novel tool to reduce incorrect search paths.

To our knowledge, this work is the most extensive, if not the only, empirical evaluation of workspace awareness in software development. We performed two user experiments to investigate the effectiveness of a workspace awareness tool in facilitating coordination and reducing conflicts. In the first experiment, we evaluated the tool through textbased assignments to avoid interference from the welldocumented effects of individual differences in software tasks. The approach of controlling for individual differences, though straightforward, is a novel paradigm for evaluating user interfaces in software engineering. With the benchmark of this first experiment in place, in the next experiment, we proceeded to validate the benefits of the tool in the software domain. Our results provide quantitative evidence of the benefits of workspace awareness in improving conflict resolution and coordination as well as helping both novice and expert users.

Conducting controlled experiments about programming activities often requires the use of multiple tasks of similar difficulty. In previously reported work about a controlled experiment investigating software exploration tools, we tried to select two change tasks of equivalent difficulty to be performed on a medium-sized code base. Despite careful effort in the selection and confirmation from our pilot subjects finding the two tasks to be of equivalent difficulty, the data from the experiment suggest the subjects found one of the tasks more difficult than the other. In this paper, we report on early work to create a metric to estimate the cognitive difficulty for a software change task. Such a metric would help in comparing between studies of different tools, and in designing future studies. Our particular approach uses a graph-theoretic statistic to measure the complexity of the task solution by the connectedness of the solution elements. The metric predicts the perceived difficulty for the tasks of our experiment, but fails to predict the perceived difficulty for other tasks to a small program. We discuss these differences and suggest future approaches.

Abstract—Developers navigate and reason about call graphs throughout investigation and debugging activities. This is often difficult: developers can spend tens of minutes answering a single question, get lost and disoriented, and erroneously make assumptions, causing bugs. To address these problems, we designed a new form of interactive call graph visualization – REACHER. Instead of leaving developers to manually traverse the call graph, REACHER lets developers search along control flow. The interactive call graph visualization encodes a number of properties that help developers answer questions about causality, ordering, type membership, repetition, choice, and other relationships. And developers remain oriented while navigating. To evaluate REACHER’S benefits, we conducted a lab study in which 12 participants answered control flow questions. Compared to an existing IDE, participants with REACHER were over 5 times more successful in significantly less time. All enthusiastically preferred REACHER, with many positive comments. Keywords-code exploration, call graphs, control flow, program visualization, program comprehension I.

We present Stacksplorer, a new tool to support source code navigation and comprehension. Stacksplorer computes the call graph of a given piece of code, visualizes relevant parts of it, and allows developers to interactively traverse it. This augments the traditional code editor by offering an additional layer of navigation. Stacksplorer is particularly useful to understand and edit unknown source code because branches of the call graph can be explored and backtracked easily. Visualizing the callers of a method reduces the risk of introducing unintended side effects. In a quantitative study, programmers using Stacksplorer performed three of four software maintenance tasks significantly faster and with higher success rates, and Stacksplorer received a System Usability Scale rating of 85.4 from participants. ACM Classification: H5.2 [Information interfaces and presentation]:

To my family for their unlimited support.

In data warehouse systems you search for all items that have a desired combination of features, called dimensions. Similar to features of an item, concerns of software are scattered throughout a software system. So, a developer might ask the following questions: Which modules are belonging to a concern? Which concerns are appearing in a package? In this paper, we introduce multi-dimensional concern reverse engineering supported by Data Warehouse technology. This approach enables to search for code fragments like it can be done for artifacts in the warehouse. We show that a transformation process from source code to the Data Warehouse is possible. Consequently, a developer can fasten up searches and perform source code analysis more easily.

With object-oriented design, it is at least as important—possibly more important—to understand the runtime structure, in terms of objects and their relations, as to understand the code structure dealing with source files, classes and packages. Today, many tools and diagrams help developers understand the code structure. Diagrams of the run-time structure, however, are much less mature. One diagram of the run-time structure is a statically extracted, global, hierarchical Ownership Object Graph (OOG). The OOG conveys architectural abstraction by ownership hierarchy by showing architecturally significant objects near the top of the hierarchy and data structures further down. In an OOG, objects are also organized into named, conceptual groups called domains. We posit that types are not enough for object-oriented code comprehension, and that the OOG improves comprehension by giving developers the ability to distinguish the role that an object plays, not only by type, but also by named groups (domains) or by position in the run-time structure (ownership), i.e.,types + ownership + domains. We evaluate, in a controlled experiment, whether an OOG, as a diagram of the run-time structure, improves object-oriented code comprehension by giving developers the ability to distinguish the role that an object plays, not only by type, but also by named groups (domains) or by position in the run-time structure