Researchers in Mining (open-source) Software Repositories (MSR) often create datasets that should survive the single paper and support long-term investigation of specific phenomena. Although popular, these studies recurrently deal with similar technical limitations. For instance, public collaborative development platforms, such as GitHub, impose hourly rate limits on their API requests. Furthermore, depending on network and API conditions, queries can fail and disrupt the process. These unexpected events can slow down or even invalidate the mining. Nevertheless, there are ways to minimize the undesirable effects in a reusable way while still complying with such limitations. However, best practices are often (re-)implemented on an ad hoc basis. Whatever works.

Since its inception, UML, the Unified Modeling Language, has been touted as the way to go when it comes to designing and documenting software systems. While being an integral part of many university software engineering programs, UML has found little consideration among developers, especially in open source software. Reasons for this include that UML shares some shortcomings with other forms of documentation (e.g., limited availability, outdatedness, inadequate level of detail). We present a study to investigate the evolution and the current situation regarding the use of UML in open source projects. We mined and analyzed ~ 13k GitHub projects, developing strategies and heuristics to identify UML files through their extensions and contents, for a quantitative analysis of two decades of evolution of the usage of UML. We explored the popularity of UML, derived characteristics of projects leveraging UML, and analyzed the authors, creators and maintainers, of UML artifacts. Our study confirms that UML is indeed still under-utilized. At the same time we found evidence of a resurgence coinciding with the popularity of human-readable text-based formats, defined and used by tools like PlantUML and Mermaid. We discuss how identifying and addressing the new challenges implied by this resurgence could impact the future of UML.

Adopted by companies such as Netflix, Amazon, and Spotify, the microservices architectural style is now well established. Aimed at facilitating software evolution, it is renowned for modularizing a software system into microservices, implemented in various technologies. Regarding databases, practitioners opt for polyglot persistence: Each microservice is responsible for its own database(s). This influences how the architecture is implemented. The decoupling and heterogeneity of microservices and their databases spread data access points throughout the codebase, complicating program comprehension and code-data co-evolution. Developers' feedback reveals their struggles to obtain a holistic view of data access in such architectures. We present Denim, a tool that enables users to identify data access points in microservices and visualize them in an interactive treemap. Using real microservice applications, we illustrate how this tool can be used for software evolution tasks. https://figshare.com/s/6f1d970b87b7ebce939f?file=54914249

Development teams for mobile applications can receive thousands of user reviews daily. At the same time, these developers use different communication channels, such as the GitHub issue tracker. Although GitHub issues are accessible and manageable for developers, their content often differs starkly from what users write in app reviews. Issues may lack steps to reproduce bugs or insights that justify the priority of new feature requests. The sheer volume of user reviews for a popular app, combined with their heterogeneity and varying quality, makes manual integration into issue trackers unfeasible. We present an approach that automatically augments GitHub issues with informative user reviews to bridge the gap between user feedback and developer-managed issues. Using a state-of-the-art large language model (LLM), our approach automatically retrieves user reviews with high semantic textual similarity (STS) to the issue content and suggests reviews that augment developers' understanding of the issue. In this paper, we present large-scale quantitative and qualitative analyses to assess the feasibility of enriching development workflows with user-written information. Using over 37,000 issues and 750,000 reviews from 19 popular Free/Libre/Open Source Software (FLOSS) mobile applications, our approach augments 3,017(8%) issues with 7,287 (1%) potentially informative reviews. In addition to providing insights into user-reported bugs and feature requests, the information from these matches points toward a novel and promising way to leverage user reviews for concerted app evolution.

Over the past decade, microservices have gained significant popularity, impacting how applications are designed and deployed. Maintaining a comprehensive high-level view of microservices applications is essential, especially for software evolution tasks, enabling developers to understand, maintain, and optimize the complex interactions across various services. Developers struggle to obtain such an overview, particularly from a data perspective. Currently, when changes occur, they must identify data access code fragments dependent on the modified parts, or manually search through the entire codebase for potentially impacted ones. This process is time-consuming, error-prone, and cumbersome, especially in large codebases residing in multiple repositories and accessing multiple databases. We present a novel approach to support code and data coevolution comprehension. We mine data access fragments using a custom static analyzer and use interactive treemaps to generate a high-level view of the architecture, which can be explored at various levels of detail allowing, among the others, several and quick what-if analyses to assess the impact of changes (e.g., data concept modification, technology switch). As a case study, we use Overleaf, a popular online LATEX collaborative authoring platform, to evaluate our approach. We compared multiple versions and analyzed the evolution of 1.9 k code fragments associated to more than 350 data concepts across 13 microservices, 855 directories, and 3.5 k files mixing different data access technologies. We complement our analysis with insights and reflections on the promising approach.

The comprehension of software evolution remains one of the most challenging and time-intensive tasks in software development, further complicated by the sheer size and complexity of systems. Researchers have addressed the problem in several ways, using both static and dynamic analysis. Visualization has proven to be a promising technique, and over the years a myriad of approaches in 2D and 3D have been proposed, even extending in more recent times to virtual reality (VR). All leverage the most used human sense, vision. We present an approach that leverages our second most used sense, hearing, by mapping the information related to software evolution onto sounds, thus opening up an underexplored domain, the one of software sonification. Data about software evolution is intrinsically centered around time, which is one of the things that hearing as a sense is good at: processing information sequentially. Our approach, implemented in a tool, enables sonifying the evolution of the files belonging to a software repository over time, utilizing harmonic chord progressions to represent code changes and identifying developers through musical instruments. We illustrate the feasibility of our approach with a case study and report on insights and reflections.

The Unix terminal, or just simply, the terminal, can be found being applied in almost every facet of computing. It is available across all major platforms and often integrated into other applications. Due to its ubiquity, even marginal improvements to the terminal have the potential to make massive improvements to productivity on a global scale. We believe that evolutionary improvements to the terminal, in its current incarnation as windowed terminal emulator, are possible and that developing a thorough understanding of issues that current terminal users face is fundamental to knowing how the terminal should evolve. In order to develop that understanding we have mined Unix and Linux Stack Exchange using a fully-reproducible method which was able to extract and categorize 91.0 % of 1,489 terminal-related questions (from the full set of nearly$\mathbf{2 4 0, 0 0 0}$questions) without manual intervention. We present an analysis, to our knowledge the first of its kind, of windowed terminal-related questions posted over a 15-year period and viewed, in aggregate, approximately 40 million times. As expected, given its longevity, we find the terminal's many features being applied across a wide variety of use cases. We find evidence that the terminal, as windowed terminal emulator, has neither fully adapted to its now current graphical environment nor completely untangled itself from features more suited to incarnations in previous environments. We also find evidence of areas where we believe the terminal could be extended along with other areas where it could be simplified. Surprisingly, while many current efforts to improve the terminal include improving the terminal's social and collaborative aspects, we find little evidence of this as a prominent pain point.

The popularity of microservices has grown significantly over the past decade. This architectural style is praised for its ability to ease software evolution, particularly due to the modular, heterogeneous, and dynamic communication nature of microservices. This new way of designing applications has also impacted how databases are integrated. Practitioners generally opt for polyglot persistence, meaning that each microservice manages its own database(s). Decoupling, heterogeneity, and distribution introduce implicit dependencies and multiply data access endpoints. This results in added complexity and challenges in understanding change propagation, which can only be addressed through manual browsing of the codebase, a time-consuming, error-prone, and cumbersome process. A holistic view of such architectures is essential, especially for enabling developers to understand, maintain, and optimize the complex interactions across microservices, particularly from a data perspective.We extend a visualization-based approach to support both a high-level view and fine-grained inspection of microservices. Based on static analysis, we generate an interactive treemap for an entire microservices architecture, providing both an overview and the means for more detailed exploration.We evaluated our approach by assessing the scalability and effectiveness of our visualization. First, we generated interactive treemaps for 10 non-trivial microservices architectures. Then, in a qualitative user study, we asked 6 professional developers to perform specific exploration and understanding tasks (e.g., understanding architectural structure, assessing concept spreading, evaluating technology breakdown, comparing versions, identifying anti-patterns). Our results show that interactive treemaps provide the holistic view needed to aid in evolution tasks.

The lifecycle and development of software systems are strongly dependent on time: A critical dimension that must be considered when analyzing software evolution. Many visualization approaches have been proposed to support developers in analyzing software systems. Yet, most of these focus on static representations, which struggle to convey evolution in time, and leverage only vision. In contrast, hearing—although underutilized—is well suited for processing sequential information, making sound a powerful medium to convey changes chronologically.We present a multimodal approach, implemented in a tool named SonicSight, that combines software sonification and visualization to analyze the development pace of software repositories interactively. A pulse synthesizer modulates its speed based on daily commits, while frequencies represent individual developers and their contribution activity. To support interpretation, the sonification is paired with a real-time interactive visual representation of software-related information. We illustrate such sonified visualization approach through case studies and discuss the underlying time model we employed, crucial for representing both sound and the temporal nature of software evolution.

Understanding the changes made by developers when they submit a pull request and/or perform a commit on a repository is a crucial activity in software maintenance and evolution. The common way to review changes relies on examining code diffs, where textual differences between two file versions are highlighted in red and green to indicate additions and deletions of lines. This can be cumbersome for developers, making it difficult to obtain a comprehensive overview of all changes in a commit. Moreover, certain types of code changes can be particularly significant and may warrant differentiation from standard modifications to enhance code comprehension. We present a novel visualization approach supported by a tool named ChangePrism, which provides a way to better understand code changes. The tool comprises two components: extraction, which retrieves code changes and relevant information from the git history, and visualization, which offers both general and detailed views of code changes in commits. The general view provides an overview of different types of code changes across commits, while the detailed view displays the exact changes in the source code for each commit. Video demonstration: https://youtu.be/jMoGLfM3KIM

Classes are the fundamental building blocks of object-oriented software systems, making their comprehension critical for effective software maintenance and evolution. Traditional source code views provide detailed information but often lack intuitive representations that reveal the structural and behavioral roles of a class at a glance. This is even harder for an overview of multiple classes in large and complex codebases. Moreover, identifying patterns and anomalies within classes remains challenging through conventional inspection.We propose Class Contours, a novel visualization metaphor that portrays individual classes as simple 2D architectural structures. Our approach visually encodes key class properties (e.g., lines of code, attributes, accessors) into customizable building features (e.g., windows, door frames, doors), supporting pattern recognition and task-specific visual exploration. With ZION, the tool we developed to exemplify our approach, we investigate how common class types correspond to recurring visual archetypes, allowing developers to swiftly recognize typical roles and structures within software systems.Our initial findings suggest that the simple but effective metaphor can enhance the understanding of class semantics in large codebases and support the identification of design issues and code smells.

Microservices have become a prevalent architectural style over the past decade, emphasizing the modular and dynamic nature of heterogeneous and distributed units that communicate with each other. Moreover, they promote polyglot persistence, meaning that each microservice is responsible for managing its own database(s), often with heterogeneous technologies. One of the downsides is the increase of the number and diversity of data access endpoints and exchanges. Additionally, the decomposition introduces implicit dependencies that affect code and data understanding and co-evolution. Maintaining a comprehensive high-level view of this kind of architecture is challenging, yet essential for software evolution tasks. Previous works have already proposed holistic representations and visualizations of data access in microservices. However, these are mainly based on structural and fixed snapshots, neglecting the dynamic perspective.We present an approach to enhance static visualizations. First, we record data-access-centered execution traces in microservices architectures through a static analysis-based refinement of dynamic instrumentation. Then, we replay scenarios over an existing static treemap, animating the sequence of data accesses and highlighting hotspots in the codebase through time. Our contribution, the animated heat treemap, helps developers to understand how data management operates inside microservices. We validated our approach on Overleaf, a popular online collaborative LATEX authoring platform, with a real-world scenario. We discuss the results obtained and provide insights and reflections.

Commits, which log the changes that have been performed by developers, are the central mechanism to drive the evolution of software systems. Understanding the intricacies of commits can be a nontrivial endeavour. Firstly, this is due to the diff-based textual nature of how versioning systems record the changes. Moreover, a commit can involve several files and pertain to various, overlapping tasks that the developer was tackling, which can lead to difficult to understand “tangled commits”. Furthermore, often commit messages lack quality. The only mechanism to really understand the changes performed in a commit is given by text-based “diff” representations, which are cumbersome to use. We present an approach, based on interactive animated visualizations, to facilitate the comprehension of the changes tracked by commits. To validate the approach, we implemented an interactive visual analytics tool which allows developers to dissect a commit in its constituent parts and observe, through the animations supported by our tool, the specifics of each change. We illustrate our approach with examples, and report on our findings and insights.

A crucial activity in software maintenance and evolution is the comprehension of the changes performed by developers, when they submit a pull request and/or perform a commit on the repository. Typically, code changes are represented in the form of code diffs, textual representations highlighting the differences between two file versions, depicting the added, removed, and changed lines. This simplistic representation must be interpreted by developers, and mentally lifted to a higher abstraction level, that more closely resembles natural language descriptions, and eases the creation of a mental model of the changes. However, the textual diff-based representation is cum-bersome, and the lifting requires considerable domain knowledge and programming skills. We present an approach, based on the concept of micro-change, to overcome these difficulties, trans-lating code diffs into a series of pre-defined change operations, which can be described in natural language. We present a catalog of micro-changes, together with an automated micro-change detector. To evaluate our approach, we performed an empirical study on a large set of open-source repositories, focusing on a subset of our micro-change catalog, namely those related to changes affecting the conditional logic. We found that our detector is capable of explaining more than 67% of the changes taking place in the systems under study.

Exploring and comprehending a software system, e.g., as preparation for its re-engineering, is a relevant, yet challenging endeavour often conducted by teams of engineers. Collaborative exploration tools aim to ease the process, e.g., via interactive visualizations in virtual reality (VR). However, these neglect to provide engineers with capabilities for persisting their thoughts and findings.

Understanding software systems is a vital task, often undertaken by teams of engineers, for the development and maintenance of systems. Collaborative software visualization tools are essential in this context, yet they are limited. Existing tools, particularly in virtual reality, allow exploration but lack the crucial feature of note-taking, which is a significant limitation.

UML artifacts constitute a key (but often neglected) asset supporting the comprehension of a system. Design documents "bind" developers in implementation phases and close the loop as documentation of the implemented system itself. Nevertheless, the intended system (design), its current version (implementation), and its documentation, naturally tend to drift apart, negatively impacting the usefulness of UML diagrams contained in such artifacts.

Understanding the evolution of software systems is a challenging task, due to their sheer size and complexity. Several visualization approaches have been presented over the years, using both 2D and 3D depictions. The vast majority of the approaches is geared towards understanding the “big picture”, facilitating the comprehension of the overall evolution. However, when it comes to understanding the basic building blocks of software evolution, i.e., the commits performed by the developers, visualization seems to fall short in favor of the de facto standard of textual diff views. We present an approach, implemented in a custom tool, to depict commits using interactive animations which allow the viewer to inspect and dissect the intricacies of one or multiple commits. We illustrate our approach on a number of case studies, showing its potential benefits.

Analyzing developers' activity is an essential step in understanding a software project. When assessing the status of a project and studying its history and development, it is vital to assess the performance of each contributor with high precision. Unfortunately, as Version Control Systems (VCS) do not manage the concept of developer identity in a precise fashion, it is often hard to connect a single identity with all the contributions a user has made to the project, by taking into account potential aliases of the same person. Our work aims to bridge this gap by processing the information related to the identities of contributors in the most popular projects available on GitHub, and to visualize their activity over time. The visualized identities are built on top of a disambiguation algorithm that aims to merge aliases of the same person into a single entity. Moreover, we perform bot detection to differentiate the activity made by bots from the one of humans. At last, we cluster the resulting identities to find users with the same activity patterns. By interacting with the proposed visualizations, one can precisely analyze the contributions of the people working on a project. Video URL: https://youtu.be/098IsBDBXKY

Software visualization concerns itself with the visual depiction of software systems to facilitate their comprehension. Any visualization approach, whether 2D or 3D or immersive, comes with a plethora of configuration possibilities (e.g., which types of artifacts to visualize and how, which layouts to use). This reflects the complexity of the domain at hand, where manipulating millions of entities pertaining to dozens of different types of artifacts is common. Most visualization tools encode their customizations in the form of view configurations/specifications (in short viewspecs), which are either created declaratively (using DSLs), or through custom user interfaces. In the case of immersive visualization, approaches using such customization facilities are cumbersome, may generate unnecessary context and paradigm switches, and fail to leverage the full potential of modern VR headsets' controllers. We present an approach to interactively manipulate the view specifications by depicting them as 3D objects in the immersive space, supporting definition and configuration with an automatic reflection-based mapping of the software domain model under exploration. IVAR - NI, the tool we developed, incorporates new immersive interaction paradigms (e.g., slot-based selection) and in-object real-time feedback (e.g., preview of the view specification effects) to enhance the usability of this new generation of VR-native interfaces for software visualization customization. https://youtu.be/HsWGtrINtHc

MongoDB is one of the most popular NoSQL database engines. To foster scalability, it provides multiple features such as schemaless data storage or sharding. However, those new features introduce additional considerations for the maintainer to be careful, which might lead to erroneous implementation choices often referred to as code smells or antipatterns. Detecting and fixing those code smells can play a crucial role for developers in their maintenance efforts. We present SMEAGOL (SMEll and Antipattern detection for monGOdb appLications), a static analysis tool to detect MongoDB code smells in JavaScript applications. SMEAGOL relies on CodeQL and detects code smells by analyzing and extracting all the necessary information (e.g., data structure) from the database access code of the application. We demonstrate it by examining the evolution of MongoDB code smells in five popular open-source projects, showing promising results. Video link: https://youtu.be/h4Xbp9dIFtO Repository link: https://github.com/bocherry/SMEAGOL_tool

Code smells are symptoms of poor design or bad implementation choices. Their automatic detection is helpful for various reasons. For example, the detected smells can guide developers during code inspection to find the causes of maintenance problems. Many code smells have been proposed for several technologies, including database communication, such as ORM or SQL antipatterns. However, despite its popularity, no research has been conducted on MongoDB smells. We present a systematic multivocal literature mapping study, also covering “grey” literature, to build a catalog of MongoDB code smells. After evaluating 1,498 artifacts (e.g., blog posts, online articles, book chapters, scientific papers, presentation slides, and videos) from 12 search engines, we manually reviewed 174 sources and devised a catalog of 76 smells organized into 11 categories. We present the catalog of MongoDB code smells through a series of examples.

Comprehending large-scale software systems is a challenging and daunting task, particularly when only source code is available. While software visualization attempts to aid that process, existing tools primarily visualize a system's structure in terms of files, folders, packages, or namespaces, neglecting its logical decomposition into cohesive architectural components. We present the tool Immersive Software Archaeology (ISA) which (i) estimates a view of a system's architecture by utilizing concepts from software architecture recovery and (ii) visualizes the results in virtual reality (VR) so that users can explore a subject system interactively, making the process more engaging. In VR, a semantic zoom lets users gradually transition between architectural components of different granularity and class-level elements while relationship graphs let users navigate along connections across classes and architectural components. We present results from a controlled experiment with 54 partic-ipants to investigate the usefulness of ISA for assisting engineers with exploring an unfamiliar large-scale system compared to another state-of-the-art VR approach and an IDE. Video Demonstration-https://youtu.belFl_SsT1314k

Fuzz testing, also known as fuzzing, is a software testing technique aimed at identifying software vulnerabilities. In recent decades, fuzzing has gained increasing popularity in the research community. However, existing studies led by fuzzing experts mainly focus on improving the coverage and performance of fuzzing techniques. That is, there is still a gap in empirical knowledge regarding fuzzing, especially about the challenges developers face when they adopt fuzzing. Understanding these challenges can provide valuable insights to both practitioners and researchers on how to further improve fuzzing processes and techniques. We conducted a study to understand the challenges encountered by developers during fuzzing. More specifically, we first manually analyzed 829 randomly sampled fuzzing-related GitHub issues and constructed a taxonomy consisting of 39 types of challenges (22 related to the fuzzing process itself, 17 related to using external fuzzing providers). We then surveyed 106 fuzzing practitioners to verify the validity of our taxonomy and collected feedback on how the fuzzing process can be improved. Our taxonomy, accompanied with representative examples and highlighted implications, can serve as a reference point on how to better adopt fuzzing techniques for practitioners, and indicates potential directions researchers can work on toward better fuzzing approaches and practices.

Re-architecting a software system requires significant preparation, e.g., to scope and design new modules with their boundaries and constituent classes. When planning an intended future state of a system as a re-engineering goal, engineers often fall recur to mechanisms such as freehand sketching (using a whiteboard). While this ensures flexibility and expressiveness, the sketches remain disconnected from the source code. The alternative, tool-supported diagramming on the other hand considerably restricts flexibility and impedes free-form communication.We present a method for preparing the architectural software re-engineering via freehand sketches in virtual reality (VR) that can be seamlessly integrated with the model structure of a software visualization and, thus, also the code of a system, for productive use: Engineers explore a subject system in the immersive visualization, while freehand sketching their insights and plans. Our concept automatically interprets sketched shapes and connects them to the system’s source code, and superimposes code-level references into a sketch to support engineers in reflecting on their sketches.We evaluated our method in an iterative interview-based case study with software developers from four different companies, where they planned a hypothetical re-engineering of an open-source software system.

The comprehension of very large-scale software system evolution remains a challenging problem due to the sheer amount of time-based (i.e., a sequence of changes) data and its intrinsically complex nature (i.e., heterogeneous changes across the entire system source code). It is a necessary step for program comprehension, as systems are not simply created out of thin air in a bang, but are the sum of many changes over long periods of time, by various actors and due to various circumstances.We present SYN, a web-based tool that uses versatile vi-sualization and data processing techniques to create scalable depictions of ultra-scale software system evolution. SYN has been successfully applied on several systems versioned on GitHub, including the nearly 20-year history of the Linux operating system, which totals more than one million commits on more than 100k evolving files.Webpage of the tool and demo video: https://syn.si.usi.ch

Modern instant messaging applications (e.g., Gitter, Slack, Discord) provide users with real-time communication means. Developers use them for collaborative development, to ask for code reviews, and to have software-related discussions. In short, a (potential) treasure trove for program comprehension. However, as with any high-throughput "chat application", messages interleave, leading to concurrent conversations. Associating messages to conversations is called conversation disentanglement, a useful and necessary pre-processing step to analyze datasets of instant messages. Although various conversation disentanglement algorithms have been proposed, it is cumbersome to set up proper execution environments and hard to ensure input data format consistency, calling for better practices and tool support.We present CODI, a RESTful API micro-service and web interface for conversation disentanglement. It provides an easy way to disentangle conversation transcripts with pre-trained models or to train new ones on custom datasets, features, and hyper-parameters. CODI achieves state-of-the-art performances on transcripts of IRC, Slack, and Discord conversations. We show how CODI can provide a significant improvement to reusability (and replicability) of research results, while reducing the efforts and potential mistakes due to configuration, setup, and execution.CODI’s source code: https://github.com/USIREVEAL/CODI

There has been some recent clamor about the developer layoff and turnover policies enacted by high-profile corporate executives. Precisely defining the contributions in software development has always been a thorny issue, as it is difficult to establish a developer’s “performance” without recurring to guesswork, due to how software development works and how Git persists history. Taking inspiration from a seemingly informal notion, the pony factor, we present an approach to identify the key developers in a software project. We present an analysis of 1,011 GitHub repositories, providing fact-based reflections on development contributions.

Modern JavaScript development relies heavily on using Node Package Manager (NPM) modules. These modules are related by dependency relationships, possibly requiring dozens or hundreds of modules to build a complete JavaScript web application. Studying dependencies, in terms of their sustainability, vulnerability, size, defects, etc., is fundamental for the deployment and maintenance of JavaScript web applications. We use a 3D metaphor based on presenting dependencies as an “elevated city”, mapping both dependency relationships and characteristics of interest of each module. We developed a VR (virtual reality) scene representing the dependencies of several web applications using the elevated city metaphor, and exposed industrial experts to it to check its suitability. They explored a medium-sized project, with more than 200 dependencies, sharing their insights. The results highlight different aspects of our approach and how the combination of metrics helps experts to obtain insights from the ecosystem. The feedback shows the usefulness of the visualization to check and explore several aspects of the dependencies of an application, helping to identify problems related to maintainability, license usage, or vulnerabilities, and to design strategies to address them.

Over the past decades, researchers proposed numerous approaches to visualize source code. A popular one is CodeCity, an interactive 3D software visualization representing software system as cities: buildings represent classes (or files) and districts represent packages (or folders). Building dimensions represent values of software metrics, such as number of methods or lines of code. There are many implementations of CodeCity, the vast majority of them running on-screen. Recently, some implementations using virtual reality (VR) have appeared, but the usefulness of CodeCity in VR is still to be proven. Our comparative study aims to answer the question “Is VR well suited for CodeCity, compared to the traditional on-screen implementation?” We performed two experiments with our web-based implementation of CodeCity, which can be used on-screen or in immersive VR. First, we conducted a controlled experiment involving 24 participants from academia and industry. Taking advantage of the obtained feedback, we improved our approach and conducted a second controlled experiment with 26 new participants. Our results show that people using the VR version performed the assigned tasks in much less time, while maintaining a comparable level of correctness. VR is at least equally well-suited as on-screen for visualizing CodeCity, and likely better.

Automatically linking bug-fixing changes to bug-inducing ones (BICs) is one of the key data-extraction steps behind several empirical studies in software engineering. The SZZ algorithm is the de facto standard to achieve this goal, with several improvements proposed over time. Evaluating the performance of SZZ implementations is, however, far from trivial. In previous works, researchers (i) manually assessed whether the BICs identified by the SZZ implementation were correct or not, or (ii) defined oracles in which they manually determined BICs from bug-fixing commits. However, ideally, the original developers should be involved in defining a labeled dataset to evaluate SZZ implementations. We propose a methodology to define a “developer-informed” oracle for evaluating SZZ implementations, without requiring a manual inspection from the original developers. We use Natural Language Processing (NLP) to identify bug-fixing commits in which developers explicitly reference the commit(s) that introduced the fixed bug. We use the built oracle to extensively evaluate existing SZZ variants defined in the literature. We also introduce and evaluate two new variants aimed at addressing two weaknesses we observed in state-of-the-art implementations (i.e., processing added lines and handling of revert commits).

Energy consumption in mobile applications is a key area of software engineering studies, since any advance could affect billions of devices. Currently, several software-based energy calculation tools can provide close estimates of the energy consumed by mobile applications without relying on physical hardware, offering new opportunities to conduct large-scale energy studies in mobile devices. In these studies, one key step of data collection is generating events, since it allows exercising specific parts of the code and, as a consequence, assessing their energy consumption. Given the fact that manually generating events by interacting with applications is time-consuming and not scalable, large-scale studies often use software-based tools to automate event generation to profile devices. Existing tools rely on randomly generated events, which undermines the reproducibility and generalizability of such studies.We present AIP (Android Instrumentation Profiler), an alternative to existing software-based event generation tools such as Monkey. AIP uses instrumented tests as a source of event generation, which enables the targeting of complex use cases for energy consumption estimations, as well as the creation of fully reproducible events and execution traces, while maintaining the scaling abilities of other state-of-the-art tools. The tool and demo video can be found on https://github.com/ONourry/AndroidInstrumentationProfiler.

New communication platforms have emerged to support developers in finding and creating the knowledge they need for program comprehension, maintenance, and evolution. Instant messaging applications are supplanting developer mailing lists in collaborative development toolchains. These applications provide a new medium, supporting faster and richer communication (e.g., embedded previews, images, files, videos). Research so far focused on extracting information from these platforms, but there is a lack of tools to visually and interactively explore them.We present DiscOrDance, a tool for the interactive visual exploration of the complete message history of a Discord server. We show how three categories of views elicit insights on aspects of the structure, members, and software related content of a Discord server. We demonstrate use cases of DiscOrDance to support software maintenance and evolution activities on an active software developer community, the Pharo Discord server.Demo video: https://youtu.be/eYCLGWwM9HYTool homepage: https://DiscOrDance.si.usi.ch

Modern communication platforms used in software development host daily conversations among developers and users about a wide range of topics pertaining to software systems, such as language features, APIs, code artifacts like classes and methods, design patterns, usage examples, code reviews, bug reporting and fixing. Discord servers are one of these virtual community hubs that have seen a steep rise in popularity, as coordination and aggregation means for communities of developers. Although Discord supports filter-based search functionalities, the sheer volume, velocity, and small granularity of single messages make it hard to find useful results, let alone complete discussions revolving around particular themes. One reason is that the concept of a discussion, which we call a conversation, does not exist as an explicit concept. We argue that extracting and analyzing such conversations can be used fruitfully to aid program comprehension.

In object-oriented programming, classes are the primary abstraction mechanism used by and exposed to developers. Understanding classes is key for the development and evolution of object-oriented applications. The fundamental problem faced by developers is that while classes are intrinsically structured entities, in IDEs they are represented as a blob of text. The idea behind the original CLASS BLUEPRINT visualization was to represent the internal structure of classes in terms of fields, their accesses, and the method call flow. Additional information was depicted using colors. The thus created visualization proved to be an effective means to support program comprehension. However, a number of omissions rendered it only partially useful.We propose CLASS BLUEPRINT V2 (in short BLUEPRINTV2), which in addition to the information depicted by CLASS BLUEPRINT also supports dead code identification, methods under tests, and calling relationships between class and instance level methods. In addition, BLUEPRINTV2 enhances the understanding of fields by showing how fields of super/subclasses are accessed. We present the enhanced visualization and report on a first validation with 26 developers and 18 projects.

In the past years numerous software visualization tools have been introduced to support the analysis of software systems and their evolution as captured in the versioning systems. Usually the target audience of such tools comprises software engineering professionals. In this paper we argue that such tools are also beneficial for educators who need to evaluate the quality of software systems developed by students. However, since the needs of educators are different than those of the software engineering professionals, we discuss several educator needs first. We report several usage examples that we believe are useful for educators when using repository visualization tools. We illustrate them with examples from several student projects from different courses in two universities. We conclude with a series of considerations that should be heeded by both educators and future tool-builders.

Abstract Most changes during software maintenance and evolution are not atomic changes, but rather the result of several related changes affecting different parts of the code. It may happen that developers omit needed changes, thus leaving a task partially unfinished, introducing technical debt or injecting bugs. We present a study investigating “quick remedy commits” performed by developers to implement changes omitted in previous commits. With quick remedy commits we refer to commits that (i) quickly follow a commit performed by the same developer, and (ii) aim at remedying issues introduced as the result of code changes omitted in the previous commit (e.g., fix references to code components that have been broken as a consequence of a rename refactoring) or simply improve the previously committed change (e.g., improve the name of a newly introduced variable). Through a manual analysis of 500 quick remedy commits, we define a taxonomy categorizing the types of changes that developers tend to omit. The taxonomy can (i) guide the development of tools aimed at detecting omitted changes and (ii) help researchers in identifying corner cases that must be properly handled. For example, one of the categories in our taxonomy groups the reverted commits, meaning changes that are undone in a subsequent commit. We show that not accounting for such commits when mining software repositories can undermine one’s findings. In particular, our results show that considering completely reverted commits when mining software repositories accounts, on average, for 0.07 and 0.27 noisy data points when dealing with two typical MSR data collection tasks (i.e., bug-fixing commits identification and refactoring operations mining, respectively).

Opinion mining, sometimes referred to as sentiment analysis, has gained increasing attention in software engineering (SE) studies. SE researchers have applied opinion mining techniques in various contexts, such as identifying developers’ emotions expressed in code comments and extracting users’ critics toward mobile apps. Given the large amount of relevant studies available, it can take considerable time for researchers and developers to figure out which approaches they can adopt in their own studies and what perils these approaches entail. We conducted a systematic literature review involving 185 papers. More specifically, we present (1) well-defined categories of opinion mining-related software development activities, (2) available opinion mining approaches, whether they are evaluated when adopted in other studies, and how their performance is compared, (3) available datasets for performance evaluation and tool customization, and (4) concerns or limitations SE researchers might need to take into account when applying/customizing these opinion mining techniques. The results of our study serve as references to choose suitable opinion mining tools for software development activities and provide critical insights for the further development of opinion mining techniques in the SE domain.

Refactoring operations are behavior-preserving changes aimed at improving source code quality. While refactoring is largely considered a good practice, refactoring proposals in pull requests are often rejected after the code review. Understanding the reasons behind the rejection of refactoring contributions can shed light on how such contributions can be improved, essentially benefiting software quality. This article reports a study in which we manually coded rejection reasons inferred from 330 refactoring-related pull requests from 207 open-source Java projects. We surveyed 267 developers to assess their perceived prevalence of these identified rejection reasons, further complementing the reasons. Our study resulted in a comprehensive taxonomy consisting of 26 refactoring-related rejection reasons and 21 process-related rejection reasons. The taxonomy, accompanied with representative examples and highlighted implications, provides developers with valuable insights on how to ponder and polish their refactoring contributions, and indicates a number of directions researchers can pursue toward better refactoring recommenders.

Refactoring aims at improving the maintainability of source code without modifying its external behavior. Previous works proposed approaches to recommend refactoring solutions to software developers. The generation of the recommended solutions is guided by metrics acting as proxy for maintainability (e.g., number of code smells removed by the recommended solution). These approaches ignore the impact of the recommended refactorings on other non-functional requirements, such as performance, energy consumption, and so forth. Little is known about the impact of refactoring operations on non-functional requirements other than maintainability. We aim to fill this gap by presenting the largest study to date to investigate the impact of refactoring on software performance, in terms of execution time. We mined the change history of 20 systems that defined performance benchmarks in their repositories, with the goal of identifying commits in which developers implemented refactoring operations impacting code components that are exercised by the performance benchmarks. Through a quantitative and qualitative analysis, we show that refactoring operations can significantly impact the execution time. Indeed, none of the investigated refactoring types can be considered “safe” in ensuring no performance regression. Refactoring types aimed at decomposing complex code entities (e.g., Extract Class/Interface, Extract Method) have higher chances of triggering performance degradation, suggesting their careful consideration when refactoring performance-critical code.

The SZZ algorithm for identifying bug-inducing changes has been widely used to evaluate defect prediction techniques and to empirically investigate when, how, and by whom bugs are introduced. Over the years, researchers have proposed several heuristics to improve the SZZ accuracy, providing various implementations of SZZ. However, fairly evaluating those implementations on a reliable oracle is an open problem: SZZ evaluations usually rely on (i) the manual analysis of the SZZ output to classify the identified bug-inducing commits as true or false positives; or (ii) a golden set linking bug-fixing and bug-inducing commits. In both cases, these manual evaluations are performed by researchers with limited knowledge of the studied subject systems. Ideally, there should be a golden set created by the original developers of the studied systems. We propose a methodology to build a "developer-informed" oracle for the evaluation of SZZ variants. We use Natural Language Processing (NLP) to identify bug-fixing commits in which developers explicitly reference the commit(s) that introduced a fixed bug. This was followed by a manual filtering step aimed at ensuring the quality and accuracy of the oracle. Once built, we used the oracle to evaluate several variants of the SZZ algorithm in terms of their accuracy. Our evaluation helped us to distill a set of lessons learned to further improve the SZZ algorithm.

Code completion is one of the killer features of Integrated Development Environments (IDEs), and researchers have proposed different methods to improve its accuracy. While these techniques are valuable to speed up code writing, they are limited to recommendations related to the next few tokens a developer is likely to type given the current context. In the best case, they can recommend a few APIs that a developer is likely to use next. We present FeaRS, a novel retrieval-based approach that, given the current code a developer is writing in the IDE, can recommend the next complete method (i.e., signature and method body) that the developer is likely to implement. To do this, FeaRS exploits "implementation patterns" (i.e., groups of methods usually implemented within the same task) learned by mining thousands of open source projects. We instantiated our approach to the specific context of Android apps. A large-scale empirical evaluation we performed across more than 20k apps shows encouraging preliminary results, but also highlights future challenges to overcome.

Refactoring as a process is aimed at improving the quality of a software system while preserving its external behavior. In practice, refactoring comes in the form of many specific and diverse refactoring operations, which have different scopes and thus a different potential impact on both the production and the test code. We present a large-scale quantitative study complemented by a qualitative analysis involving 615,196 test cases to understand how and to what extent different refactoring operations impact a system's test suites. Our findings show that while the vast majority of refactoring operations do not or very seldom induce test breaks, some specific refactoring types (e.g., “RENAME Attribute” and “RENAME Class”) have a higher chance of breaking test suites. Meanwhile, “ADD Parameter” and “CHANGE Return Type” refactoring operations often require additional lines of changes to fix the test suite they break. While some modern IDEs provide features to automatically apply these two types of refactoring operations, they are not always able to avoid test breaks, thus demanding extra human efforts.

Several techniques have been proposed in the literature to support code completion, showing excellent results in predicting the next few tokens a developer is likely to type given the current context. Only recently, approaches pushing the boundaries of code completion (e.g., by presenting entire code statements) have been proposed. In this line of research, we present FeaRS, a recommender system that, given the current code a developer is writing in the IDE, recommends the next complete method to be implemented. FeaRS has been deployed to learn “implementation patterns” (i.e., groups of methods usually implemented within the same task) by continuously mining open-source Android projects. Such knowledge is leveraged to provide method recommendations when the code written by the developer in the IDE matches an “implementation pattern”. Preliminary results of FeaRS’ accuracy show its potential as well as some open challenges to overcome.

Refactoring, the process of improving the internal code structure of a software system without altering its external behavior, is widely applied during software development. Understanding how developers refactor source code can help gain better understanding of the software development process and the relationship between various versions of a system. Refactoring detection tools have been developed for many popular programming languages, such as Java (e.g., REFACTORINGMINER and REF-FINDER) but, quite surprisingly, this is not the case for Python, a widely used programming language.Inspired by REFACTORING MINER, we present PYREF, a tool that automatically detects method-level refactoring operations in Python projects. We evaluated PYREF against a manually built oracle and compared it with a PYTHON-ADAPTED REFACTOR-INGMINER, which converts Python program to Java and detects refactoring operations with REFACTORING MINER. Our results indicate that PYREF can achieve satisfactory precision and detect more refactorings than the current state-of-the-art.

The city metaphor for visualizing software systems in 3D has been widely explored and it has led to many diverse implementations and approaches. However, when looking at software systems in general, and when using specifically a city approach, it is evident that something is missing: The data. Indeed, software systems are intrinsically driven by data, which is usually managed using databases or often also simply stored in files coming in a variety of formats, such as CSV, XML, and JSON. While such data files are part of a project’s file system and can thus be easily retrieved, the situation is different for databases: A database is usually not contained in the file system, and its presence can only be inferred from the source code which contains the database accesses.We present an extension of the CodeCity implementation, M3TRICITY2, with two new contributions: First, we consider data files and use simple metrics to integrate them in the visualization seamlessly. Second, we present a novel way to add a database to the visualization by making use of the one remaining space left unused: the sky and the underground. We present our contributions and illustrate them on various software systems.

The rise of distributed version control systems, such as git, and platforms built on top of it, such as GitHub, has triggered a change in how software is developed. Most notably, state-of-the-art practice foresees the use of pull requests and issues, enriched by means to enable discussions among the involved people. Platforms like GitHub and GitLab have thus turned into comprehensive and cohesive modern software development environments, also offering additional mechanisms, such as code review tools and a transversal support for continuous integration and deployment. However, the plethora of concepts, mechanisms, and their interconnections are stored and presented in textual form, which makes the understanding of the underlying evolutionary processes difficult.We introduce the notion of an issue tale, a visual narrative of the events and actors revolving around any GitHub issue, and present an approach, implemented as an interactive visual analytics tool, to depict and analyze the relevant information pertaining to issue tales. We illustrate our approach and its implementation on several open-source software systems.

Over the past decades, researchers proposed numerous approaches to visualize source code. A prominent one is CodeCity, an interactive 3D software visualization that leverages the "city metaphor" to represent software system as cities: buildings represent classes (or files) and districts represent packages (or folders). Building dimensions represent values of software metrics, such as the number of methods or the lines of code. There are many implementations of CodeCity, the vast majority of them running on-screen. Recently, some implementations visualizing CodeCity in virtual reality (VR) have appeared. While exciting as a technology, VR’s usefulness remains to be proven.The question we pose is: Is VR well suited to visualize CodeCity, compared to the traditional on-screen implementation?We performed an experiment in our interactive web-based application to visualize CodeCity. Users can fetch data from any git repository and visualize its source code. Our application enables users to navigate CodeCity both on-screen and in an immersive VR environment, using consumer-grade VR headsets like Oculus Quest. Our controlled experiment involved 24 participants from academia and industry. Results show that people using the VR version performed the assigned tasks in much less time, while still maintaining a comparable level of correctness.Therefore, our results show that VR is at least equally well-suited as on-screen for visualizing CodeCity, and likely better.

The last decade has seen the rise of global software community platforms, such as Slack, Gitter, and Discord. They allow developers to discuss implementation issues, report bugs, and, in general, interact with one another. Such real-time communication platforms are thus slowly complementing, if not replacing, more traditional communication channels, such as development mailing lists. Apart from simple text messaging and conference calls, they allow the sharing of any type of content, such as videos, images, and source code. This is turning such platforms into precious information sources when it comes to searching for documentation and understanding design and implementation choices. However, the velocity and volatility of the contents shared and discussed on such platforms, combined with their often informal structure, makes it difficult to grasp and differentiate the relevant pieces of information.We present a visual analytics approach, supported by a tool named DiscOrDance, which provides numerous custom views to support the understanding of Discord servers in terms of their structure, contents, and community. We illustrate DiscOrDance, using as running example the public Pharo development community Discord Server, which counts to date ∼180k messages shared among ∼2,900 developers, spanning 5 years of history. Based on our analyses, we distill and discuss interesting insights and lessons learned.

Since their invention, treemaps have been widely used to visualize hierarchical structures, due to their intuitive nature and their scaling capability: Indeed, given a maximum treemap size, one can depict hierarchical structures, such as file and software systems, of arbitrary size and depth. To make up for the rather blocky nature of treemaps, Voronoi treemaps were introduced, leading to depictions that look more "organic". However, hierarchical structures in general, evolve over time, and this is especially the case for software.We present Voronoi Evolving Treemaps (VET), a novel approach inspired by the Voronoi power-weighted treemap algorithm, that takes into account the evolution of hierarchical structures. VET is able to display the complete evolution of a software system in terms of its hierarchical structure, and enriches the visualization with additional information. We detail VET’s evolutionary layout algorithm, discuss the architecture, implementation, and the features of VET, and illustrate how VET can be used to analyze the evolution of different systems.

Developers do not always have the knowledge needed to understand source code and must refer to different resources (e.g., teammates, documentation, the web). This non-trivial process, called program comprehension, is very time-consuming. While many approaches support the comprehension of a given code at hand, they are mostly focused on defining extractive summaries from the code (i.e., on selecting from a given piece of code the most important statements/comments to comprehend it). However, if the information needed to comprehend the code is not there, their usefulness is limited. We present ADANA, an approach to automatically inject comments describing a given piece of Android code. ADANA reuses the descriptions of similar and well-documented code snippets retrieved from various online resources. Our evaluation has shown that ADANA is able to aid the program comprehension process.

In theory, (good) documentation is an invaluable asset to any software project, as it helps stakeholders to use, understand, maintain, and evolve a system. In practice, however, documentation is generally affected by numerous shortcomings and issues, such as insufficient and inadequate content and obsolete, ambiguous information. To counter this, researchers are investigating the development of advanced recommender systems that automatically suggest high-quality documentation, useful for a given task. A crucial first step is to understand what quality means for practitioners and what information is actually needed for specific tasks.

Knowledge transfer is one of the main goals of modern code review, as shown by several studies that surveyed and interviewed developers. While knowledge transfer is a clear expectation of the code review process, there are no analytical studies using data mined from software repositories to assess the effectiveness of code review in "training" developers and improve their skills over time. We present a mining-based study investigating how and whether the code review process helps developers to improve their contributions to open source projects over time. We analyze 32,062 peer-reviewed pull requests (PRs) made across 4,981 GitHub repositories by 728 developers who created their GitHub account in 2015. We assume that PRs performed in the past by a developer D that have been subject to a code review process have "transferred knowledge" to D. Then, we verify if over time (i.e., when more and more reviewed PRs are made by D), the quality of the contributions made by D to open source projects increases (as assessed by proxies we defined, such as the acceptance of PRs, or the polarity of the sentiment in the review comments left for the submitted PRs). With the above measures, we were unable to capture the positive impact played by the code review process on the quality of developers' contributions. This might be due to several factors, including the choices we made in our experimental design.Additional investigations are needed to confirm or contradict such a negative result.

Software systems are continuously modified to implement new features, to fix bugs, and to improve quality attributes. Most of these activities are not atomic changes, but rather the result of several related changes affecting different parts of the code. For this reason, it may happen that developers omit some of the needed changes and, as a consequence, leave a task partially unfinished, introduce technical debt or, in the worst case scenario, inject bugs. Knowing the changes that are mistakenly omitted by developers can help in designing recommender systems able to automatically identify risky situations in which, for example, the developer is likely to be pushing an incomplete change to the software repository.

Modern software is developed under considerable time pressure, which implies that developers more often than not have to resort to compromises when it comes to code that is well written and code that just does the job. This has led over the past decades to the concept of “technical debt”, a short-term hack that potentially generates long-term maintenance problems. Self-admitted technical debt (SATD) is a particular form of technical debt: developers consciously perform the hack but also document it in the code by adding comments as a reminder (or as an admission of guilt). We focus on a specific type of SATD, namely “On-hold” SATD, in which developers document in their comments the need to halt an implementation task due to conditions outside of their scope of work (e.g., an open issue must be closed before a function can be implemented).We present an approach, based on regular expressions and machine learning, which is able to detect issues referenced in code comments, and to automatically classify the detected instances as either “On-hold” (the issue is referenced to indicate the need to wait for its resolution before completing a task), or as “cross-reference”, (the issue is referenced to document the code, for example to explain the rationale behind an implementation choice). Our approach also mines the issue tracker of the projects to check if the On-hold SATD instances are “superfluous” and can be removed (i.e., the referenced issue has been closed, but the SATD is still in the code). Our evaluation confirms that our approach can indeed identify relevant instances of On-hold SATD. We illustrate its usefulness by identifying superfluous On-hold SATD instances in open source projects as confirmed by the original developers.

Visualization approaches that leverage a 3D city metaphor have become popular. Numerous variations, including virtual and augmented reality have emerged. Despite its popularity, the city metaphor falls short when depicting the evolution of a system, which results in buildings and districts moving around in unpredictable ways. We present a novel approach to visualize software systems as evolving cities that treats evolution as a first-class concept. It renders with fidelity not only changes but also refactorings in a comprehensive way. To do so, we developed custom ways to traverse time. We implemented our approach in a publicly accessible web-based platform named m3triCity.

Informal documentation contained in resources such as Q&A websites (e.g., Stack Overflow) is a precious resource for developers, who can find there examples on how to use certain APIs, as well as opinions about pros and cons of such APIs. Automatically identifying and classifying such opinions can alleviate developers' burden in performing manual searches, and can be used to recommend APIs that are good from some points of view (e.g., performance), or highlight those less ideal from other perspectives (e.g., compatibility). We propose POME (Pattern-based Opinion MinEr), an approach that leverages natural language parsing and pattern-matching to classify Stack Overflow sentences referring to APIs according to seven aspects (e.g., performance, usability), and to determine their polarity (positive vs negative). The patterns have been inferred by manually analyzing 4,346 sentences from Stack Overflow linked to a total of 30 APIs. We evaluated POME by (i) comparing the pattern-matching approach with machine learners leveraging the patterns themselves as well as n-grams extracted from Stack Overflow posts; (ii) assessing the ability of POME to detect the polarity of sentences, as compared to sentiment-analysis tools; (iii) comparing POME with the state-of-the-art Stack Overflow opinion mining approach, Opiner, through a study involving 24 human evaluators. Our study shows that POME exhibits a higher precision than a state-of-the-art technique (Opiner), in terms of both opinion aspect identification and polarity assessment.

(Good) Software documentation provides developers and users with a description of what a software system does, how it operates, and how it should be used. For example, technical documentation (e.g., an API reference guide) aids developers during evolution/maintenance activities, while a user manual explains how users are to interact with a system. Despite its intrinsic value, the creation and the maintenance of documentation is often neglected, negatively impacting its quality and usefulness, ultimately leading to a generally unfavourable take on documentation. Previous studies investigating documentation issues have been based on surveying developers, which naturally leads to a somewhat biased view of problems affecting documentation. We present a large scale empirical study, where we mined, analyzed, and categorized 878 documentation-related artifacts stemming from four different sources, namely mailing lists, Stack Overflow discussions, issue repositories, and pull requests. The result is a detailed taxonomy of documentation issues from which we infer a series of actionable proposals both for researchers and practitioners.

Code comments are a primary means to document source code. Keeping comments up-to-date during code change activities requires substantial time and attention. For this reason, researchers have proposed methods to detect code-comment inconsistencies (i.e., comments that are not kept in sync with the code they document) and studies have been conducted to investigate this phenomenon. However, these studies were performed at a small scale, relying on quantitative analysis, thus limiting the empirical knowledge about code-comment inconsistencies. We present the largest study at date investigating how code and comments co-evolve. The study has been performed by mining 1.3 Billion AST-level changes from the complete history of 1,500 systems. Moreover, we manually analyzed 500 commits to define a taxonomy of code-comment inconsistencies fixed by developers. Our analysis discloses the extent to which different types of code changes (e.g., change of selection statements) trigger updates to the related comments, identifying cases in which code-comment inconsistencies are more likely to be introduced. The defined taxonomy categorizes the types of inconsistencies fixed by developers. Our results can guide the development of tools aimed at detecting and fixing code-comment inconsistencies.

Android apps are inextricably linked to the official Android APIs. Such a strong form of dependency implies that changes introduced in new versions of the Android APIs can severely impact the apps' code, for example because of deprecated or removed APIs. In reaction to those changes, mobile app developers are expected to adapt their code and avoid compatibility issues. To support developers, approaches have been proposed to automatically identify API compatibility issues in Android apps. The state-of-the-art approach, named CiD, is a data-driven solution learning how to detect those issues by analyzing the changes in the history of Android APIs ("API side" learning). While it can successfully identify compatibility issues, it cannot recommend coding solutions. We devised an alternative data-driven approach, named ACRYL. ACRYL learns from changes implemented in other apps in response to API changes ("client side" learning). This allows not only to detect compatibility issues, but also to suggest a fix. When empirically comparing the two tools, we found that there is no clear winner, since the two approaches are highly complementary, in that they identify almost disjointed sets of API compatibility issues. Our results point to the future possibility of combining the two approaches, trying to learn detection/fixing rules on both the API and the client side.

Meaningful, expressive identifiers in source code can enhance the readability and reduce comprehension efforts. Over the past years, researchers have devoted considerable effort to understanding and improving the naming quality of identifiers in source code. However, little attention has been given to test code, an important resource during program comprehension activities. To better grasp identifier quality in test code, we conducted a survey involving manually written and automatically generated test cases from ten open source software projects. The survey results indicate that test cases contain low quality identifiers, including the manually written ones, and that the quality of identifiers is lower in test code than in production code. We also investigated the use of three state-of-the-art rename refactoring recommenders for improving test code identifiers. The analysis highlights their limitations when applied to test code and supports mapping out a research agenda for future work in the area.

Stack Overflow is the most popular question and answer website on computer programming with more than 2.5M users, 16M questions, and a new answer posted, on average, every five seconds. This wide availability of data led researchers to develop techniques to mine Stack Overflow posts. The aim is to find and recommend posts with information useful to developers. However, and not surprisingly, not every Stack Overflow post is useful from a developer's perspective. We empirically investigate what the characteristics of "useful" Stack Overflow posts are. The underlying assumption of our study is that posts that were used (referenced in the source code) in the past by developers are likely to be useful. We refer to these posts as leveraged posts. We study the characteristics of leveraged posts as opposed to the non-leveraged ones, focusing on community aspects (e.g., the reputation of the user who authored the post), the quality of the included code snippets (e.g., complexity), and the quality of the post's textual content (e.g., readability). Then, we use these features to build a prediction model to automatically identify posts that are likely to be leveraged by developers. Results of the study indicate that post meta-data (e.g., the number of comments received by the answer) is particularly useful to predict whether it has been leveraged or not, whereas code readability appears to be less useful. A classifier can classify leveraged posts with a precision of 65% and recall of 49% and non-leveraged ones with a precision of 95% and recall of 97%. This opens the road towards an automatic identification of "high-quality content" in Stack Overflow.

Recent studies have demonstrated that software is natural, that is, its source code is highly repetitive and predictable like human languages. Also, previous studies suggested the existence of a relationship between code quality and its naturalness, presenting empirical evidence showing that buggy code is “less natural” than non-buggy code. We conjecture that this qualitynaturalness relationship could be exploited to support refactoring activities (e.g., to locate source code areas in need of refactoring). We perform a first step in this direction by analyzing whether refactoring can improve the naturalness of code. We use state-of-the-art tools to mine a large dataset of refactoring operations performed in open source systems. Then, we investigate the impact of different types of refactoring operations on the naturalness of the impacted code. We found that (i) code refactoring does not necessarily increase the naturalness of the refactored code; and (ii) the impact on the code naturalness strongly depends on the type of refactoring operations.

Software development video tutorials have seen a steep increase in popularity in recent years. Their main advantage is that they thoroughly illustrate how certain technologies, programming languages, etc. are to be used. However, they come with a caveat: there is currently little support for searching and browsing their content. This makes it difficult to quickly find the useful parts in a longer video, as the only options are watching the entire video, leading to wasted time, or fast-forwarding through it, leading to missed information. We present an approach to mine video tutorials found on the web and enable developers to query their contents as opposed to just their metadata. The video tutorials are processed and split into coherent fragments, such that only relevant fragments are returned in response to a query. Moreover, fragments are automatically classified according to their purpose, such as introducing theoretical concepts, explaining code implementation steps, or dealing with errors. This allows developers to set filters in their search to target a specific type of video fragment they are interested in. In addition, the video fragments in CodeTube are complemented with information from other sources, such as Stack Overflow discussions, giving more context and useful information for understanding the concepts.

Sentiment analysis has been applied to various software engineering (SE) tasks, such as evaluating app reviews or analyzing developers' emotions in commit messages. Studies indicate that sentiment analysis tools provide unreliable results when used out-of-the-box, since they are not designed to process SE datasets. The silver bullet for a successful application of sentiment analysis tools to SE datasets might be their customization to the specific usage context.

Software engineering researchers have used sentiment analysis for various purposes, such as analyzing app reviews and detecting developers' emotions. However, most existing sentiment analysis tools do not achieve satisfactory performance when used in software-related contexts, and there are not many ready-to-use datasets in this domain. To facilitate the emergence of better tools and sufficient validation of sentiment analysis techniques, we present two datasets with labeled sentiments, which are extracted from mobile app reviews and Stack Overflow discussions, respectively. The web app we created to support the labeling of the Stack Overflow dataset is also provided.

The concept of monolithic stand-alone software systems developed completely from scratch has become obsolete, as modern systems nowadays leverage the abundant presence of Application Programming Interfaces (APIs) developed by third parties, which leads on the one hand to accelerated development, but on the other hand introduces potentially fragile dependencies on external resources. In this context, the design of any API strongly influences how developers write code utilizing it. A wrong design decision like a poorly chosen method name can lead to a steeper learning curve, due to misunderstandings, misuse and eventually bug-prone code in the client projects using the API. It is not unfrequent to find APIs with poorly expressive or misleading names, possibly lacking appropriate documentation. Such issues can manifest in what have been defined in the literature as Linguistic Antipatterns (LAs), i.e., inconsistencies among the naming, documentation, and implementation of a code entity. While previous studies showed the relevance of LAs for software developers, their impact on (developers of) client projects using APIs affected by LAs has not been investigated. This paper fills this gap by presenting a large-scale study conducted on 1.6k releases of popular Maven libraries, 14k open-source Java projects using these libraries, and 4.4k questions related to the investigated APIs asked on Stack Overflow. In particular, we investigate whether developers of client projects have higher chances of introducing bugs when using APIs affected by LAs and if these trigger more questions on Stack Overflow as compared to non-affected APIs.

Code quality metrics are widely used to identify design flaws (e.g., code smells) as well as to act as fitness functions for refactoring recommenders. Both these applications imply a strong assumption: quality metrics are able to assess code quality as perceived by developers. Indeed, code smell detectors and refactoring recommenders should be able to identify design flaws/recommend refactorings that are meaningful from the developer's point-of-view. While such an assumption might look reasonable, there is limited empirical evidence supporting it. We aim at bridging this gap by empirically investigating whether quality metrics are able to capture code quality improvement as perceived by developers. While previous studies surveyed developers to investigate whether metrics align with their perception of code quality, we mine commits in which developers clearly state in the commit message their aim of improving one of four quality attributes: cohesion, coupling, code readability, and code complexity. Then, we use state-of-the-art metrics to assess the change brought by each of those commits to the specific quality attribute it targets. We found that, more often than not the considered quality metrics were not able to capture the quality improvement as perceived by developers (e.g., the developer states "improved the cohesion of class C", but no quality metric captures such an improvement).

Code metrics can be used to assess the internal quality of software systems, and in particular their adherence to good design principles. While providing hints about code quality, metrics are difficult to interpret. Indeed, they take a code component as input and assess a quality attribute (e.g., code readability) by providing a number as output. However, it might be unclear for developers whether that value should be considered good or bad for the specific code at hand. We present RETICULA (REal TIme Code qUaLity Assessment), a plugin for the IntelliJ IDE to assist developers in perceiving code quality during software development. RETICULA compares the quality metrics for a project (or a single class) under development in the IDE with those of similar open source systems (classes) previously analyzed. With the visualized results, developers can gain insights about the quality of their code. A video illustrating the features of RETICULA can be found at: https://reticulaplugin.github.io/.

The promise of recommender systems is to provide intelligent support to developers during their programming tasks. Such support ranges from suggesting program entities to taking into account pertinent Q&A pages. However, current recommender systems limit the context analysis to change history and developers' activities in the IDE, without considering what a developer has already consulted or perused, e.g., by performing searches from the Web browser. Given the faceted nature of many programming tasks, and the incompleteness of the information provided by a single artifact, several heterogeneous resources are required to obtain the broader picture needed by a developer to accomplish a task. We present Libra, a holistic recommender system. It supports the process of searching and navigating the information needed by constructing a holistic meta-information model of the resources perused by a developer, analyzing their semantic relationships, and augmenting the web browser with a dedicated interactive navigation chart. The quantitative and qualitative evaluation of Libra provides evidence that a holistic analysis of a developer's information context can indeed offer comprehensive and contextualized support to information navigation and retrieval during software development.

We advocate for a paradigm shift in supporting the information needs of developers, centered around the concept of automated on-demand developer documentation. Currently, developer information needs are fulfilled by asking experts or consulting documentation. Unfortunately, traditional documentation practices are inefficient because of, among others, the manual nature of its creation and the gap between the creators and consumers. We discuss the major challenges we face in realizing such a paradigm shift, highlight existing research that can be leveraged to this end, and promote opportunities for increased convergence in research on software documentation.

Exploring and analyzing the history of changes is an intrinsic part of software evolution comprehension. Existing tools that exploit the data residing in version control repositories provide only limited support for the intuitive navigation of code changes from a historical perspective. We present the Code Time Machine, a lightweight IDE plugin which uses visualization techniques to depict the history of any chosen file augmented with information mined from the underlying versioning system. Inspired by Apple's Time Machine, our tool allows both developers and the system itself to seamlessly move through time. A video of the Code Time Machine can be found at https://youtu.be/meblwFO95oA.

Code redundancy widely occurs in software projects. Researchers have investigated the existence, causes, and impacts of code redundancy, showing that it can be put to good use, for example in the context of code completion. When analyzing source code redundancy, previous studies considered software projects as sequences of tokens, neglecting the role of the syntactic structures enforced by programming languages. However, differences in the redundancy of such structures may jeopardize the performance of applications leveraging code redundancy. We present a study of the redundancy of several types of code constructs in a large-scale dataset of active Java projects mined from GitHub, unveiling that redundancy is not uniform and mainly resides in specific code constructs. We further investigate the implications of the locality of redundancy by analyzing the performance of language models when applied to code completion. Our study discloses the perils of exploiting code redundancy without taking into account its strong locality in specific code constructs.

Online resources of formal and informal documentation-such as reference manuals, forum discussions and tutorials-have become an asset to software developers, as they allow them to tackle problems and to learn about new tools, libraries, and technologies. This study investigates to what extent and for which purpose developers refer to external online resources when they contribute changes to a repository by raising a pull request. Our study involved (i) a quantitative analysis of over 150k URLs occurring in pull requests posted in GitHub, (ii) a manual coding of the kinds of software evolution activities performed in commits related to a statistically significant sample of 2,130 pull requests referencing external documentation resources, (iii) a survey with 69 participants, who provided feedback on how they use online resources and how they refer to them when filing a pull request. Results of the study indicate that, on the one hand, developers find external resources useful to learn something new or to solve specific problems, and they perceive useful referring such resources to better document changes. On the other hand, both interviews and repository mining suggest that external resources are still rarely referred in document changes.

Meaningless identifiers as well as inconsistent use of identifiers in the source code might hinder code readability and result in increased software maintenance efforts. Over the past years, effort has been devoted to promoting a consistent usage of identifiers across different parts of a system through approaches exploiting static code analysis and Natural Language Processing (NLP). These techniques have been evaluated in small-scale studies, but it is unclear how they compare to each other and how they complement each other. Furthermore, a full-fledged larger empirical evaluation is still missing.,,We aim at bridging this gap. We asked developers of five projects to assess the meaningfulness of the recommendations generated by three techniques, two already existing in the literature (one exploiting static analysis, one using NLP) and a novel one we propose. With a total of 922 rename refactorings evaluated, this is, to the best of our knowledge, the largest empirical study conducted to assess and compare rename refactoring tools promoting a consistent use of identifiers. Our study sheds light on the current state-of-the-art in rename refactoring recommenders, and indicates directions for future work.

Software development, like any prolonged and intellectually demanding activity, can negatively affect the motivation of developers. This is especially true in specific areas of software engineering, such as requirements engineering, test-driven development, bug reporting and fixing, where the creative aspects of programming fall short. The developers' engagement might progressively degrade, potentially impacting their work's quality.

When knowledgeable colleagues are not available, developers resort to offline and online resources, e.g., tutorials, mailing lists, and Q&A websites. These, however, need to be found, read, and understood, which takes its toll in terms of time and mental energy. A more immediate and accessible resource are video tutorials found on the web, which in recent years have seen a steep increase in popularity. Nonetheless, videos are an intrinsically noisy data source, and finding the right piece of information might be even more cumbersome than using the previously mentioned resources.

Integrated Development Environments (IDEs) lack effective support to browse complex relationships between source code elements. As a result, developers are often forced to exploit multiple user interface components at the same time, bringing the IDE into a complex, “chaotic” state. Keeping track of these relationships demands increased source code navigation and cognitive load, leading to productivity deficits documented in observational studies. Beyond small-scale studies, the amount and nature of the chaos experienced by developers in the wild is unclear, and more importantly it is unclear how to tame it. Based on a dataset of fine-grained interaction data, we propose several metrics to characterize and quantify the “level of chaos” of an IDE. Our results suggest that developers spend, on average, more than 30% of their time in a chaotic environment, and that this may affect their productivity. To support developers, we devise and evaluate simple strategies that automatically alter the UI of the IDE. We find that even simple strategies may considerably reduce the level of chaos both in terms of effective space occupancy and time spent in a chaotic environment.

To ensure quality of software systems, developers use bug reports to track defects. It is in the interest of users and developers that bug reports provide the necessary information to ease the fixing process. Past research found that users do not provide the information that developers deem ideally useful to fix a bug. This raises an interesting question: What is the satisficing information to speed up the bug fixing process? We conducted an observational study on the relation between provided report information and its lifetime, considering more than 650,000 reports from open-source systems using popular bug trackers. We distilled a meta-model for a minimal bug report, establishing a basic layer of core features. We found that few fields influence the resolution time and that customized fields have little impact on it. We performed a survey to investigate what users deem easy to provide in a bug report.

As part of their daily work, developers interact with Integrated Development Environments (IDE), generating thousands of events. Together with other aspects of development, this data also captures the modus operandi of the developer, including all the program entities she interacted with during a development session. This "working set" (or context) is leveraged by developers to create and maintain their mental model of the software system at hand. Understanding how developers navigate and interact with source code during a development session is an open question. We present a novel visual approach to understand how working sets evolve during a development session. The visualization incrementally depicts all the program entities involved in a development session, the intensity of the developer activity on them, and the navigation paths that occurred between them. We visualized about a thousand development sessions, and categorized them according to their visual properties.

Developing software is a complex, intrinsically intellectual, and therefore ephemeral activity, also due to the intangible nature of the end product, the source code. There is a thin red line between a productive development session, where a developer actually does something useful and productive, and a session where the developer essentially produces "fried air", pieces of code whose quality and usefulness are doubtful at best. We believe that well-thought mechanisms of gamification built on fine-grained interaction information mined from the IDE can crystallize and reward good coding behavior. We present our preliminary experience with the design and implementation of a micro-gamification layer built into an object-oriented IDE, which at the end of each development session not only helps the developer to understand what he actually produced, but also praises him in case the development session was productive. Building on this, we envision an environment where the IDE reflects on the deeds of the developers and by providing a historical view also helps to track and reward long-term growth in terms of development skills, not dissimilar from the mechanics of role-playing games.

We present ViDI (Visual Design Inspector), a novel code review tool which focuses on quality concerns and design inspection as its cornerstones. It leverages visualization techniques to represent the reviewed software and augments the visualization with the results of quality analysis tools. To effectively understand the contribution of a reviewer in terms of the impact of her changes on the overall system quality, ViDI supports the recording and further inspection of reviewing sessions. ViDI is an advanced prototype which we will soon release to the Pharo open-source community.

Software evolution is supported by a variety of tools that help developers understand the structure of a software system, analyze its history and support specific classes of analyses. However, the increasingly distributed nature of software development requires basic repository analyses to be always available to developers, even when they cannot access their workstation with full-fledged applications and command-line tools. We present URBANIT, a gesture-based tablet application for the iPad that supports the visualization of software repositories together with useful evolutionary analyses (e.g., version diff) and basic sharing features in a portable and mobile setting. URBANIT is paired with a web application that manages synchronization of multiple repositories.

Developing software is a complex mental activity, requiring extensive technical knowledge and abstraction capabilities. The tangible part of development is the use of tools to read, inspect, edit, and manipulate source code, usually through an IDE (integrated development environment). Common claims about software development include that program comprehension takes up half of the time of a developer, or that certain UI (user interface) paradigms of IDEs offer insufficient support to developers. Such claims are often based on anecdotal evidence, throwing up the question of whether they can be corroborated on more solid grounds. We present an in-depth analysis of how developers spend their time, based on a fine-grained IDE interaction dataset consisting of ca. 740 development sessions by 18 developers, amounting to 200 hours of development time and 5 million of IDE events. We propose an inference model of development activities to precisely measure the time spent in editing, navigating and searching for artifacts, interacting with the UI of the IDE, and performing corollary activities, such as inspection and debugging. We report several interesting findings which in part confirm and reinforce some common claims, but also disconfirm other beliefs about software development.

Modern Integrated Development Environments (IDEs) are often affected by the "window plague", an overly crowded workspace with many open windows and tabs. The main cause is the lack of navigation support in IDEs, also due to the many -- and not always obvious -- complex relationships that exist between program entities. Researchers have shown that it is possible to mitigate the window plague by exploiting the data obtained by monitoring how developers interact with the user interface of the IDE. However, despite initial results the approach was never fully integrated in an IDE. In our previous work, we implemented DFlow, an automatic interaction profiler that monitors all the fine-grained interactions of the developer with the IDE. Here we present a first prototype of the Plague Doctor, a tool that seamlessly detects the windows that are less likely to be used in the future and automatically closes them. We discuss our long term vision on how to fully exploit the interaction data recorded by DFlow to provide a more effective cure for the window plague.

Source code and models of a software system, like architectural views, tend to evolve separately and drift apart over time. Previous research has shown that it is possible to effectively relate them through a reflex ion model, defined as a "summarization of a software system from the viewpoint of a particular high-level model". While effective, the process of constructing and analyzing reflex ion models was supported by text-based tools with limited visual representation. With the original approach, it was relatively hard to understand which parts of the system were represented, and which parts of the system contributed to specific relations in the reflexion model. We present our vision on augmenting the construction and analysis of reflex ion models with visual support, effectively providing the basis for visual reflex ion models. We describe our approach, implemented as a web-based application, and two promising case studies involving two open-source projects.

Summarization is hailed as a promising approach to reduce the amount of information that must be taken in by the person who wants to understand development artifacts, such as pieces of code, bug reports, emails, etc. However, existing approaches treat artifacts as pure textual entities, disregarding the heterogeneous and partially structured nature of most artifacts, which contain intertwined pieces of distinct type, such as source code, diffs, stack traces, human language, etc. We present a novel approach to augment existing summarization techniques (such as LexRank) to deal with the heterogeneous and multidimensional nature of complex artifacts. Our preliminary results on heterogeneous artifacts suggest our approach outperforms the current text-based approaches.

Stack Overflow is the de facto Question and Answer (Q&A) website for developers, and it has been used in many approaches by software engineering researchers to mine useful data. However, the contents of a Stack Overflow discussion are inherently heterogeneous, mixing natural language, source code, stack traces and configuration files in XML or JSON format. We constructed a full island grammar capable of modeling the set of 700,000 Stack Overflow discussions talking about Java, building a heterogeneous abstract syntax tree (H-AST) of each post (question, answer or comment) in a discussion. The resulting dataset models every Stack Overflow discussion, providing a full H-AST for each type of structured fragment (i.e., JSON, XML, Java, Stack traces), and complementing this information with a set of basic meta-information like term frequency to enable natural language analyses. Our dataset allows the end-user to perform combined analyses of the Stack Overflow by visiting the H-AST of a discussion.

Java is a safe language. Its runtime environment provides strong safety guarantees that any Java application can rely on. Or so we think. We show that the runtime actually does not provide these guarantees---for a large fraction of today's Java code. Unbeknownst to many application developers, the Java runtime includes a "backdoor" that allows expert library and framework developers to circumvent Java's safety guarantees. This backdoor is there by design, and is well known to experts, as it enables them to write high-performance "systems-level" code in Java. For much the same reasons that safe languages are preferred over unsafe languages, these powerful---but unsafe---capabilities in Java should be restricted. They should be made safe by changing the language, the runtime system, or the libraries. At the very least, their use should be restricted. This paper is a step in that direction. We analyzed 74 GB of compiled Java code, spread over 86,479 Java archives, to determine how Java's unsafe capabilities are used in real-world libraries and applications. We found that 25% of Java bytecode archives depend on unsafe third-party Java code, and thus Java's safety guarantees cannot be trusted. We identify 14 different usage patterns of Java's unsafe capabilities, and we provide supporting evidence for why real-world code needs these capabilities. Our long-term goal is to provide a foundation for the design of new language features to regain safety in Java.

While constructing and evolving software systems, developers generate directly and indirectly a large amount of data of diverse nature, such as source code changes, bug tracking information, IDE interactions, stack traces, etc. Often these diverse data sources are processed and visualized in isolation, leading to a partial view of systems. We present a blended approach to visualize several data “ingredients” at once, to give as complete an answer as possible to the question “What happened to the system in the last few days?”. The goal is to enable a quick and comprehensive assessment of what happened to a software system in any given time frame.

Understanding a problem domain is a fundamental prerequisite for good software design. In object-oriented systems design, modeling is the fundamental first phase that focuses on identifying core concepts and their relations. How to properly support modeling is still an open problem, and existing approaches and tools can be very different in nature. On the one hand, lightweight ones, such as pen & paper/whiteboard or CRC cards, are informal and support well the creative aspects of modeling, but produce artifacts that are difficult to store, process and reuse as documentation. On the other hand, more constrained and semi-formal ones, like UML, produce storable and processable structured artifacts with defined semantics, but this comes at the expense of creativity. We believe there exists a middle ground to investigate that maximizes the good of both worlds, that is, by supporting software modeling closer to its essence, with minimal constraints on the developer's creativity and still producing reusable structured artifacts. We also claim that modeling can be best treated by using the emerging technology of touch-based tablets. We present a novel gesture-based modeling approach based on a minimal set of constructs, and CEL, an iPad application, for rapidly creating, manipulating, and storing language agnostic object-oriented software models, which can be exported as skeleton source code in any language of choice. We assess our approach through a controlled qualitative study.

During software development, exceptions are by no means exceptional: Programmers repeatedly try and test their code to ensure that it works as expected. While doing so, runtime exceptions are raised, pointing out various issues, such as inappropriate usage of an API, convoluted code, as well as defects. Such failures result in stack traces, lists composed of the sequence of method invocations that led to the interruption of the program. Stack traces are useful to debug source code, and if shared also enhance the quality of bug reports. However, they are handled manually and individually, while we argue that they can be leveraged automatically and collectively to enable what we call crowdstacking, the automated collection of stack traces on the scale of a whole development community. We present our crowdstacking approach, supported by Shore-Line Reporter, a tool which seamlessly collects stack traces during program development and execution and stores them on a central repository. We illustrate how thousands of stack traces stemming from the IDEs of several developers can be leveraged to identify common hot spots in the code that are involved in failures, using this knowledge to retrieve relevant and related bug reports and to provide an effective, instant context of the problem to the developer.

Modern software development sees code review as a crucial part of the process, because not only does it facilitate the sharing of knowledge about the system at hand, but it may also lead to the early detection of defects, ultimately improving the quality of the produced software. Although supported by numerous approaches and tools, code review is still in its infancy, and indeed researchers have pointed out a number of shortcomings in the state of the art. We present a critical analysis of the state of the art of code review tools and techniques, extracting a set of desired features that code review tools should possess. We then present our vision and initial implementation of a novel code review approach named Visual Design Inspection (ViDI), illustrated through a set of usage scenarios. ViDI is based on a combination of visualization techniques, design heuristics, and static code analysis techniques.

Most development activities, like program understanding, source code navigation and editing, are supported by Integrated Development Environments (IDEs). They provide different tools and user interfaces (UI) to interact with the source code, such as browsers, debuggers, and inspectors. It is uncertain how and when programmers use different UI elements of an IDE and to what extent they appropriately support development. Previously we developed DFLOW, a tool that seamlessly records and processes interaction data. Our long-term goal is to assess to what extent the UIs of IDEs support the workflow of developers and whether they can be improved. As a first step we present our approach to analyze development sessions in the form of visual storytelling. We illustrate our initial catalogue of visualizations through two development stories.

Developers often consult different sources of information like Application Programming Interfaces (API) documentation, forums, Q&A websites, etc. With the aim of gathering additional knowledge for the programming task at hand. The process of searching and identifying valuable pieces of information requires developers to spend time and energy in formulating the right queries, assessing the returned results, and integrating the obtained knowledge into the code base. All of this is often done manually. We present Prompter, a plug-in for the Eclipse IDE which automatically searches and identifies relevant Stack Overflow discussions, evaluates their relevance given the code context in the IDE, and notifies the developer if and only if a user-defined confidence threshold is surpassed.

Stack Overflow is a popular questions and answers (Q&A) website among software developers. It counts more than two millions of users who actively contribute by asking and answering thousands of questions daily. Identifying and reviewing low quality posts preserves the quality of site's contents and it is crucial to maintain a good user experience. In Stack Overflow the identification of poor quality posts is performed by selected users manually. The system also uses an automated identification system based on textual features. Low quality posts automatically enter a review queue maintained by experienced users. We present an approach to improve the automated system in use at Stack Overflow. It analyzes both the content of a post (e.g., simple textual features and complex readability metrics) and community-related aspects (e.g., popularity of a user in the community). Our approach reduces the size of the review queue effectively and removes misclassified good quality posts.

Developers often require knowledge beyond the one they possess, which often boils down to consulting sources of information like Application Programming Interfaces (API) documentation, forums, Q&A websites, etc. Knowing what to search for and how is non- trivial, and developers spend time and energy to formulate their problems as queries and to peruse and process the results. We propose a novel approach that, given a context in the IDE, automatically retrieves pertinent discussions from Stack Overflow, evaluates their relevance, and, if a given confidence threshold is surpassed, notifies the developer about the available help. We have implemented our approach in Prompter, an Eclipse plug-in. Prompter has been evaluated through two studies. The first was aimed at evaluating the devised ranking model, while the second was conducted to evaluate the usefulness of Prompter.

One of the fundamental principles of open-source projects is that they foster collaboration among developers, disregarding their geographical location or personal background. When it comes to software repositories collaboration is a rather ephemeral phenomenon which lacks a clear definition, and it must therefore be mined and modeled. This throws up the question whether what is mined actually maps to reality.

Integrated Development Environments (IDEs) have become the de facto standard vehicle to develop software systems. The user interface (UI) of an IDE offers a staggering amount of facilities to manipulate source code, such as inspectors, debuggers, recommenders, alternative viewers, etc. It is unclear how developers use the UI of an IDE and whether such UIs actually give appropriate support to the developers. We present a visual approach to understand and characterize development sessions from the UI perspective. The tool supporting our approach mines and processes the finest-grained UI-level events making up development sessions and presents them visually. We have collected, visualized, and analyzed hundreds of development sessions and report on our findings.

The design of object-oriented systems starts with modeling, a process to identify core concepts and their relations. Mainstream modeling techniques can be either informal (white board, CRC cards, etc.) or formal (e.g., UML editors). The former support well the creative modeling process, but their output is difficult to store, process and maintain. The latter reduce these problems, at the expense of creativity and productivity because they are tedious and not trivial to use. We present Cel, a touch- and gesture-based iPad application to rapidly create, manipulate, and store language agnostic object-oriented software models, based on a minimal set of constructs. Demo video URL: http://youtu.be/icQVS6w0jTE.

Services, such as Stack Overflow, offer a web platform to programmers for discussing technical issues, in form of Question and Answers (Q&A). Since Q&A services store the discussions, the generated “crowd knowledge” can be accessed and consumed by a large audience for a long time. Nevertheless, Q&A services are detached from the development environments used by programmers: Developers have to tap into this crowd knowledge through web browsers and cannot smoothly integrate it into their workflow. This situation hinders part of the benefits of Q&A services. To better leverage the crowd knowledge of Q&A services, we created Seahawk, an Eclipse plugin that supports an integrated and largely automated approach to assist programmers using Stack Overflow. Seahawk formulates queries automatically from the active context in the IDE, presents a ranked and interactive list of results, lets users import code samples in discussions through drag & drop and link Stack Overflow discussions and source code persistently as a support for team work. Video Demo URL: http://youtu.be/DkqhiU9FYPI.

Mobile applications, also known as apps, are dedicated software systems that run on handheld devices, such as smartphones and tablet computers. The apps business has in a few years turned into a multi-billion dollar market. From a software engineering perspective apps represent a new phenomenon, and there is a need for tools and techniques to analyze apps. We present SAMOA, a visual web-based software analytics platform for mobile applications. It mines software repositories of apps and uses a set of visualization techniques to present the mined data. We describe SAMOA, detail the analyses it supports, and describe a methodology to understand apps from a structural and historical perspective. The website of SAMOA, containing the screen cast of the tool demo, is located at http://samoa.inf.usi.ch/about.

Collaboration is essential for the development of complex software systems. An important aspect of collaboration is team awareness: The understanding of the activity of others that provides a context for one's activity. We claim that the current IDE support for awareness is inadequate: The typical setting is to rely on software configuration management systems (SCMs), which are based on an explicit check-out/check-in model. If developers rely only on SCMs information, they become aware of concurrent changes only when they commit their code to the repository. This generates problems such as complex merging and redundant work. Most tools to raise awareness notify developers of emerging conflicts in the form of textual notifications. We propose to improve the notification by using real-time visualization integrated in the IDE to notify developers of team activity. Our approach, implemented in a tool called Manhattan, eases team activity comprehension by relying on a city metaphor. Manhattan depicts a software system as a live city that changes as the underlying system evolves. Within the city, Manhattan renders team activity information, updating developers in real-time about changes implemented by the entire development team. Further, Manhattan provides programmers with immediate feedback about emerging conflicts in which they are involved.

Open source software (OSS) development teams use electronic means, such as emails, instant messaging, or forums, to conduct open and public discussions. Researchers investigated mailing lists considering them as a hub for project communication. Prior work focused on specific aspects of emails, for example the handling of patches, traceability concerns, or social networks. This led to insights pertaining to the investigated aspects, but not to a comprehensive view of what developers communicate about. Our objective is to increase the understanding of development mailing lists communication. We quantitatively and qualitatively analyzed a sample of 506 email threads from the development mailing list of a major OSS project, Lucene. Our investigation reveals that implementation details are discussed only in about 35% of the threads, and that a range of other topics is discussed. Moreover, core developers participate in less than 75% of the threads. We observed that the development mailing list is not the main player in OSS project communication, as it also includes other channels such as the issue repository.

Developers use the Integrated Development Environment (IDE) to develop a system at hand, by reading, understanding, and writing its source code. They do so by exploiting the tools and facilities provided by the IDE. This also allows them to build a mental model of the system to perform informed changes. It is however not clear how and when developers use which facility and tool, and to what extent the current services offered by the IDE appropriately support the navigation. We present an approach to visualize the activities of developers within the IDE, implemented in a tool: DFLow. DFLOW records all IDE interactions that occur during a development session and visualizes them through a web-based visualization platform.

The evolution of non-trivial software systems is accompanied by unexpected behaviour and side-effects, referred as bugs or defects. These defects are reported to and stored in bug tracking systems, which contain descriptions of the problems that have been encountered. However, bug tracking systems store and present bug reports in textual form, which makes their understanding dispersive and unintuitive. We present an approach to display bug reports through a web-based visual analytics platform, named in∗Bug. in∗Bug allows users to navigate and inspect the vast information space created by bug tracking systems, with the goal of easing the comprehension of bug reports in detail and also obtain an understanding “in the large” of how bugs are reported with respect to one system or to an entire software ecosystem.

Preemptive conflict detection is the act of detecting a potential merge conflict at an earlier stage than at check in time, and informing the involved developers about it. Researchers have proposed a number of tools and techniques to detect potential merge conflicts. However, barely any study has been conducted to investigate whether the adoption of such tools and techniques brings benefits to developers. We have conducted a qualitative user study to understand how developers behave when dealing with merging and how this behavior changes when they are exposed to preemptive conflict detection. We report on the analysis of the data collected in the user study, and provide an in-depth discussion on the findings derived from it.

Emails related to the development of a software system contain information about design choices and issues encountered during the development process. Exploiting the knowledge embedded in emails with automatic tools is challenging, due to the unstructured, noisy, and mixed language nature of this communication medium. Natural language text is often not well-formed and is interleaved with languages with other syntaxes, such as code or stack traces. We present an approach to classify email content at line level. Our technique classifies email lines in five categories (i.e., text, junk, code, patch, and stack trace) to allow one to subsequently apply ad hoc analysis techniques for each category. We evaluated our approach on a statistically significant set of emails gathered from mailing lists of four unrelated open source systems.

Summary form only given. My group at Microsoft Research creates software development tools through user-centered design. This method creates a virtuous cycle: we study developers and their teams, which in turn inspires the tools we design, which we then evaluate with those developers and teams, seeking to improve the nature of their work. In this talk, we'll discuss some of the biggest problem areas we have observed, including information seeking, multitasking and disorientation, and look at some of the prototypes we have built in response. Code Canvas provides a zoomable map of a software project, allowing the programmer to zoom out to see structure and visualizations and zoom in to edit code. Debugger Canvas (a joint project with Brown University) provides a spatial representation of a programmer's task, like a debugging session, as it unfolds. Finally, Code Space uses a combination of touch screens, Kinects and mobile devices to allow fluid sharing of digital objects at development team meetings.

Source code is the target and final outcome of software development. By focusing our research and analysis on source code only, we risk forgetting that software is the product of human efforts, where communication plays a pivotal role. One of the most used communications means are emails, which have become vital for any distributed development project. Analyzing email archives is non-trivial, due to the noisy and unstructured nature of emails, the vast amounts of information, the unstandardized storage systems, and the gap with development tools.

Software visualization is a popular program comprehension technique used in the context of software maintenance, reverse engineering, and software evolution analysis. While there is a broad range of software visualization approaches, only few have been empirically evaluated. This is detrimental to the acceptance of software visualization in both the academic and the industrial world.

The program comprehension research community has been developing useful tools and techniques to support developers in the time-consuming activity of understanding software artifacts. However, the majority of the tools do not bring collective benefit to the team: After gaining the necessary understanding of an artifact (e.g., using a technique based on visualization, feature localization, architecture reconstruction, etc.), developers seldom document what they have learned, thus not sharing their knowledge. We argue that code bookmarking can be effectively used to document a developer's findings, to retrieve this valuable knowledge later on, and to share the findings with other team members. We present a tool, called Pollicino, for collective code bookmarking. To gather requirements for our bookmarking tool, we conducted an online survey and interviewed professional software engineers about their current usage and needs of code bookmarks. We describe our approach and the tool we implemented. To assess the tool's effectiveness, adequacy, and usability, we present an exploratory pre-experimental user study we have performed with 11 participants.

Developers often need to find answers to questions regarding the evolution of a system when working on its code base. While their information needs require data analysis spanning over different repository types, the source code repository has a pivotal role for program comprehension tasks. However, the coarse-grained nature of the data stored by commit-based software configuration management systems often makes it challenging for a developer to search for an answer. We present Replay, an Eclipse plug-in that allows one to explore the change history of a system by capturing the changes at a finer granularity level than commits, and by replaying the past changes chronologically inside the integrated development environment with the source code at hand. We conducted a controlled experiment to empirically assess whether Replay outperforms a baseline (SVN client in Eclipse) on helping developers to answer common questions related to software evolution. The experiment shows that Replay leads to a decrease in completion time with respect to a set of software evolution comprehension tasks.

The design and evolution of a software system leave traces in various kinds of artifacts. In software, produced by humans for humans, many artifacts are written in natural language by people involved in the project. Such entities contain structured information which constitute a valuable source of knowledge for analyzing and comprehending a system's design and evolution. However, the ambiguous and informal nature of narrative is a serious challenge in gathering such information, which is scattered throughout natural language text. We present an approach-based on island parsing-to recognize and enable the parsing of structured information that occur in natural language artifacts. We evaluate our approach by applying it to mailing lists pertaining to three software systems. We show that this approach allows us to extract structured data from emails with high precision and recall.

Integrated development environments (IDEs) include many tools that provide the means to construct programs. Coincidentally, the very same IDEs are a primary vehicle for program comprehension. We claim that IDEs may be an impediment for program comprehension because they treat software elements as text, which may be counterproductive in the context of program understanding-where abstracting from the source text to the level of structural entities and relationships is the key. We are currently building Gaucho, a visual object-focused environment that allows developers to write programs by creating and manipulating lightweight and intuitive depictions of object-oriented constructs. The research question we investigate here is how such an environment compares with traditional IDEs when it comes to performing program comprehension tasks. To answer our question, we conducted a preliminary controlled experiment with eight subjects, comparing Gaucho against a traditional IDE. We found that Gaucho outperforms the IDE regarding the correctness of the tasks, while it is slower with respect to the completion time. Our preliminary results suggest that alternative-visual-IDEs may be superior to traditional IDEs as program comprehension aids.

E-mails concerning the development issues of a system constitute an important source of information about high-level design decisions, low-level implementation concerns, and the social structure of developers.

Team collaboration is essential for the success of multi-developer projects. When team members are spread across different locations, individual awareness of the activity of others drops due to communication barriers.

Software evolution researchers have focused mostly on analyzing single software systems. However, often projects are developed and co-exist within software ecosystems, i.e., the larger contexts of companies, research groups or open-source communities. We present The Small Project Observatory, a web-based analysis platform for ecosystem reverse engineering through interactive visualization and exploration.

Welcome to the 26th IEEE International Conference on Software Maintenance in Timişoara, Romania. ICSM is adding a new country on its list of locations highlighting its international dimension. We hope you will all enjoy the location as much as the conference.

E-mails, used by developers and system users to communicate over a broad range of topics, offer a valuable source of information. If archived, e-mails can be mined to support program comprehension activities and to provide views of a software system that are alternative and complementary to those offered by the source code. However, e-mails are written in natural language, and therefore contain noise that makes it difficult to retrieve the important data. Thus, before conducting an effective system analysis and extracting data for program comprehension, it is necessary to select the relevant messages, and to expose only the meaningful information. In this work we focus both on classifying e-mails that hold fragments of the source code of a system, and on extracting the source code pieces inside the e-mail. We devised and analyzed a number of lightweight techniques to accomplish these tasks. To assess the validity of our techniques, we manually inspected and annotated a statistically significant number of e-mails from five unrelated open source software systems written in Java. With such a benchmark in place, we measured the effectiveness of each technique in terms of precision and recall.

In large software systems, knowing the dependencies between modules or components is critical to assess the impact of changes. To recover the dependencies, fact extractors analyze the system as a whole and build the dependency graph, parsing the system down to the statement level. At the level of software ecosystems, which are collections of software projects, the dependencies that need to be recovered reside not only within the individual systems, but also between the libraries, frameworks, and entire software systems that make up the complete ecosystem; scaling issues arise. In this paper we present and evaluate several variants of a lightweight and scalable approach to recover dependencies between the software projects of an ecosystem. We evaluate our recovery algorithms on the Squeak 3.10 Universe, an ecosystem containing more than 200 software projects. Categories and Subject Descriptors D.2.8 [Software Engineering]: Metrics—complexity measures, performance measures

Reliably predicting software defects is one of software engineering's holy grails. Researchers have devised and implemented a plethora of bug prediction approaches varying in terms of accuracy, complexity and the input data they require. However, the absence of an established benchmark makes it hard, if not impossible, to compare approaches. We present a benchmark for defect prediction, in the form of a publicly available data set consisting of several software systems, and provide an extensive comparison of the explanative and predictive power of well-known bug prediction approaches, together with novel approaches we devised. Based on the results, we discuss the performance and stability of the approaches with respect to our benchmark and deduce a number of insights on bug prediction models.

Change prediction helps developers by recommending program entities that will have to be changed alongside the entities currently being changed. To evaluate their accuracy, current change prediction approaches use data from versioning systems such as CVS or SVN. These data sources provide a coarse-grained view of the development history that flattens the sequence of changes in a single commit. They are thus not a valid basis for evaluation in the case of development-style prediction, where the order of the predictions has to match the order of the changes a developer makes. We propose a benchmark for the evaluation of change prediction approaches based on fine-grained change data recorded from IDE usage. Moreover, the change prediction approaches themselves can use the more accurate data to fine-tune their prediction. We present an evaluation procedure and use it on several change prediction approaches, both novel and from the literature, and report on the results.

When software repositories are mined, two distinct sources of information are usually explored: the history log and snapshots of the system. Results of analyses derived from these two sources are biased by the frequency with which developers commit their changes. We argue that the usage of mainstream SCM systems influences the way that developers work. For example, since it is tedious to resolve conflicts due to parallel commits, developers tend to minimize conflicts by not contemporarily modifying the same file. This however defeats one of the purposes of such systems. We mine repositories created by our Syde tool, which records every change by every developer in multi-developer projects. This new source of information can augment the accuracy of analyses and breaks new ground in terms of how such information can assist developers. In this paper we illustrate how the information we mine can help to provide a refined notion of code ownership. As a case study, we analyze the developers' activities of the development of a commercial system.

We analyzed the gnome family of systems with the small project observatory, our online ecosystem visualization platform. We begin by briefly introducing the model of SPO. We then observe and discuss several phases in the activity of the gnome ecosystem. We follow and look at how the contributors are distributed between writing source code and doing other activities such as internationalization. We end with a visual overview of the activity of more than 900 contributors in the 10 years of existence of gnome.

Abstract The analysis of the evolution of large software systems is challenging for many reasons, such as the retrieval and processing of historical information and the large quantity of data that must be dealt with. While recent advances in research have led to the solutions to these problems, a central question remains: How do we deal with this information in a methodical way and where do we start with our analysis? We present a methodology based on interactive visualizations that support the reconstruction of the evolution of software systems. We propose several visualizations which help us to perform software evolution analysis of a system ‘in the large’ and ‘in the small’, and apply them to two large systems. Copyright © 2009 John Wiley & Sons, Ltd.

Software evolution analysis provides a valuable source of information that can be used both to understand a system's design and predict its future development. While for many program comprehension purposes, it is sufficient to model a single version of a system, there are types of information that can only be recovered when the history of a system is taken into account. Logical coupling, the implicit dependency between software artifacts that have been changed together, is an example of such information. Previous research has dealt with low-level couplings between files, leading to an explosion of the data to be analyzed, or has abstracted the logical couplings to the level of modules, leading to a loss of detailed information. In this paper, we present a visualization-based approach that integrates logical coupling information at different levels of abstraction. This facilitates an in-depth analysis of the logical couplings, and at the same time, leads to a characterization of a system's modules in terms of their logical coupling. The presented approach supports the retrospective analysis of a software system and maintenance activities such as restructuring and redocumentation. We illustrate retrospective analysis on two large open-source software systems.

In October 2004 the University of Lugano in southern Switzerland established a new faculty of informatics. Its founding principles are innovation in teaching and faculty participation in the research community. With respect to teaching, students spend mornings attending lectures and afternoons in an Atelier designed to support interaction both among students and with the instructors. In teaching the first year "Programming Fundamentals" courses, we took advantage of the clean slate nature of the faculty to introduce innovative teaching elements. The novel aspects include our use of Scheme, Smalltalk, and Java, our combination of individual, pair and group projects and the integration of expert lectures to introduce useful, but slightly orthogonal elements at key points in the semester. Our very positive experience is reported along with a discussion of aspects to improve in the future.

Our research is driven by the motivation that change must be put in the center, if one wants to understand the complex processes of software evolution. We built a toolset named SpyWare which, using a monitoring plug-in for integrated development environments (IDEs), tracks the changes that a developer performs on a program as they happen. SpyWare stores these first-class changes in a change repository and offers a plethora of productivity-enhancing IDE extensions to exploit the recorded information.

Code completion is a widely used productivity tool. It takes away the burden of remembering and typing the exact names of methods or classes: As a developer starts typing a name, it provides a progressively refined list of candidates matching the name. However, the candidate list always comes in alphabetic order, i.e., the environment is only second-guessing the name based on pattern matching. Finding the correct candidate can be cumbersome or slower than typing the full name. We present an approach to improve code completion with program history. We define a benchmark measuring the accuracy and usefulness of a code completion engine. Further, we use the change history data to also improve the results offered by code completion tools. Finally, we propose an alternative interface for completion tools.

The understanding of development sessions, the phases during which a developer actively modifies a software system, is a valuable asset for program comprehension, since the sessions directly impact the current state and future evolution of a software system. Such information is usually lost by state-of-the-art versioning systems, because of the checkin/checkout model they rely on: a developer must explicitly commit his changes to the repository. Since this happens in arbitrary and sometimes long intervals, recovering the changes between two commits is difficult and inaccurate, and recovering the order of the changes is impossible. We have implemented an evolution monitoring prototype which records every semantic change performed on a system, and is able to completely reconstruct development sessions. In this paper we use this fine-grained information to understand and characterize the development sessions as they were carried out on two object-oriented systems.

The comprehensive understanding of a large software system is a daunting task because of the sheer size and complexity that such systems exhibit. In this context software visualization is a widely used approach, since well-conceived visual representations allow one to spot patterns. The large majority of visualizations use 2D representations, because they are easier to construct, navigate, and interact with. 3D representations usually exploit the 3rd dimension as an additional means to encode quantitative values, which is dismissed by many as a too small benefit in the light of the added complexity in terms of navigation and interaction. We argue that a well-constructed, interactive, and easily navigable 3D visualization can greatly help in program comprehension tasks by supporting habitability. Habitability transmits to a developer the notion that a software system is a physical space with strong orientation points. This can give developers the feeling of being "at home" in a system. We propose a 3D visualization of software systems hinging on the city metaphor. It is useful for program comprehension because it leads to clarity about the overall structure of a system. We apply our visualization technique on two large systems and discuss its benefits and drawbacks.

Software evolution constitutes a crucial phase of the software life-cycle, requiring up to 80% of the total effort. IWPSE, the International Workshop on Principles of Software Evolution brings together researchers and practitioners in a worldwide forum with the aim of iscussing principles, techniques, and tools related to software evolution.

Gaining higher level evolutionary information about large software systems is a key challenge in dealing with increasing complexity and decreasing software quality. Software repositories such as modifications, changes, or release information are rich sources for distinctive kinds of analyses: They reflect the reasons and effects of particular changes made to the software system over a certain period of time. If we can analyze these repositories in an effective way, we get a clearer picture of the status of the software. Software repositories can be analyzed to provide information about the problems concerning a particular feature or a set of features. Hidden dependencies of structurally unrelated but over time logically coupled files exhibit a high potential to illustrate software evolution and possible architectural deterioration. In this tutorial, we describe the investigation of software evolution by taking a step towards reflecting the analysis results against software quality attributes. Different kinds of analyses (from architecture to code) and their interpretation will be presented and discussed in relation to quality attributes. This will show our vision of where such evolution investigations can lead and how they can support development. For that, the tutorial will touch issues such as meta-models for evolution data, data analysis and history mining, software quality attributes, as well as visualization of analysis results.

CodeCrawler (in the remainder of the text CC) is a language independent, interactive, information visualization tool. It is mainly targeted at visualizing object-oriented software, and has been successfully validated in several industrial case studies over the past few years. CC adheres to lightweight principles: it implements and visualizes polymetric views, visualizations of software enriched with information such as software metrics and other source code semantics. CC is built on top of Moose, an extensible language independent reengineering environment that implements the FAMIX metamodel. In its last implementation, CC has become a general-purpose information visualization tool.

Understanding source code is an important task in the maintenance of software systems. Legacy systems are not only limited to procedural languages, but are also written in object-oriented languages. In such a context, understanding classes is a key activity as they are the cornerstone of the object-oriented paradigm and the primary abstraction from which applications are built. Such an understanding is however difficult to obtain because of reasons such as the presence of late binding and inheritance. A first level of class understanding consists of the understanding of its overall structure, the control flow among its methods, and the accesses on its attributes. We propose a novel visualization of classes called class blueprint that is based on a semantically enriched visualization of the internal structure of classes. This visualization allows a software engineer to build a first mental model of a class that he validates via opportunistic code-reading. Furthermore, we have identified visual patterns that represent recurrent situations and as such convey additional, information to the viewer. The contributions of this article are the class blueprint, a novel visualization of the internal structure of classes, the identification of visual patterns, and the definition of a vocabulary based on these visual patterns. We have performed several case studies of which one is presented in depth, and validated the usefulness of the approach in a controlled experiment.

Current unit test frameworks present broken unit tests in an arbitrary order, but developers want to focus on the most specific ones first. We have therefore inferred a partial order of unit tests corresponding to a coverage hierarchy of their sets of covered method signatures: When several unit tests in this coverage hierarchy break, we can guide the developer to the test calling the smallest number of methods. Our experiments with four case studies indicate that this partial order is semantically meaningful, since faults that cause a unit test to break generally cause less specific unit tests to break as well.

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.

Reverse engineering software systems has become a major concern in software industry because of their sheer size and complexity. This problem needs to be tackled since the systems in question are of considerable worth to their owners and maintainers. In this article, we present the concept of a polymetric view, a lightweight software visualization technique enriched with software metrics information. Polymetric views help to understand the structure and detect problems of a software system in the initial phases of a reverse engineering process. We discuss the benefits and limits of several predefined polymetric views we have implemented in our tool CodeCrawler. Moreover, based on clusters of different polymetric views, we have developed a methodology which supports and guides a software engineer in the first phases of a reverse engineering of a large software system. We have refined this methodology by repeatedly applying it on industrial systems and illustrate it by applying a selection of polymetric views to a case study.

The reengineering and reverse engineering of software systems is gaining importance in software industry, because the accelerated turnover in software industry, because the accelerated turnover in software companies creates legacy systems in a shorter period of time. Especially understanding classes is a key activity in object-oriented programming, since classes represent the primary abstractions from which applications are built. The main problem of this task is to quickly grasp the purpose of a class and its inner structure. To help the reverse engineers in their first contact with a foreign system, we propose a categorization of classes based on the visualization of their internal structure. The contributions of this paper are a novel categorization of classes and a visualization of the which we call the class blueprint. We have validated the categorization on several case studies, two of which we present here.