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.

Butor et le livre-installation: montage de textes, œuvre plurielle, transits entre univers culturels

La complétude des Œuvres complètes de Butor est problématique, car elle ne prend pas en compte les collaborations de toutes sortes et les œuvres inscrites sur d’autres supports que du papier. Pour avoir une véritable idée de cette complétude, il faudrait donc imaginer une installation qui réunirait à la fois, entre autres, les codex habituels de Butor, les livres d’artistes, les œuvres numériques. On se rendrait compte que cette installation est fondée sur des passages de frontières entre les genres artistiques, l’assemblage et le collage permettant de passer des frontières entre univers culturels différents.

Museum Schwab. Eine Sammlung, eine Idee und steter Wandel

1865, vier Jahre vor seinem Tod, schenkt der Bieler Sammler Friedrich Schwab seine archäologischen Objekte der Stadt. Er möchte damit den Bewohnern Biels, vor allem der Jugend, einen reichen Fundus zur Verfügung stellen, der einen Einblick in den Alltag der prähistorischen Bewohner der Region bietet. Bis heute ist die Sammlung Schwab ein Studienobjekt für Archäologen geblieben und inspiriert Öffentlichkeit und Schulklassen: So sieht Friedrich Schwab seinen Willen auch nach bald 150 Jahren noch immer erfüllt. Die vorliegende Publikation erläutert die wechselvolle Geschichte des Museums Schwab und bietet gleichzeitig einen Überblick über die archäologische Erforschung der Drei-Seen-Region: von der Entdeckung der ersten Pfahlbausiedlungen bis zu ihrer Aufnahme in das UNESCO Welterbe. Sie folgt den Sammlungen eines Universalmuseums auf ihrer Odyssee, weist auf Details einer einmaligen Architektur hin und zeigt die Zusammenhänge zwischen Kulturpolitik und der aktuellen Bieler Museumslandschaft auf.

Who cares about my feature request?

Previous studies on issue tracking systems for open source software (OSS) focused mainly on requests for bug fixes. However, requests to add a new feature or an improvement to an OSS project are often also made in an issue tracking system. These inquiries are particularly important because they determine the further development of the software. This study examines if there is any difference between requests of the IBM developer community and other sources in terms of the likelihood of successful implementation. Our study consists of a case study of the issue tracking system BugZilla in the Eclipse integrated development environment (IDE). Our hypothesis, which was that feature requests from outsiders have less chances of being implemented, than feature requests from IBM developers, was confirmed.

On Understanding How Developers Use the Spotter Search Tool

Analyzing how software engineers use the Integrated Development Environment (IDE) is essential to better understanding how engineers carry out their daily tasks. Spotter is a code search engine for the Pharo programming language. Since its inception, Spotter has been rapidly and broadly adopted within the Pharo community. However, little is known about how practitioners employ Spotter to search and navigate within the Pharo code base. This paper evaluates how software engineers use Spotter in practice. To achieve this, we remotely gather user actions called events. These events are then visually rendered using an adequate navigation tool chain. Sequences of events are represented using a visual alphabet. We found a number of usage patterns and identified underused Spotter features. Such findings are essential for improving Spotter.