Recent research has shown the great potential of automatic feedback in education. This paper presents SOBO, a bot we designed to automatically provide feedback on code quality to undergraduate students. SOBO has been deployed in a course at the KTH Royal Institute of Technology in Sweden with 130+ students. Overall, SOBO has analyzed 1687 GitHub repositories and produced 8443 tailored code quality feedback messages to students. Unlike traditional tools embedded in CI pipelines, SOBO is designed to interact with students in a way that promotes personalized learning without imposing additional teaching burdens. The quantitative and qualitative results indicate that SOBO effectively nudges students into adopting code quality best practices, without interfering with pedagogical objectives. From this experience, we provide guidelines on how to design and deploy teaching bots in programming courses.

Automated unit test generation consists of two complementary challenges: Finding sequences of API calls that exercise the code of a class under test, and finding assertion statements that validate the behavior of the class during execution. The former challenge is often addressed using meta-heuristic search algorithms optimising tests for code coverage, which are then annotated with regression assertions to address the latter challenge, i.e., assertions that capture the states observed during test generation. While the resulting tests tend to achieve high coverage, their fault finding potential is often inhibited by poor or difficult observability of the codebase. That is, relevant attributes and properties may either not be exposed adequately at all, or only in ways that the test generator is unable to handle. In this paper, we investigate the influence of observability in the context of the EvoSuite search-based Java test generator, which we extend in two complementary ways to study and improve observability: First, we apply a transformation to code under test to expose encapsulated attributes to the test generator; second, we address EvoSuite's limited capability of asserting the state of complex objects. Our evaluation demonstrates that together these observability improvements lead to significantly increased mutation scores, underscoring the importance of considering the class observability in the test generation process.

GitHub Actions (GA) is an orchestration platform that streamlines the automatic execution of software engineering tasks such as building, testing, and deployment. Although GA workflows are the primary means for automation, according to our experience and observations, human intervention is necessary to correct defects, update dependencies, or refactor existing workflow files. In fact, previous research has shown that software artifacts similar to workflows, such as build files and bots, can introduce additional maintenance tasks in software projects. This suggests that workflow files, which are also used to automate repetitive tasks in professional software production, may generate extra workload for developers. However, the nature of such effort has not been well studied. This paper presents a large-scale empirical investigation towards characterizing the maintenance of GA workflows by studying the evolution of workflow files in almost 200 mature GitHub projects across ten programming languages. Our findings largely confirm the results of previous studies on the maintenance of similar artifacts, while also revealing GA-specific insights such as bug fixing and CI/CD improvement being among the major drivers of GA maintenance. A direct implication is that practitioners should be aware of proper resource planning and allocation for maintaining GA workflows, thus exposing the “hidden costs of automation.” Our findings also call for identifying and documenting best practices for such maintenance, and for enhanced tool features supporting dependency tracking and better error reporting of workflow specifications.

Empirically analyzing debugging activity is notoriously difficult. In particular, aggregating data (obtained from either observation or event logging) to verify hypotheses on developers' behavior is known to be challenging. Overall, the difficulty of studying debugging activities contributes to the need for more empirical evidence on how practitioners use debuggers. We propose debugging activity blueprint as a visual tool to analyze and navigate through all the events recorded in a programming environment. Our blueprint is a polymetric view representing the interaction between debuggers and other programming tools. Our blueprint highlights the flow of a debugging activity across the tools an IDE offers. An exploratory use case over three participants and two debugging tasks indicates that our blueprint supports a fine-grained analysis of complex debugging scenarios.

The software engineering community has produced numerous tools, techniques, and methodologies for practitioners to analyze and optimize memory usage during software execution. However, little is known about the actual needs of programmers when analyzing memory behavior and how they use tools to address those needs. We conducted an exploratory study (i) to understand what a programmer needs to know when analyzing memory behavior and (ii) how a programmer finds that information with current tools. From our observations, we provide a catalog of 34 questions programmers ask themselves when analyzing memory behavior. We also report a detailed analysis of how some tools are used to answer these questions and the difficulties participants face during the process. Finally, we present four recommendations to guide researchers and developers in designing, evaluating, and improving memory behavior analysis tools.

GitHub Actions (GA) enjoy increasing popularity in many software development projects as a means to automate repetitive software engineering tasks by enabling programmable event-driven workflows. Researchers typically analyze GA at the raw data level using batch tools to mine and analyze actions, jobs, and steps within GA workflows. Although this approach is widely applicable, it ignores the specific context of the GA workflow domain. Consequently, researchers do not reason directly about the domain abstractions.We present our preliminary steps in building EGAD (Explorable GitHub Action Domain Model), a moldable domain-specific tool to depict and analyze detailed GA workflow data. EGAD consists of an explorable domain model of GA workflows augmented with custom, domain-specific views, and live narratives. We illustrate EGAD in action using it to explore "sticky commits" in GitHub repositories.

A microprint is a visualization that condenses the contents of a text file into a small space. This is done by using colored scaled -down characters or pixels to represent each character of the text. The colors aim to highlight information relevant to the user. We have created μPrintGen, a framework for creating custom microprints by associating colors to rules that specify what is included or excluded from the line, with plain text or regular expressions. At the same time, the user can customize the look and structure of the created microprint for ease of use. We also created$\mu$PrintVis, a website for viewing the created microprints that supports various navigation features, like zoom and search. Feedback from the Rust and Julia open-source communities shows that μPrintGen lets users navigate through large log files, while easily highlighting reported errors. Two experts agree on the benefits of$\mu$PrintGen, compared to pure textual-based searching features commonly offered by text editors. Video URL: https://youtu.beIlJIZHLQdXiO

Detecting and repairing memory issues is still a challenging task. One reason is that understanding a program's memory usage involves a diverse and related set of dynamic and static aspects. Over the years, multiple tools have been proposed to assist practitioners in these activities. However, detailed information about how a tool helps users when analyzing memory usage is missing.This article introduces Vismep, an interactive visualization prototype to help programmers analyze Python applications' memory usage, and presents an exploratory study to understand the behavior and perception of users when using Vismep. As a result, we reported five information needs when participants analyze memory consumption and how they use Vismep to satisfy these needs. Besides, participants positively perceived Vismep due to their valuable views and high overall usability.

Information about source code changes is important for many software development activities. As such, modern IDEs, including, IntelliJ IDEA and Visual Studio Code, show visual clues within the code editor that highlight lines that have been changed since the last synchronization with the code repository. However, the granularity of the change information is limited to a line level, showing mainly a small colored icon on the left side of the lines that have been added, deleted, or modified.This paper introduces Spike, a source code highlighting plugin that uses the font color to visually encode fine-grained version difference information within the code editor. In contrast to previously mentioned tools, Spike can highlight insertions, deletions, updates, and refactorings all in a same line. Our plugin also enriches the source code with small icons that allow retrieving detailed information about a given code change. We perform an exploratory user study with five professional software engineers. Our results show that our approach is able to assist practitioners with complex comprehension tasks about software history within the code editor.

GitHub Actions are an event-driven tool to automatically respond to particular GitHub events. Typical events are receiving new pull requests or publishing a software release. Despite the massive and quick adoption of GitHub Actions, little is known about the incremental construction of GitHub Actions workflow by practitioners. This paper presents the result of a manual inspection of 222 commits of GitHub Actions workflows obtained from 10 popular open-source repositories. Our hierarchical taxonomy, obtained by systematically categorizing and tagging workflow modifications, reveals 11 types of modifications and presents opportunities for improvement in the way workflows are built and edited. In particular, our results highlight the need for adequate tooling to support refactoring, debugging and code editing of GitHub Actions workflows.

Abstract Some test amplification tools extend a manually created test suite with additional test cases to increase the code coverage. The technique is effective, in the sense that it suggests strong and understandable test cases, generally adopted by software engineers. Unfortunately, the current state-of-the-art for test amplification heavily relies on program analysis techniques which benefit a lot from explicit type declarations present in statically typed languages. In dynamically typed languages, such type declarations are not available and as a consequence test amplification has yet to find its way to programming languages like Smalltalk, Python, Ruby and Javascript. We propose to exploit profiling information —readily obtainable by executing the associated test suite— to infer the necessary type information creating special test inputs with corresponding assertions. We evaluated this approach on 52 selected test classes from 13 mature projects in the Pharo ecosystem containing approximately 400 test methods. We show the improvement in killing new mutants and mutation coverage at least in 28 out of 52 test classes (≈ 53%). Moreover, these generated tests are understandable by humans: 8 out of 11 pull-requests submitted were merged into the main code base (≈ 72%). These results are comparable to the state-of-the-art, hence we conclude that test amplification is feasible for dynamically typed languages.

The behavior of a robot is typically expressed as a set of source code files written using a programming language. As for any software engineering activity, programming robotic behaviors is a complex and error-prone task. This paper propose a methodology that aims to reduce the cost of producing a reliable software describing a robotic behavior by automatically testing it.We employ a fuzz testing technique to stress software components with randomly generated data. By applying fuzz testing to a complex robotic-software, we identified errors related to the coding, the way data is handled, the logic of the robotic behavior, and the initialization of architectural components. Furthermore, a panel of experts acquainted with the analyzed behavior have highlighted the relevance and the significance of our findings. Our fuzzer operates on the SMACH and ROS frameworks and it is available under the MIT public open source license.

Assessing code comment quality is known to be a difficult problem. A number of coding style guidelines have been created with the aim to encourage writing of informative, readable, and consistent comments. However, it is not clear from the research to date which specific aspects of comments the guidelines cover (e.g., syntax, content, structure). Furthermore, the extent to which developers follow these guidelines while writing code comments is unknown.We analyze various style guidelines in Java and Python and uncover that the majority of them address more the content aspect of the comments rather than syntax or formatting. However, when considering the different types of information developers embed in comments and the concerns they raise on various online platforms about the commenting practices, existing comment conventions are not yet specified clearly enough, nor do they adequately cover important concerns. We find that developers of both languages follow the writing style and content-related comment conventions more often than syntax and structure types of conventions. Our results highlight the mismatch between developer commenting practices and style guidelines, and provide several focal points for the design and improvement of comment quality checking tools.

Large code refactoring projects can consist of hundreds of refactoring rules that are applied iteratively to make code easier to maintain. Visualising the refactoring process can help engineers and stakeholders understand how chains of refactorings were applied and to gain more confidence in the produced result. An apparently suitable existing visualisation using log-based behavioural differencing suffers from scalability issues when applied to industrial-size cases. We propose an adapted visualisation tool that highlights those parts that really changed in-between iterations of a large refactoring process and collapses those parts that remain stable. We show that our alternative visualisation scales well on large logs of a process with many possible refactoring chains, of which significant parts are shared. Consequently, it allows engineers and stakeholders to quickly answer relevant questions about what happened during the refactoring process.

This paper studies how a simple approach based on fuzzing testing can help authors of Solidity contracts to accurately estimate the gas cost of services specified in a contract. Our fuzzer creates a private blockchain and randomly generates transactions. Such an environment is meant to simulate large scale behavior that may be seen in a public blockchain. Our fuzzer handles Ethereum starting and target endpoints in a transaction to accommodate requirements expressed in financial contracts. By comparing the gas computation made by the Ethereum Solidity compiler and the actual consumption during our fuzzing, we are able to find discrepancies between predicted and real gas consumption. Our findings are beneficial to transaction authors to correctly predict the computing resources of Ethereum miners.

To characterize the building blocks of a legacy software system (e.g., structure, dependencies), programmers usually spend a long time navigating its source code. Yet, modern integrated development environments (IDEs) do not provide appropriate means to efficiently achieve complex software comprehension tasks. To deal with this unfulfilled need, we present Hunter, a tool for the visualization of JavaScript applications. Hunter visualizes source code through a set of coordinated views that include a node-link diagram that depicts the dependencies among the components of a system, and a treemap that helps programmers to orientate when navigating its structure.

Motivation: Software visualization can be helpful in comprehending the architecture of large software systems. Traditionally, software visualisation focuses on representing the structural perspectives of systems. In this paper we enrich this perspective by adding the notion of role-stereotype. This rolestereotype carries information about the type of functionality that a class has in the system as well as the types of collaborations with other classes that it typically has.Objective: We propose an interactive visualization called RoleViz, that visualizes system architectures in which architectural elements are annotated with their role-stereotypes.Method: We conducted a user-study in which developers use RoleViz and Softagram (a commercial tool for software architecture comprehension) to solve two separate comprehension tasks on a large open source system. We compared RoleViz against Softagram in terms of participant's: (i) perceived cognitive load, (ii) perceived usability, and (iii) understanding of the system. Result: In total, 16 developers participated in our study. Six of the participants explicitly indicated that visualizing roles helped them complete the assigned tasks. Our observations indicate significant differences in terms of participant's perceived usability and understanding scores.Conclusion: The participants achieved better scores on completing software understanding tasks with RoleViz without any cognitive-load penalty.

Genetic algorithms are an efficient mechanism to generate unit tests. Automatically generated unit tests are known to be an important asset to identify software defects and define oracles. However, configuring the test generation is a tedious activity for a practitioner due to the inherent difficulty to adequately tuning the generation process. This paper presents TestEvoViz, a visual technique to introspect the generation of unit tests using genetic algorithms. TestEvoViz offers the practitioners a visual support to expose some of the decisions made by the test generation. A number of case studies are presented to illustrate the expressiveness of TestEvoViz to understand the effect of the algorithm configuration.Artifact - https://github.com/andreina-covi/ArtifactSSG.

Several studies provide the questions developers ask during software evolution tasks, providing foundations for subsequent work. Nevertheless, none of them focus on Live Programming environments that gain in popularity as they are perceived to have a positive effect on programming tasks. Studying the impact of a Live Programming environment on software development activities is thus the goal of this study. In a partial replication of the study by Sillito et al., we conducted 17 software evolution sessions in a Live Programming environment and report 1,161 developer questions asked during these sessions. We contrast our results with the results by Sillito et al., focusing on the question occurrences, question complexity and what information participants used to gain a required knowledge. We report eight new questions and observe that the Live Programming facilities do have an impact on the way developers ask questions about source code and use tools to gain corresponding knowledge.

Software performance may be significantly affected by source code modifications. Understanding the effect of these changes along different software versions is a challenging and necessary activity to debug performance failures. It is not sufficiently supported by existing profiling tools and visualization approaches. Practitioners would need to manually compare calling context trees and call graphs. We aim at better supporting the comparison of benchmark executions along multiple software versions. We propose Performance Evolution Matrix, an interactive visualization technique that contrasts runtime metrics to source code changes. It combines a comparison of time series data and execution graphs in a matrix layout, showing performance and source code metrics at different levels of granularity. The approach guides practitioners from the high-level identification of a performance regression to the changes that might have caused the issue. We conducted a controlled experiment with 12 participants to provide empirical evidence of the viability of our method. The results indicate that our approach can reduce the effort for identifying sources of performance regressions compared to traditional profiling visualizations.

Monitoring software performance evolution is a daunting and challenging task. This paper proposes a lightweight visualization technique that contrasts source code variation with the memory consumption and execution time of a particular benchmark. The visualization fully integrates with the commit graph as common in many software repository managers. We illustrate the usefulness of our approach with two application examples. We expect our technique to be beneficial for practitioners who wish to easily review the impact of source code commits on software performance.

Live Programming environments allow programmers to get feedback instantly while changing software. Liveness is gaining attention among industrial and open-source communities; several IDEs offer high degrees of liveness. While several studies looked at how programmers work during software evolution tasks, none of them consider live environments. We conduct such a study based on an analysis of 17 programming sessions of practitioners using Pharo, a mature Live Programming environment. The study is complemented by a survey and subsequent analysis of 16 programming sessions in additional languages, e.g., JavaScript. We document the approaches taken by developers during their work. We find that some liveness features are extensively used, and have an impact on the way developers navigate source code and objects in their work.

Beyond a practical use in code review, source code change detection (SCCD) is an important component of many mining software repositories (MSR) approaches. As such, any error or imprecision in the detection may result in a wrong conclusion while mining repositories. We identified, analyzed, and characterized impressions in GumTree, which is the most advanced algorithm for SCCD. After analyzing its detection accuracy over a curated corpus of 107 C# projects, we diagnosed several imprecisions. Many of our findings confirm that a more language-aware perspective of GumTree can be helpful in reporting more precise changes.

Profiling the memory consumption of a software execution is usually carried out by characterizing calling-context trees. However, the plurality nature of this data-structure makes it difficult to adequately and efficiently exploit in practice. As a consequence, most of anomalies in memory footprints are addressed either manually or in an ad-hoc way. We propose an interactive visualization of the execution context related to object productions. Our visualization augments the traditional calling-context tree with visual cues to characterize object allocation sites.We performed a qualitative study involving eight software engineers conducting a software execution memory assessment. As a result, we found that participants find our visualization as beneficial to characterizing a memory consumption and to reducing the overall memory footprint.

The following topics are dealt with: data visualisation; software engineering; Java; program visualisation; data analysis; software maintenance; software metrics; software quality; virtual reality; trees (mathematics).

Modern object-oriented programming languages greatly alleviate the memory management for programmers. Despite the efficiency of garbage collection and Just-In-Time program analyzes, memory still remains prone to be wasted.

To obtain an accurate understanding of program behavior, developers use a set of tools and techniques such as logging outputs, debuggers, profilers, and visualizations. These support an in-depth analysis of the program behavior, each approach focusing on a different aspect. What is missing, however, is an approach to get an overview of a program execution. As a first step to fill this gap, this paper presents an approach to generate Method Execution Reports. Each report summarizes the execution of a selected method for a specific execution of the program using natural-language text and embedded visualizations. A report provides an overview of the dynamic calls and time consumption related to the selected method. We present a framework to generate these reports and discuss the specific instantiation and phrasing we have chosen. Our results comprise feedback from developers discussing the understandability and usefulness of our approach and a task-based comparison to state-of-the-art solutions.

Identifying dependencies between classes is an essential activity when maintaining and evolving software applications. It is also known that JavaScript developers often use classes to structure their projects. This happens even in legacy code, i.e., code implemented in JavaScript versions that do not provide syntactical support to classes. However, identifying associations and other dependencies between classes remain a challenge due to the lack of static type annotations. This paper investigates the use of type inference to identify relations between classes in legacy JavaScript code. To this purpose, we rely on Flow, a state-of-the-art type checker and inferencer tool for JavaScript. We perform a study using code with and without annotating the class import statements in two modular applications. The results show that precision is 100% in both systems, and that the annotated version improves the recall, ranging from 37% to 51% for dependencies in general and from 54% to 85% for associations. Therefore, we hypothesize that these tools should also depend on dynamic analysis to cover all possible dependencies in JavaScript code.

JavaScript is the most popular programming language for the Web. Although the language is prototype-based, developers can emulate class-based abstractions in JavaScript to master the increasing complexity of their applications. Identifying classes in legacy JavaScript code can support these developers at least in the following activities: (1) program comprehension; (2) migration to the new JavaScript syntax that supports classes; and (3) implementation of supporting tools, including IDEs with class-based views and reverse engineering tools. In this paper, we propose a strategy to detect class-based abstractions in the source code of legacy JavaScript systems. We report on a large and in-depth study to understand how class emulation is employed, using a dataset of 918 JavaScript applications available on GitHub. We found that almost 70% of the JavaScript systems we study make some usage of classes. We also performed a field study with the main developers of 60 popular JavaScript systems to validate our findings. The overall results range from 97% to 100% for precision, from 70% to 89% for recall, and from 82% to 94% for F-score.

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

Software visualization can be very useful for answering complex questions that arise in the software development process. Although modern visualization engines offer expressive APIs for building such visualizations, developers often have difficulties to (1) identify a suitable visualization technique to answer their particular development question, and to (2) implement that visualization using the existing APIs. Examples that illustrate the usage of an engine to build concrete visualizations offer a good starting point, but developers may have to traverse long lists of categories and analyze examples one-by-one to find a suitable one. We propose MetaVis, a tool that fills the gap between existing visualization techniques and their practical applications during software development. We classify questions frequently formulated by software developers and for each, based on our expertise, identify suitable visualizations. MetaVis uses tags mined from these questions to offer a tag-iconic cloud-based visualization. Each tag links to suitable visualizations that developers can explore, modify and try out. We present initial results of an implementation of MetaVis in the Pharo programming environment. The tool visualizes 76 developers' questions assigned to 49 visualization examples.

Static and dynamic evolution of software systems may be described in terms of connection additions and removals in a graph. Due to the inherent complexity of software, navigating through such a dynamic network is a non-trivial task and extracting relevant information typically involves sophisticated queries. We explore the notion of space-time cube, a well-known 3D representation of an evolving dynamic graph, to support a set of software engineering activities. CuboidMatrix is a visualization tool that offers simple and expressive navigation operations. We have evaluated our tool against two software comprehension activities, namely (i) assessing interaction of classes during a software execution and (ii) exploring the cause of breaking Lint-like quality rules over a large number of software revisions.

Object-oriented programming supports object mutation during a program execution. A mutation occurs whenever a value is assigned to an object field. Analyzing the evolution of object mutation is known to be difficult. Unfortunately, classical code debuggers painfully support the analysis of object mutations. Object Evolution Blueprint is a visualization dedicated to exploring object mutation over time. Our blueprint visually and concisely represents sequences of field mutations. The history of each field is adequately shown with respect to the dynamic value types. We have observed the use of our blueprint with three practitioners. Our visualization has been well received and accepted to complete two different software comprehension tasks. Moreover, our user study shows that the visualization is both intuitive and simple to learn.

Source code changes may inadvertently introduce performance regressions. Benchmarking each software version is traditionally employed to identify performance regressions. Although effective, this exhaustive approach is hard to carry out in practice. This paper contrasts source code changes against performance variations. By analyzing 1,288 software versions from 17 open source projects, we identified 10 source code changes leading to a performance variation (improvement or regression). We have produced a cost model to infer whether a software commit introduces a performance variation by analyzing the source code and sampling the execution of a few versions. By profiling the execution of only 17% of the versions, our model is able to identify 83% of the performance regressions greater than 5% and 100% of the regressions greater than 50%.

Little is known about how software performance evolves across software revisions. The severity of this situation is high since (i) most performance variations seem to happen accidentally and (ii) addressing a performance regression is challenging, especially when functional code is stacked on it. This paper reports an empirical study on the performance evolution of 19 applications, totaling over 19 MLOC. It took 52 days to run our 49 benchmarks. By relating performance variation with source code revisions, we found out that: (i) 1 out of every 3 application revisions introduces a performance variation, (ii) performance variations may be classified into 9 patterns, (iii) the most prominent cause of performance regression involves loops and collections. We carefully describe the patterns we identified, and detail how we addressed the numerous challenges we faced to complete our experiment.

Thresholds are essential for promoting source code metrics as an effective instrument to control the internal quality of software applications. However, little is known about the relation between software quality as identified by metric thresholds and as perceived by real developers. In this paper, we report the first results of a study designed to validate a technique that extracts relative metric thresholds from benchmark data. We use this technique to extract thresholds from a benchmark of 79 Pharo/Smalltalk applications, which are validated with five experts and 25 developers. Our preliminary results indicate that good quality applications - as cited by experts - respect metric thresholds. In contrast, we observed that noncompliant applications are not largely viewed as requiring more effort to maintain than other applications.

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

In Software Product Line (SPL) engineering, Feature Models (FMs) are widely used to capture and manage variability in a sound and organized fashion. Though semantics, notations and reasoning support are well established, maintaining large FMs is still an open problem. As large FMs naturally contain different concerns, some related to domains, others being inherently cross-cutting ones, it is challenging to find a decomposition that will tame this complexity and ease maintenance. This paper presents a visual representation of dependent FMs useful in decomposing a large FM while quantitatively visualizing constraints between and inside them. This Variability Blueprint is intuitive enough to enable the SPL maintainer to confine dependencies between FMs in a small set of identified features inside each decomposed FM. We describe our blueprint and report on its application on two case studies.

Most programming environments are shipped with accurate memory profilers. Although efficient in their analyses, memory profilers traditionally output textual listing reports, thus reducing the memory profile exploration as a set of textual pattern-matching operations. Memory blueprint visually reports the memory consumption of a program execution. A number of simple visual cues are provided to identify direct and indirect object production sites, key ingredients to efficiently address memory issues. Scalability is addressed by restricting the scope of interest both in the call graph and the considered classes. Memory blueprint has been implemented in the Pharo programming language, and is available under the MIT license.

Reporting bugs, asking for new features and in general giving any kind of feedback is a common way to contribute to an Open-Source Software (OSS) project. In GitHub, the largest code hosting service for OSS, this feedback is typically expressed as new issues for the project managed by an issue-tracking system available in each new project repository. Among other features, the issue tracker allows creating and assigning labels to issues with the goal of helping the project community to better classify and manage those issues (e.g., facilitating the identification of issues for top priority components or candidate developers that could solve them). Nevertheless, as the project grows a manual browsing of the project issues is no longer feasible. In this paper we present GiLA, a tool which generates a set of visualizations to facilitate the analysis of issues in a project depending on their label-based categorization. We believe our visualizations are useful to see the most popular labels (and their relationships) in a project, identify the most active community members for those labels and compare the typical issue evolution for each label category.

JavaScript is the de facto programming language for the Web. It is used to implement mail clients, office applications, or IDEs, that can weight hundreds of thousands of lines of code. The language itself is prototype based, but to master the complexity of their application, practitioners commonly rely on informal class abstractions. This practice has never been the target of empirical research in JavaScript. Yet, understanding it is key to adequately tuning programming environments and structure libraries such that they are accessible to programmers. In this paper we report on a large and in-depth study to understand how class emulation is employed in JavaScript applications. We propose a strategy to statically detect class-based abstractions in the source code of JavaScript systems. We used this strategy in a dataset of 50 popular JavaScript applications available from GitHub. We found four types of JavaScript software: class-free (systems that do not make any usage of classes), class-aware (systems that use classes, but marginally), class-friendly (systems that make a relevant usage of classes), and class-oriented (systems that have most of their data structures implemented as classes). The systems in these categories represent, respectively, 26%, 36%, 30%, and 8% of the systems we studied.

Object-orientation relies on polymorphism to express behavioral variants. As opposed to traditional procedural design, explicit type-based conditionals should be avoided. This message is conveyed in introductory material on object orientation, as well as in object-oriented reengineering patterns. Is this principle followed in practice? In other words, are type predicates actually used in object-oriented software, and if so, to which extent?

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

ABSTRACT Defining and formalizing the software development process is a common means for improving it. Software process modeling is often a challenging and expensive endeavor, because a well specified process may still include inefficiencies that are hardly detected before enacting it. Thus, assessing process quality is a relevant concern to improve several aspects such as conceptual integrity, correctness, usability, maintainability, and performance, among others. This paper describesAvispa, a graphical tool that allows analyzing the quality of SPEM 2.0 software processes models.Avispaidentifies a series of error patterns and highlights them in different blueprints. A detailed description of the internals ofAvispais provided to show both its structure and its extensibility mechanisms. We also present an interactive mechanism to define new analysis scripts and to implement new patterns and blueprints. This paper illustrates the application ofAvispain an industrial case study where process engineers are assisted to analyze the quality of their process. Copyright © 2013 John Wiley & Sons, Ltd.

The artifact evaluation committee (AEC) is in charge of evaluating data and software that accompany papers accepted at the ESEC/FSE'13 research track. Authors of more than 40% of the accepted papers have submitted an artifact (22 out of the 51 accepted papers). The AEC has positively evaluated more than 50% of the submitted artifacts. 12 out of the 22 artifacts have been graded as ``met expectations'' or ``exceeded expectations''.

Understanding the root of a performance drop or improvement requires analyzing different program executions at a fine grain level. Such an analysis involves dedicated profiling and representation techniques. JProfiler and YourKit, two recognized code profilers fail, on both providing adequate metrics and visual representations, conveying a false sense of the performance variation root. We propose performance evolution blueprint, a visual support to precisely compare multiple software executions. Our blueprint is offered by Rizel, a code profiler to efficiently explore performance of a set of benchmarks against multiple software revisions.

AspectMaps is a visualization that shows the structure of aspectual source code. In its design and implementation we made a number of design decisions that we present and discuss in this text. This in the light of more than two years of using, extending and maintaining the AspectMaps visualization and tool. The purpose of this paper is to share our experience with other visualization designers and implementers, as an aid in the making of their design decisions.

During the process of developing and maintaining a complex software system, developers pose detailed questions about the runtime behavior of the system. Source code views offer strictly limited insights, so developers often turn to tools like debuggers to inspect and interact with the running system. Unfortunately, traditional debuggers focus on the runtime stack as the key abstraction to support debugging operations, though the questions developers pose often have more to do with objects and their interactions. We propose object-centric debugging as an alternative approach to interacting with a running software system. We show how, by focusing on objects as the key abstraction, natural debugging operations can be defined to answer developer questions related to runtime behavior. We present a running prototype of an object-centric debugger, and demonstrate, with the help of a series of examples, how object-centric debugging offers more effective support for many typical developer tasks than a traditional stack-oriented debugger.

Generic programming is a mechanism for re-using code by abstracting specific types used in classes and programs. In this paper, we present a mechanism for adding generic programming in dynamically typed languages, showing how programmers can benefit from generic programming. Furthermore, we enhance the expressiveness of generic programming with reverse generics, a mechanism for automatically deriving new generic code starting from existing non-generic one. We implemented generics and reverse generics in Pharo Smalltalk, and we successfully used them to solve a problem of reusing unit test cases. This helped us to identify a number of bugs and anomalies in the stream class hierarchy.

SUMMARY Although traditional approaches to code profiling help locate performance bottlenecks, they offer only limited support for removing these bottlenecks. The main reason is the lack of detailed visual runtime information to identify and eliminate computation redundancy. We provide three profiling blueprints that help identify and remove performance bottlenecks. Thestructural distribution blueprintgraphically represents the CPU consumption share for each method and class of an application. Thebehavioral distribution blueprintdepicts the distribution of CPU consumption along method invocations and hints at method candidates for caching optimizations. Thebehavioral evolution blueprintcompares profiles of different versions of a software system and highlights performance‐critical changes in the system. These three blueprints helped us to significantly optimize Mondrian, an open source visualization engine. Our implementation is freely available for the Pharo development environment and has been evaluated in a number of different scenarios. Copyright © 2011 John Wiley & Sons, Ltd.

Software process models are sophisticated and large specifications aimed at organizing and managing software development. Their formal specification demands an enormous effort, but once specified there are few approaches and even fewer tools that aid the process engineer to analyze the quality of the process. For the last five years we have aided software companies in specifying their software processes and we have found a series of error patterns that indicate the potential presence of misconceptions or misspecifications. This paper presents these patterns, characterizes the kinds of errors they potentially reveal, and details how errors could be localized within a software process model. To assist process engineers to analyze the quality of their processes, we provide Avispa, a tool that graphically renders different aspects of a process model and highlights potential errors as intuitive and comprehensible indicators. The approach and the supporting tool are illustrated by applying them for analyzing the software process models of three Chilean software companies.

Wireless sensor networks necessitate a programming model different from those used to develop desktop applications. Typically, resources in terms of power and memory are constrained. C is the most common programming language used to develop applications on very small embedded sensor devices. We claim that C does not provide efficient mechanisms to address the implicit asynchronous nature of sensor sampling. C applications for these devices suffer from a disruption in their control flow. In this paper, we present FlowTalk, a new object-oriented programming language aimed at making software development for wireless embedded sensor devices easier. FlowTalk is an object-oriented programming language in which dynamicity (e.g., object creation) has been traded for a reduction in memory consumption. The event model that traditionally comes from using sensors is adapted in FlowTalk with controlled disruption, a light-weight continuation mechanism. The essence of our model is to turn asynchronous long-latency operations into synchronous and blocking method calls. FlowTalk is built for TinyOS and can be used to develop applications that can fit in 4 KB of memory for a large number of wireless sensor devices.

A trait is a unit of behaviour that can be composed with other traits and used by classes. Traits offer an alternative to multiple inheritance. Conflict resolution of traits, while flexible, does not completely handle accidental method name conflicts: if a trait with method m is composed with another trait defining a different method m then resolving the conflict may prove delicate or infeasible in cases where both versions of m are still needed. In this paper we present freezeable traits, which provide an expressive composition mechanism to support unanticipated method composition conflicts. Our solution introduces private trait methods and lets the class composer change method visibility at composition time (from public to private and vice versa). Moreover two class composers may use different composition policies for the same trait, something which is not possible in mainstream languages. This approach respects the two main design principles of traits: the class composer is empowered and traits can be flattened away. We present an implementation of freezable traits in Smalltalk. As a side-effect of this implementation we introduced private (early-bound and invisible) methods to Smalltalk by distinguishing object-sends from self-sends. Our implementation uses compile-time bytecode manipulation and, as such, introduces no run-time penalties.

Unanticipated changes to complex software systems can introduce anomalies such as duplicated code, suboptimal inheritance relationships and a proliferation of run-time downcasts. Refactoring to eliminate these anomalies may not be an option, at least in certain stages of software evolution. Classboxes are modules that restrict the visibility of changes to selected clients only, thereby offering more freedom in the way unanticipated changes may be implemented, and thus reducing the need for convoluted design anomalies. In this paper we demonstrate how classboxes can be implemented in statically-typed languages like Java. We also present an extended case study of Swing, a Java GUI package built on top of AWT, and we document the ensuing anomalies that Swing introduces. We show how Classbox/J, a prototype implementation of classboxes for Java, is used to provide a cleaner implementation of Swing using local refinement rather than subclassing.