Debugging is hard. Interactive debuggers are mostly the same. They show you a stack, a way to sample the state of the stack, and, if the debugger is live, a way to step through execution. The standard interactive debugger for a general-purpose programming language provided by a mainstream IDE mostly offers a low-level interface in terms of generic language constructs to track down and fix bugs. A custom debugger, such as those developed for specific application domains, offers alternative interfaces more suitable to the specific execution context of the program being debugged. Custom debuggers offering contextual debugging views and actions can greatly improve our ability to reason about the current problem. Implementing such custom debuggers, however, is non-trivial, and poses a barrier to improving the debugging experience. In this paper we introduce moldable exceptions, a lightweight mechanism to adapt a debugger’s interface based on contextual information provided by a raised exception. We present, through a series of examples, how moldable exceptions can enhance a live programming environment.

What makes software systems explainable?As we develop and maintain software, we have questions to ask about the code, but piecing together the answers remains hard. The main interface the classical IDE offers is a text editor for the source code. Code, documentation, and the running system are disconnected.In this keynote presentation, we will show how software systems can be made explainable with the help of three interacting technologies: (i) live notebooks that can be used to create narratives that link documentation, source code, and running applications, (ii) example methods that not only perform tests, but produce live examples that can be used within narratives, to explain use cases, scenarios and features, and (iii) a moldable inspector that can be easily extended with live custom views to answer domain-specific questions about software systems.With the help of running examples we will show in the keynotes presentation how these technologies work together to provide a radically different kind of development experience.

Glyphs are automatically generated visual icons, commonly employed as an object identification technique. Although popular in the Human Computer Interaction community, glyphs are rarely employed to address software engineering problems. We extended the VisualID glyph technique to cope with structural software elements and used it to address two issues in software maintenance: identify classes with the same dependencies and classes with a similar set of methods. We have compared VisualID against three visual representations: textual, graph (nodes and edges), and dependency structural matrix. Our experiments indicate that VisualID significantly helps identify classes with the same dependencies and classes with similar methods when compared with visual techniques commonly used in software maintenance.

A picture tells a thousand words. We all know that. Then why are our development tools showing mainly text with so much obstinacy? Even when visualizations do make it into our tools, they typically do not make it past the periphery. Something is deeply wrong. We argue that visualizations must become pervasive in software development, and to accommodate this goal, the integrated development environments must change significantly.

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.

Graphs are commonly used to visually represent software dependencies. However, adequately visualizing software dependencies as a graph is a non-trivial problem due to the pluridimentional nature of software. We have designed a domain-specific language for visualizing software dependencies as graphs that is both expressive and concise. GRAPH, the implementation of our DSL, features a seamless mapping between visual dimensions to software metrics, composition of graph layouts, graph partition, and hierarchical bundle edges.

SUMMARY Reuse in object‐oriented languages typically focuses on inheritance. Numerous techniques have been developed to provide finer‐grained reuse of methods, such as flavors, mixins, and traits. These techniques, however, only deal with reuse at the level of classes. Class‐based reuse is inherently static. Increasing use of reflection and meta‐programming techniques in real‐world applications underlines the need for more dynamic approaches. New approaches have shifted to object‐specific reuse. However, these techniques fail to provide a complete solution to the composition issues arising during reuse. We propose a new approach that deals with reuse at the object level and that supports behavioral and state composition. We introduce a new abstraction called a talent that models features that are shared between objects of different class hierarchies. Talents provide a composition mechanism that is as flexible as that of traits but that is dynamic. Copyright © 2012 John Wiley & Sons, Ltd.

Dynamic analysis is increasingly attracting attention for debugging, profiling, and program comprehension. Ten to twenty years ago, many dynamic analyses investigated only simple method execution traces. Today, in contrast, many sophisticated dynamic analyses exist, for instance, for detecting memory leaks, analyzing ownership properties, measuring garbage collector performance, or supporting debugging tasks. These analyses depend on complex program instrumentations and analysis models, making it challenging to understand, compare, and reproduce the proposed approaches. While formal specifications and proofs are common in the field of static analysis, most dynamic analyses are specified using informal, textual descriptions. In this paper, we propose a formal framework using operational semantics that allows researchers to precisely specify their dynamic analysis. Our goal is to provide an accessible and reusable basis on which researchers who may not be familiar with rigorous specifications of dynamic analyses can build. By extending the provided semantics, one can concisely specify how runtime events are captured and how this data is transformed to populate the analysis model. Furthermore, our approach provides the foundations to reason about properties of a dynamic analysis.

Java Enterprise Applications (JEAs) are large systems that integrate multiple technologies and programming languages. Transactions in JEAs simplify the development of code that deals with failure recovery and multi-user coordination by guaranteeing atomicity of sets of operations. The heterogeneous nature of JEAs, however, can obfuscate conceptual errors in the application code, and in particular can hide incorrect declarations of transaction scope. In this paper we present a technique to expose and analyze the application transaction scope in JEAs by merging and analyzing information from multiple sources. We also present several novel visualizations that aid in the analysis of transaction scope by highlighting anomalies in the specification of transactions and violations of architectural constraints. We have validated our approach on two versions of a large commercial case study.

Industrial software systems are large and complex, both in terms of the software entities and their relationships. Consequently, understanding how a software system works requires the ability to pose queries over the design-level entities of the system. Traditionally, this task has been supported by simple tools (e.g., grep) combined with the programmer's intuition and experience. Recently, however, specialized code query technologies have matured to the point where they can be used in industrial situations, providing more intelligent, timely, and efficient responses to developer queries. This working session aims to explore the state of the art in code query technologies, and discover new ways in which these technologies may be useful in program comprehension. The session brings together researchers and practitioners. We survey existing techniques and applications, trying to understand the strengths and weaknesses of the various approaches, and sketch out new frontiers that hold promise.

Several reengineering environments have been created to provide for a unified infrastructure in which various approaches can be employed together. While the collaboration between tools is very strong within such environments, currently the inter-environmental collaboration is very weak and happens mainly at the level of data-files exchange. Consequently, the different groups of researchers are only collaborating shallowly via data, rather than at the level of analysis. In this demo, we present NOREX, a distributed reengineering environment that allows different groups of researchers to transparently use and combine existing techniques, and share their own, transcending any parochial barriers (e.g., implementation language or environment).

Understanding large software systems is a challenging task, and to support it many approaches have been developed. Often, the result of these approaches categorize existing entities into new groups or associates them with mutually exclusive properties. In this paper we present the distribution map as a generic technique to visualize and analyze this type of result. Our technique is based on the notion of focus, which shows whether a property is well-encapsulated or cross-cutting, and the notion of spread, which shows whether the property is present in several parts of the system. We present a basic visualization and complement it with measurements that quantify focus and spread. To validate our technique we show evidence of applying it on the result sets of different analysis approaches. As a conclusion we propose that the distribution map technique should belong to any reverse engineering toolkit

Copy-paste programming is dangerous as it may lead to hidden dependencies between different parts of the system. Modifying clones is not always straight forward, because we might not know all the places that need modification. This is even more of a problem when several developers need to know about how to change the clones. In this paper, we correlate the code clones with the time of the modification and with the developer that performed the modification to detect patterns of how developers copy from one another. We develop visualization, named clone evolution view, to represent the evolution of the duplicated code. We show the relevance of our approach on several large case studies and we distill our experience in forms of interesting copy patterns

The histories of software systems hold useful information when reasoning about the systems at hand or when reasoning about general laws of software evolution. Over the past 30 years, research has been increasingly spent on understanding software evolution. However, the approaches developed so far do not rely on an explicit meta-model and, thus, they make it difficult to reuse or compare their results. We argue that there is a need for an explicit meta-model for software evolution analysis. We present a survey of the evolution analyses and deduce a set of requirements that an evolution meta-model should have. We define Hismo, a meta-model in which history is modeled as an explicit entity. Hismo adds a time layer on top of structural information, and provides a common infrastructure for expressing and combining evolution analyses and structural analyses. We validate the usefulness of our meta-model by presenting how different analyses are expressed on it. Copyright © 2006 John Wiley & Sons, Ltd.

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 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 and 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 feature's 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 which features were affected by code changes. 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. Copyright © 2006 John Wiley & Sons, Ltd.

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.

Software systems are complex and difficult to analyze. Reengineering is a complex activity that usually involves combining different techniques and tools. MOOSE is an reengineering environment designed to provide the necessary infrastructure for building new tools and for integrating them. MOOSE centers on a language independent meta-model, and offers services like grouping, querying, navigation, and meta-descriptions. Several tools have been built on top of MOOSE dealing with different aspects of reengineering like: visualization, evolution analysis, semantic analysis, concept analysis or dynamic analysis.

MOOSE is a language-independent environment for reverse- and re-engineering complex software systems. MOOSE provides a set of services including a common meta-model, metrics evaluation and visualization, a model repository, and generic GUI support for querying, browsing and grouping. The development effort invested in MOOSE has paid off in precisely those research activities that benefit from applying a combination of complementary techniques. We describe how MOOSE has evolved over the years, we draw a number of lessons learned from our experience, and we outline the present and future of MOOSE.

Knowing where to start reverse engineering a large software system, when no information other than the system's source code itself is available, is a daunting task. Having the history of the code (i.e., the versions) could be of help if this would not imply analyzing a huge amount of data. We present an approach for identifying candidate classes for reverse engineering and reengineering efforts. Our solution is based on summarizing the changes in the evolution of object-oriented software systems by defining history measurements. Our approach, named Yesterday's Weather, is an analysis based on the retrospective empirical observation that classes which changed the most in the recent past also suffer important changes in the near future. We apply this approach on two case studies and show how we can obtain an overview of the evolution of a system and pinpoint its classes that might change in the next versions.