Automatic Static Analysis Tools (ASATs) are widely used by software developers to diffuse and enforce coding practices. Yet, we know little about the documentation of ASATs, despite it being critical to learn about the coding practices in the first place. We shed light on this through several contributions. First, we analyze the documentation of more than 100 rules of 16 ASATs for multiple programming languages, and distill a taxonomy of the purposes of the documentation---What triggers a rule; Why it is important; and how to Fix an issue---and its types of contents. Then, we conduct a survey to assess the effectiveness of the documentation in terms of its goals and types of content. We highlight opportunities for improvement in ASAT documentation. In particular, we find that the Why purpose is missing in half of the rules we survey; moreover, when the Why is present, it is more likely to have quality issues than the What and the Fix.

Jupyter notebooks are increasingly being adopted by teachers to deliver interactive practical sessions to their students. Notebooks come with many attractive features, such as the ability to combine textual explanations, multimedia content, and executable code alongside a flexible execution model which encourages experimentation and exploration. However, this execution model can quickly become an issue when students do not follow the intended execution order of the teacher, leading to errors or misleading results that hinder their learning. To counter this adverse effect, teachers usually write detailed instructions about how students are expected to use the notebooks. Yet, the use of digital media is known to decrease reading efficiency and compliance with written instructions, resulting in frequent notebook misuse and students getting lost during practical sessions. In this article, we present a novel approach, MOON, designed to remedy this problem. The central idea is to provide teachers with a language that enables them to formalize the expected usage of their notebooks in the form of a script and to interpret this script to guide students with visual indications in real time while they interact with the notebooks. We evaluate our approach using a randomized controlled experiment involving 21 students, which shows that MOON helps students comply better with the intended scenario without hindering their ability to progress. Our follow-up user study shows that about 75% of the surveyed students perceived MOON as rather useful or very useful.

Coding practices are increasingly used by software companies. Their use promotes consistency, readability, and maintainability, which contribute to software quality. Coding practices were initially enforced by general-purpose linters, but companies now tend to design and adopt their own company-specific practices. However, these company-specific practices are often not automated, making it challenging to ensure they are shared and used by developers. Converting these practices into linter rules is a complex task that requires extensive static analysis and language engineering expertise.In this paper, we seek to answer the following question: can coding practices be learned automatically from examples manually tagged by developers? We conduct a feasibility study using CodeBERT, a state-of-the-art machine learning approach, to learn linter rules. Our results show that, although the resulting classifiers reach high precision and recall scores when evaluated on balanced synthetic datasets, their application on real-world, unbalanced codebases, while maintaining excellent recall, suffers from a severe drop in precision that hinders their usability.

Summary Exploratory testing (ET) is a software testing approach that complements automated testing by leveraging business expertise. It has gained momentum over the last decades as it appeals testers to exploit their business knowledge to stress the system under test (SUT). Exploratory tests, unlike automated tests, are defined and executed on‐the‐fly by testers. However, testers who perform exploratory tests may be biased by their experience and, incidentally, miss anomalies or unusual interactions proposed by the SUT. This is even more complex in the context of web applications, which typically expose a huge number of interaction paths to their users. As testers of these applications cannot remember all the sequences of interactions they performed, they may fail to deeply explore the application scope. This article, therefore, introduces a new approach to assist testers in widely exploring any web application. In particular, our approach monitors the online interactions performed by the testers to suggest in real‐time the probabilities of performing next interactions. Looking at these probabilities, we claim that the testers who favour interactions that have a low probability (because they were rarely performed), will increase the diversity of their explorations. Our approach defines a prediction model, based on ‐grams, that encodes the history of past interactions and that supports the estimation of the probabilities. Integrated within a web browser extension, it automatically and transparently injects feedback within the application itself. We conduct a controlled experiment and a qualitative study to assess our approach. Results show that it prevents testers to be trapped in already tested loops, and succeeds to assist them in performing deeper explorations of the SUT.

Jupyter notebooks have gained popularity in educational settings. In France, it is one of the tools used by teachers in post-secondary classes to teach programming. When students complete their assignments, they send their notebooks to the teacher for feedback or grading. However, the teacher may not be able to reproduce the results contained in the notebooks. Indeed, students rely on the non-linearity of notebooks to write and execute code cells in an arbitrary order. Conversely, teachers are not aware of this implicit execution order and expect to reproduce the results by running the cells linearly from top to bottom. These two modes of usage conflict, making it difficult for teachers to evaluate their students' work. This article investigates the use of immediate visual feedback to alleviate the issue of non-reproducibility of students' notebooks. We implemented a Jupyter plug-in called Notebook Reproducibility Monitor (NoRM) that pinpoints the non-reproducible cells of a notebook under modifications. To evaluate the benefits of this approach, we perform a controlled study with 37 students on a programming assignment, followed by a focus group. Our results show that the plug-in significantly improves the reproducibility of notebooks without sacrificing the productivity of students.

Exploratory testing (ET) is a software testing approach that complements automated testing by leveraging business expertise. It has gained momentum over the last decades as it appeals testers to exploit their business knowledge to stress the system under test (SUT). Exploratory tests, unlike automated tests, are defined and executed on-the-fly by testers. Testers who perform exploratory tests may be biased by their past experience and therefore may miss anomalies or unusual interactions proposed by the SUT. This is even more complex in the context of web applications, which typically expose a huge number of interaction paths to their users. As testers of these applications cannot remember all the sequences of interactions they performed, they may fail to deeply explore the application scope. This paper therefore introduces a new approach to assist testers in widely exploring any web application. In particular, our approach monitors the online interactions performed by the testers to suggest in real-time the probabilities of performing next interactions. Looking at these probabilities, we claim that the testers who favour interactions that have a low probability (because they were rarely performed), will increase the diversity of their explorations. Our approach defines a prediction model, based on ${n}$-grams, that encodes the history of past interactions and that supports the estimation of the probabilities. Integrated within a web browser extension, it automatically and transparently injects feedback within the application itself. We conduct a controlled experiment and a qualitative study to assess our approach. Results show that it prevents testers to be trapped in already tested loops, and succeeds to assist them in performing deeper explorations of the SUT.

Docker is becoming a popular tool used by developers and end-users to deploy and run software applications. Dockerfiles now belong to software projects as any other software artefacts such as source code or configuration files. Many projects are even starting to maintain families of Dockerfiles rather than a single Dockerfile like the Python project who simultaneously maintains a family of 43 Dockerfiles (specific versions/dependencies). In this paper, we wonder if traditional maintenance challenge of handling duplicates arises in such projects since this challenge is classical in software development, even for non-code software artefacts. Our goal is to provide practitioners a clear explanation for why duplicates arise in projects, and what are the different means to handle duplicates with their pros and cons. To do so, we observe the practices of expert Dockerfile maintainers of Official Docker projects (128 projects) and perform a survey on 25 maintainers from our corpus. We show that duplicates in Dockerfiles are frequent in our corpus, that developers are aware of their existence, are frequently facing them and have a split opinion regarding them (error-prone but easy to maintain with the right tools). Finally, we show that some maintainers manage to limit duplicates by using ad-hoc tools. These tools while sometimes hard to set-up can help reduce the amount of duplicates by up-to 85%.

With millions of applications (apps) distributed through mobile markets, engaging and retaining end-users challenge Android developers to deliver a nearly perfect user experience. As mobile apps run in resource-limited devices, performance is a critical criterion for the quality of experience. Therefore, developers are expected to pay much attention to limit performance bad practices. On the one hand, many studies already identified such performance bad practices and showed that they can heavily impact app performance. Hence, many static analysers, a.k.a. linters, have been proposed to detect and fix these bad practices. On the other hand, other studies have shown that Android developers tend to deal with performance reactively and they rarely build on linters to detect and fix performance bad practices. In this paper, we therefore perform a qualitative study to investigate this gap between research and development community. In particular, we performed interviews with 14 experienced Android developers to identify the perceived benefits and constraints of using linters to identify performance bad practices in Android apps. Our observations can have a direct impact on developers and the research community. Specifically, we describe why and how developers leverage static source code analysers to improve the performance of their apps. On top of that, we bring to light important challenges faced by developers when it comes to adopting static analysis for performance purposes.

The timing requirements of real-time systems can be guaranteed by the well-designed scheduling.The analysis of such scheduling inputs an abstract task model of the system and outputs a diagnostic regarding the practicability of the timing requirements.Task models have evolved from periodic models to more sophisticated graph-based ones, among which the digraph real-time (DRT) task model is the most applicable because of its good expressiveness and analysis efficiency.However, the DRT model can't support the precedence constraints within or between tasks.In this paper, we propose a new task model, called the DRTPC model, that extends the DRT model to support the precedence constraint.Further, based on our model, we present a uniprocessor schedulability analysis algorithm for the static priority scheduling, and introduce an optimization technique to improve the analysis efficiency.Our experiments show that, despite the high computational complexity of the problem, our approach scales very well for large sets of tasks with precedence constraints.

The timing requirements of real-time systems can be guaranteed by well-designed scheduling policies. The analysis of such scheduling uses an abstract task model of the system to diagnose the practicability of timing requirements. The task models have evolved from periodic models to more sophisticated graph-based ones, among which digraph real-time (DRT) task model is the most applicable because of its good expressiveness and analysis efficiency. However, the DRT model cannot support the commonly used precedence constraints within or between tasks. In this paper, we propose a new task model that extends the DRT model to support precedence constraints. Based on our model, we present two methods of uniprocessor schedulability analysis for static priority scheduling policy and earliest deadline first (EDF) scheduling policy. We also introduce an optimization technique to improve the efficiency of model analysis. Our experiments show that, despite a high computational complexity of the problem, our approach scales very well for large sets of tasks with precedence constraints.

Turnover is the phenomenon of continuous influx and retreat of human resources in a team. Despite being well-studied in many settings, turnover has not been characterized for open-source software projects. We study the source code repositories of five open-source projects to characterize patterns of turnover and to determine the effects of turnover on software quality. We define the base concepts of both external and internal turnover, which are the mobility of developers in and out of a project, and the mobility of developers inside a project, respectively. We provide a qualitative analysis of turnover patterns. We also found, in a quantitative analysis, that the activity of external newcomers negatively impact software quality.

Context: Ownership metrics measure how the workload of software modules is shared among their developers. They have been shown to be accurate indicators of software quality. Objective: Since ownership metrics studies were done only on industrial software projects, we replicated such a study on Java free/libre and open source software (FLOSS) projects. Our goal was to generalize an "ownership law" that stated that minor developers should be avoided. Method: We explored the relationship between ownership metrics and fault-proneness on seven FLOSS projects, using publicly available corpora to retrieve the fault-related information. Results: In our corpus, the relationship between ownership metrics and module faults is weak. At best, less than half of projects exhibit a significant correlation, and at worst, no projects at all. Moreover, fault-proneness seems to be much more influenced by module size than by ownership. Conclusion: The results of ownership studies done on closed-source projects do not generalize to FLOSS projects. To understand the reasons for that, we performed an in-depth analysis and found that the lack of correlation between ownership metrics and module faults is due to the distributions of contributions among developers and the presence of "heroes" in FLOSS projects.

Context: Expert identification is becoming critical to ease the communication between developers in case of global software development or to better know members of large software communities. To quickly identify who are the experts that will best perform a given development task, both the assignment of skills to developers and the computation of their corresponding expertise level have to be automated. Since the real level of expertise is tedious to assess, our challenge is to identify developers having a significant level of experience with respect to a skill. Method: In this paper we propose XTic, an approach that takes up this challenge with the intent to be accurate and efficient. XTic provides a language to specify skills. It also provides an automatic process that extracts skills and experience levels from source code repositories. Our approach is based on the idea that an expert has a high level of experience with respect to a skill. Results: We have validated XTic both on open source and industrial projects to measure its accuracy and its efficiency. The results we obtained show that its accuracy is between moderate and strong and that it scales well with medium and large size software projects. Conclusion: XTic supports the specification of a diversity of developer skills and the extraction of the expertise of these developers under the form of level of experience.

At the heart of software evolution is a sequence of edit actions, called an edit script, made to a source code file. Since software systems are stored version by version, the edit script has to be computed from these versions, which is known as a complex task. Existing approaches usually compute edit scripts at the text granularity with only add line and delete line actions. However, inferring syntactic changes from such an edit script is hard. Since moving code is a frequent action performed when editing code, it should also be taken into account. In this paper, we tackle these issues by introducing an algorithm computing edit scripts at the abstract syntax tree granularity including move actions. Our objective is to compute edit scripts that are short and close to the original developer intent. Our algorithm is implemented in a freely-available and extensible tool that has been intensively validated.

Although software development involves making numerous decisions amongst alternatives, the design and implementation choices made typically become invisible; what a developer sees in the project's artifacts are the end result of all of the decisions. What if, instead, all of the choices made were tracked and it was easy for a developer to revisit a point where a decision was made and choose another alternative? What if the development environment could detect and suggest alternative choices? What if it was easy and low-cost to try another path? We explore the idea of speculative reprogramming that could support a what-if environment for the programming stages of software development.

ABSTRACT Software intensively depends on external libraries whose relevance may change during its life cycle. As a consequence, software developers must periodically reconsider the libraries they depend on, and must think about replacing them for more relevant ones. We refer to this practice as library migration. To find the best replacement for their library, they can rely on information over the Web, but they get quickly overwhelmed by the amount of data they gather. Making the right choice in this context constitutes the topic of our work. The solution we propose is to exhibit and mine the library migrations trends computed by performing a study of a large set of software projects. To perform this analysis, we have defined an automatic approach to compute library dependencies and a semi‐automatic approach that identifies library migrations. Then, we propose a deep analysis of the library migration phenomena by performing a descriptive study of a large set of software projects stored on the Githubplatform. Second, based on our descriptive study, we propose a support to developers who want to migrate their libraries. The main result of our study is that recommendations of libraries can be inferred from the analysis of the migration trends. Copyright © 2014 John Wiley & Sons, Ltd.

SUMMARY Ensuring models’ consistency is a key concern when using a model‐based development approach. Therefore, model inconsistency detection has received significant attention over the last years. To be useful, inconsistency detection has to be sound, efficient, and scalable. Incremental detection is one way to achieve efficiency in the presence of large models. In most of the existing approaches, incrementalization is carried out at the expense of the memory consumption that becomes proportional to the model size and the number of consistency rules. In this paper, we propose a new incremental inconsistency detection approach that only consumes a small and model size‐independent amount of memory. It will therefore scale better to projects using large models and many consistency rules. Copyright © 2012 John Wiley & Sons, Ltd.

Software development companies have been putting a lot of effort in adopting process models, however two main issues remain. On the one hand, process models are inherently incomplete, since companies can not capture all possible situations in a single model. On the other hand, managers can not force process participants (agents) to strictly follow these models. The effect of both issues is that companies need to be able to handle deviations during process enactment. In order to make sure that process agents follow the process model and that their deviations get detected and handled, they adopt the so-called Process-centered Software Engineering Environments (PSEEs). Unfortunately, the options proposed by these tools, when it comes to handling a deviation, are rather limited to basically ignoring or forbidding it. In the present work, we face this limitation by presenting an approach for detecting, managing and tolerating agent deviations. Besides, in this paper we present the formal specification for this approach in the Linear Temporal Logic (LTL). It has been used as a the basis of our PSEE prototype.

Describing and managing activities, resources, and constraints of software development processes is a challenging goal for many organizations. A first generation of Software Process Modeling Languages (SPMLs) appeared in the 1990s but failed to gain broad industrial support. Recently, however, a second generation of SPMLs has appeared, leveraging the strong industrial interest for modeling languages such as UML. In this paper, we propose a comparison of these UML-based SPMLs. While not exhaustive, this comparison concentrates on SPMLs most representative of the various alternative approaches, ranging from UML-based framework specializations to full-blown executable metamodeling approaches. To support the comparison of these various approaches, we propose a frame gathering a set of requirements for process modeling, such as semantic richness, modularity, executability, conformity to the UML standard, and formality. Beyond discussing the relative merits of these approaches, we also evaluate the overall suitability of these UML-based SPMLs for software process modeling. Finally, we discuss the impact of these approaches on the current state of the practice, and conclude with lessons we have learned in doing this comparison.

In this article paper entitled "From Play-In Scenarios to Code: An Achievable Dream",David Harel presented a development schema that makes it possible to go from high-level user-friendly requirements to a full system model, and from there to the final implementation. Even if Harel's schema represents a real contribution to filing the gap between user requirements and final implementations, there is few work on its feasibility and none within UML2.This paper addresses this lack. First we use UML2 sequence diagram as a formalism for requirement specification. Then an approach that synthesizes state machines from UML2 sequence diagrams is presented. From the obtained state machines, we implement a transformation to code. The AIBO platform (one of several typesof robotic pets designed and manufactured by Sony) is used as a case study toillustrate our implementation.

Nowadays, large-scale industrial software systems may involve hundreds of developers working on hundreds of different but related models representing parts of the same system specification. Detecting and resolving structural inconsistencies between these models is then critical. In this article we propose to represent models by sequences of elementary construction operations, rather than by the set of model elements they contain. Structural and methodological consistency rules can then be expressed uniformly as logical constraints on such sequences. Our approach is meta-model independent, allowing us to deal with consistency between different models whatever their kind. We have validated our approach by building a Prolog engine that detects violations of structural and methodological constraints specified on UML 2.1 models and requirement models. This engine has been integrated into two contemporary UML-based modelling environments, Eclipse EMF and Rational Software Architect (RSA).

Software processes and software process modeling approaches were and still are in the heart of enterprise preoccupations. This interest is essentially motivated by the increasing need to build reliable and complex software systems in a short time to market. During the three last decades, a variety of Process Modeling Languages were proposed in order to capture the expertise of enterprises. However no one succeeded in gaining the attention of the industry. Main reasons were because that most of them were either imprecise or not suitable to be executed or both. This paper presents UML4SPM, a UML2.0-based Language for software process modelling. Expressiveness, understandability, precision and executability were our main objectives while designing UML4SPM. Our contribution comes inform of MOF-compliant metamodel, a simple yet expressive graphical notation and diagrams and a precise semantics. In order to validate our work, we evaluate UML4SPM with the well-known ISPW-6 process example, a standard benchmark problem for software process modeling

The MDA approach aims to ease software maintenance faced with platform and business evolution. In this approach, main development artifacts, i.e. models, are defined with the Meta Object Facility (MOF) standard. To support collaborative development in MDA, we propose a mechanism for merging concurrent changes to MOF models. Our approach has the following novel functionality. First, as MOF models can have ordered relations, our mechanism can identify the order changes in MOF models, detect the conflicts caused by concurrent order changes, and integrate those changes. Second, as MOF models must respect multiplicity constraints, our mechanism detects the concurrent modifications that result in multiplicity violations. Therefore, it ensures the consistency of the merge result. Third, we offer a framework for building conflict resolution programs dedicated to developers' particular requirements. This framework offers a flexible and automated way for resolving conflicts. This work is a part of ModelBus, an open environment for CASE tool interoperability. Its contribution is to enable models to be concurrently modified by several developers and with different tools. ModelBus implementation is available as the Eclipse open source project, Model Driven Development integration (MDDi).

LIP6 and EDF have started to develop an RM-ODP framework for building open distributed systems. The first concern of this development was the construction of the Specification Exchange Service. This service, the so-called Backbone, enables to exchange RM-ODP specifications over any ORB or file system. This article presents the functionalities of the Backbone in the RM-ODP framework and its explains how meta-modeling standards such as MOF and XMI have been used to create it.

Specification is not a gimmick; it is a real discipline that offers many advantages to software developers. It is helpful for building, managing and describing applications. Specification standards are now available, such as the OMG (Object Management Group) adoption of the UML (Unified Modelling Language) notation and the RM-ODP (Reference Model for Open Distributed Processing) standards developed by ISO (International Standardisation Organisation) and ITU-T (International Telecommunication Union-Telecommunication Sector). However, these standards are totally independent, even though they deal with the same topic. In order to conciliate these two approaches, we propose a way to use the UML notation to express RM-ODP enterprise concepts.