Supporting Task-oriented Navigation in IDEs with Configurable HeatMaps

Mainstream IDEs generally rely on the static structure of a software project to support browsing and navigation. We propose HeatMaps, a simple but highly configurable technique to enrich the way an IDE displays the static structure of a software system with additional kinds of information. A heatmap highlights software artifacts according to various metric values, such as bright red or pale blue, to indicate their potential degree of interest. We present a prototype system that implements heatmaps, and we describe an initial study that assesses the degree to which different heatmaps effectively guide developers in navigating software.

Augmenting Static Source Views in IDEs with Dynamic Metrics

Mainstream IDEs such as Eclipse support developers in managing software projects mainly by offering static views of the source code. Such a static perspective neglects any information about runtime behavior. However, object-oriented programs heavily rely on polymorphism and late-binding, which makes them difficult to understand just based on their static structure. Developers thus resort to debuggers or profilers to study the system's dynamics. However, the information provided by these tools is volatile and hence cannot be exploited to ease the navigation of the source space. In this paper we present an approach to augment the static source perspective with dynamic metrics such as precise runtime type information, or memory and object allocation statistics. Dynamic metrics can leverage the understanding for the behavior and structure of a system. We rely on dynamic data gathering based on aspects to analyze running Java systems. By solving concrete use cases we illustrate how dynamic metrics directly available in the IDE are useful. We also comprehensively report on the efficiency of our approach to gather dynamic metrics.

Autumn Leaves: Curing the Window Plague in IDEs

Navigating large software systems is difficult as the various artifacts are distributed in a huge space, while the relationships between different artifacts often remain hidden and obscure. As a consequence, developers using a modern interactive development environment (IDE) are forced to open views on numerous source artifacts to reveal these hidden relationships, leading to a crowded workspace with many opened windows or tabs. Developers often lose the overview in such a cluttered workspace as IDEs provide little support to get rid of unused windows. AutumnLeaves automatically selects windows unlikely for future use to be closed or grayed out while important ones are displayed more prominently. This reduces the number of windows opened at a time and adds structure to the developer's workspace. We validate AutumnLeaves with a benchmark evaluation using recorded navigation data of various developers to determine the prediction quality of the employed algorithms.

Embedding Moose Facilities Directly in IDEs

Moose is a powerful reverse engineering platform, but its facilities and means to analyze software are separated from the tools developers typically use to develop and maintain their software systems: development environments such as Eclipse, VisualWorks, or Squeak. In practice, this requires developers to work with two distinct environments, one to actually develop the software, and another one (e.g., Moose) to analyze it. We worked on several different techniques, using both dynamic and static analyzes to provide software analysis capabilities to developers directly in the IDE. The immediate availability of analysis tools in an IDE significantly increases the likelihood that developers integrate software analysis in their daily work, as we discovered by conducting user studies with developers. Finally, we identified several important aspect of integrating software analysis in IDEs that need to be addressed in the future to increase the adoption of these techniques by developers.

Extracting models from IDEs

Systems must co-evolve with their context. Reverse engineering tools are a great help in this process of required adaption. In order for these tools to be flexible, they work with models, abstract representations of the source code. The extraction of such information from source code can be done using a parser. However, it is fairly tedious to build new parsers. And this is made worse by the fact that it has to be done over and over again for every language we want to analyze. In this paper we propose a novel approach which minimizes the knowledge required of a certain language for the extraction of models implemented in that language by reflecting on the implementation of preparsed ASTs provided by an IDE. In a second phase we use a technique referred to as Model Mapping by Example to map platform dependent models onto domain specific model.

Spotter: towards a unified search interface in IDEs

Program comprehension requires developers to reason about many kinds of highly interconnected software entities. Dealing with this reality prompts developers to continuously intertwine searching and navigation. Nevertheless, most integrated development environments (IDEs) address searching by means of many disconnected search tools, making it difficult for developers to reuse search results produced by one search tool as input for another search tool. This forces developers to spend considerable time manually linking disconnected search results. To address this issue we propose Spotter, a model for expressing and combining search tools in a unified way. The current implementation shows that Spotter can unify a wide range of search tools. More information about Spotter can be found at scg.unibe.ch/research/moldablespotter

Simultaneous bilateral hip replacement reveals superior outcome and fewer complications than two-stage procedures: a prospective study including 1819 patients and 5801 follow-ups from a total joint replacement registry

Background Total joint replacements represent a considerable part of day-to-day orthopaedic routine and a substantial proportion of patients undergoing unilateral total hip arthroplasty require a contralateral treatment after the first operation. This report compares complications and functional outcome of simultaneous versus early and delayed two-stage bilateral THA over a five-year follow-up period. Methods The study is a post hoc analysis of prospectively collected data in the framework of the European IDES hip registry. The database query resulted in 1819 patients with 5801 follow-ups treated with bilateral THA between 1965 and 2002. According to the timing of the two operations the sample was divided into three groups: I) 247 patients with simultaneous bilateral THA, II) 737 patients with two-stage bilateral THA within six months, III) 835 patients with two-stage bilateral THA between six months and five years. Results Whereas postoperative hip pain and flexion did not differ between the groups, the best walking capacity was observed in group I and the worst in group III. The rate of intraoperative complications in the first group was comparable to that of the second. The frequency of postoperative local and systemic complication in group I was the lowest of the three groups. The highest rate of complications was observed in group III. Conclusions From the point of view of possible intra- and postoperative complications, one-stage bilateral THA is equally safe or safer than two-stage interventions. Additionally, from an outcome perspective the one-stage procedure can be considered to be advantageous.

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 system's static source code. The static perspective, however, is not enough to understand an object-oriented program's behavior, in particular if implemented in a dynamic language. We propose to enhance IDEs with a program's runtime information (eg. 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.

Tackling Software Navigation Issues of the Smalltalk IDE

The IDE used in most Smalltalk dialects such as Pharo, Squeak or Cincom Smalltalk did not evolve significantly over the last years, if not to say decades. For other languages, for instance Java, the available IDEs made tremendous progress as Eclipse or NetBeans illustrate. While the Smalltalk IDE served as an exemplar for many years, other IDEs caught up or even overtook the erstwhile leader in terms of feature-richness, usability, or code navigation facilities. In this paper we first analyze the difficulty of software navigation in the Smalltalk IDE and second illustrate with concrete examples the features we added to the Smalltalk IDE to fill the gap to modern IDEs and to provide novel, improved means to navigate source space. We show that thanks to the agility and dynamics of Smalltalk, we are able to extend and enhance with reasonable effort the Smalltalk IDE to better support software navigation, program comprehension, and software maintenance in general. One such support is the integration of dynamic information into the static source views we are familiar with. Other means include easing the access to static information (for instance by better arranging important packages) or helping developers re-locating artifacts of interest (for example with a categorization system such as smart groups).