Real-time collaborative coding in a web IDE

This paper describes Collabode, a web-based Java integrated development environment designed to support close, synchronous collaboration between programmers. We examine the problem of collaborative coding in the face of program compilation errors introduced by other users which make collaboration more difficult, and describe an algorithm for error-mediated integration of program code. Concurrent editors see the text of changes made by collaborators, but the errors reported in their view are based only on their own changes. Editors may run the program at any time, using only error-free edits supplied so far, and ignoring incomplete or otherwise error-generating changes. We evaluate this algorithm and interface on recorded data from previous pilot experiments with Collabode, and via a user study with student and professional programmers. We conclude that it offers appreciable benefits over naive continuous synchronization without regard to errors and over manual version control.National Science Foundation (U.S.) (award IIS- 0447800

Report from GI-Dagstuhl Seminar 16394: Software Performance Engineering in the DevOps World

This report documents the program and the outcomes of GI-Dagstuhl Seminar 16394 "Software Performance Engineering in the DevOps World". The seminar addressed the problem of performance-aware DevOps. Both, DevOps and performance engineering have been growing trends over the past one to two years, in no small part due to the rise in importance of identifying performance anomalies in the operations (Ops) of cloud and big data systems and feeding these back to the development (Dev). However, so far, the research community has treated software engineering, performance engineering, and cloud computing mostly as individual research areas. We aimed to identify cross-community collaboration, and to set the path for long-lasting collaborations towards performance-aware DevOps. The main goal of the seminar was to bring together young researchers (PhD students in a later stage of their PhD, as well as PostDocs or Junior Professors) in the areas of (i) software engineering, (ii) performance engineering, and (iii) cloud computing and big data to present their current research projects, to exchange experience and expertise, to discuss research challenges, and to develop ideas for future collaborations

Understanding and Generating Patches for Bugs Introduced by Third-party Library Upgrades

During the process of software development, developers rely heavily on third-party libraries to enable functionalities and features in their projects. However, developers are faced with challenges of managing dependency messes when a project evolves. One of the most challenging problems is to handle issues caused by dependency upgrades. To better understand the issues caused by Third-party Library Upgrades (TLU), in this thesis, we conduct a comprehensive study of the bugs caused by dependency upgrades. The study is conducted on a collection of 8,952 open-source Java projects from GitHub and 304 Java projects on Apache Software Foundation (ASF) JIRA systems. We collect 83 bugs caused by inappropriate TLUs in total. Our inspection shows that TLUs are conducted out of different reasons. The most popular reason is that the project is preparing for release and wants to keep its dependencies up-to-date (62.3%). Another popular reason is that the older version of a dependency is not compatible with other dependencies (15.3%). Our inspection also indicates that the problems introduced by inappropriate dependency upgrades can be categorized into different types, i.e., program failures that are detectable statically and dynamically. Then, we investigate developers’ efforts on repairing bugs caused by inappropriate TLUs. We notice that 32.53% of these bugs can be fixed by only modifying the build scripts (which we call TLU-build bugs), 20.48% of them can be fixed by merely modifying the source code (which is called TLU-code bugs), and 16.87% of them require modifications in multiple sources. TLU-build bugs and TLU-code bugs as the two most popular types, are explored more by us. For TLU-code bugs, we summarize the common ways used to fix them. Furthermore, we study whether current repair techniques can fix TLU-code bugs efficiently. For the 14 TLU-code bugs that cause test failures and runtime failures, the study shows that existing automated program repair tools can only work on 6 of the 14 investigated bugs. Each of them can only fix a limited amount of the 6 bugs, but the union of them can finally fix 5 out of 6 bugs. For TLU-build bugs, by leveraging the knowledge from our study, we summarize common patterns to fix build scripts, and propose a technique to automatically fix them. Our evaluation shows the proposed technique can successfully fix 9 out of 14 TLU-build bugs

Uma técnica para compilar sistemas configuráveis com #ifdefs baseada no impacto da mudança.

Sistemas configuráveis tipicamente usam #ifdefs para denotar variabilidade. Gerar e compilar todas as configurações de um sistema pode consumir tempo. Uma alternativa consiste em usar analisadores sintáticos conscientes de variabilidade, como TypeChef. Porém, eles podem não escalar. Na prática, desenvolvedores podem utilizar estratégias de amostragem (sampling) para compilar apenas um subconjunto das configurações. Este trabalho propõe uma técnica para compilar sistemas configuráveis com #ifdefs baseada no impacto da mudança através da análise apenas das configurações impactadas por uma mudança de código. A técnica foi implementada em uma ferramenta chamada CHECKCONFIGMX, que reporta os novos erros de compilação introduzidos pela transformação. Um estudo empírico foi realizado para avaliar 3,913 transformações aplicadas aos 14 maiores arquivos dos sistemas configuráveis BusyBox, Apache HTTPD, e Expat. CHECKCONFIGMX encontrou 595 erros de compilação de 20 tipos introduzidos por 41 desenvolvedores em 214 commits (5.46% das transformações analisadas). No estudo realizado, a ferramenta reduziu ao menos 50% (uma média de 99%) o número de configurações compiladas em comparação à abordagem exaustiva, sem considerar feature models. CHECKCONFIGMX pode ajudar os desenvolvedores a reduzir o esforço de avaliar transformações de granularidade fina aplicadas a sistemas configuráveis com #ifdefs.Configurable systems typically use #ifdefs to denote variability. Generating and compiling all configurations may be time-consuming. An alternative consists of using variability aware parsers, such as TypeChef. However, they may not scale. In practice, developers can use sampling strategies to compile only a subset of the configurations. We propose a change-centric approach to compile configurable systems with #ifdefs by analyzing only configurations impacted by a code change. We implement it in a tool called CHECKCONFIGMX, which reports the new compilation errors introduced by the transformation. We perform an empirical study to evaluate 3,913 transformations applied to the 14 largest files of BusyBox, Apache HTTPD, and Expat configurable systems. CHECKCONFIGMX finds 595 compilation errors of 20 types introduced by 41 developers in 214 commits (5.46% of the analyzed transformations). In our study, it reduces at least 50% (an average of 99%) the number of compiled configurations by comparing with the exhaustive approach without considering a feature model. CHECKCONFIGMX may help developers to reduce compilation effort to evaluate fine-grained transformations applied to configurable systems with #ifdefs.Cape

Software development with real-time collaborative editing

Thesis (Ph. D.)--Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 2012.Cataloged from student-submitted PDF version of thesis.Includes bibliographical references (p. 129-133).This thesis presents Collabode, a web-based integrated development environment for Java. With real-time collaborative editing, multiple programmers can use Collabode to edit the same source code at the same time. Collabode introduces error-mediated integration, where multiple editors see the text of one another's changes while being isolated from errors and in-progress work, and error-free changes are integrated automatically. Three models of collaborative programming are presented and evaluated using Collabode. Classroom programming brings zero-setup web-based programming to computer science students working in a classroom or lab. Test-driven pair programming combines two existing software development strategies to create a model with clear roles and explicit tool support. And micro-outsourcing enables one programmer to easily request and integrate very small contributions from many distributed assistants, demonstrating how a system for highly-collaborative programming enables a development model infeasible with current tools. To show that highly-collaborative programming, using real-time collaborative editing of source code, is practical, useful, and enables new models of software development, this thesis presents a series of user studies. A study with pairs of both student and professional programmers shows that error-mediated integration allows them to work productively in parallel. In a semester-long deployment of Collabode, students in an MIT software engineering course used the system for classroom programming. In a lab study of a Collabode prototype, professional programmers used test-driven pair programming. Finally, a study involving both in-lab participants and contractors hired online demonstrated how micro-outsourcing allowed participants to approach programming in a new way, one enabled by collaborative editing, automatic error-mediated integration, and a web-based environment requiring no local setup.by Max Goldman.Ph.D

Towards an Ontology of Software

Software is permeating every aspect of our personal and social life. And yet, the cluster of concepts around the notion of software, such as the notions of a software product, software requirements, software specifications, are still poorly understood with no consensus on the horizon. For many, software is just code, something intangible best defined in contrast with hardware, but it is not particularly illuminating. This erroneous notion, software is just code, presents both in the ontology of software literature and in the software maintenance tools. This notion is obviously wrong because it doesn’t account for the fact that whenever someone fixes a bug, the code of a software system changes, but nobody believes that this is a different software system. Several researchers have attempted to understand the core nature of software and programs in terms of concepts such as code, copy, medium and execution. More recently, a proposal was made by Irmak to consider software as an abstract artifact, distinct from code, just because code may change while the software remains the same. We share many of his intuitions, as well as the methodology he adopts to motivate his conclusions, based on an analysis of the condition under which software maintains its identity despite change. However, he leaves the question of ‘what is the identity of software’ open, and we answer this question here. Trying to answer the question left open by Irmak, the main objective of this dissertation is to lay the foundations for an ontology of software, grounded on the foundational ontology DOLCE. This new ontology of software is intended to facilitate the communication within the community by reducing terminological ambiguities, and by resolving inconsistencies. If we had a better footing on answering the question ‘What is software?’, we'd be in a position to build better tools for maintaining and managing a software system throughout its lifetime. The research contents of the thesis consist of three results. Firstly, we dive into the ontological nature of software, recognizing it as an abstract information artifact. To support this proposal the first main contribution of the dissertation is demonstrated from three dimensions: (1) We distinguish software (non-physical object) from hardware (physical object), and demonstrate the idea that the rapid changing speed of software is supported by the easy changeability of its medium hardware; (2) Furthermore, we discuss about the artifactual nature of software, addressing the erroneous notion, software is just code, presents both in the ontology of software literature and in the software maintenance tools; (3)At last, we recognize software as an information artifact, and this approach ensures that software inherits all the properties of an information artifact, and the study and research could be directly reused for software then. Secondly, we propose an ontology founded on the concepts adopted from Requirements Engineering (RE), such as the notions of World and Machine phenomena. In this ontology, we make a sharp distinction between different kinds of software artifacts (software program, software system, and software product), and describe the ways they are inter-connected in the context of a software engineering process. Additionally, we study software from a Social Perspective, explaining the concepts of licensable software product and licensed software product. Also, we discuss about the possibility to adopt our ontology of software in software configuration management systems to provide a better understanding and control of software changes. Thirdly, we note the important role played by assumptions in getting software to fulfill its requirements. The requirements for most software systems -- the intended states-of-affairs these systems are supposed to bring about -- concern their operational environment, usually a social world. But these systems don’t have any direct means to change that environment in order to bring about the intended states-of-affairs. In what sense then can we say that such systems fulfill their requirements? One of the main contributions of this dissertation is to account for this paradox. We do so by proposing a preliminary ontology of assumptions that are implicitly used in software engineering practice to establish that a system specification S fulfills its requirements R given a set of assumptions A, and our proposal is illustrated with a meeting scheduling example

Enforcing Abstract Immutability

Researchers have recently proposed a number of systems for expressing, verifying, and inferring immutability declarations. These systems are often rigid, and do not support "abstract immutability". An abstractly immutable object is an object o which is immutable from the point of view of any external methods. The C++ programming language is not rigid–it allows developers to express intent by adding immutability declarations to methods. Abstract immutability allows for performance improvements such as caching, even in the presence of writes to object fields. This dissertation presents a system to enforce abstract immutability. First, we explore abstract immutability in real-world systems. We found that developers often incorrectly use abstract immutability, perhaps because no programming language helps developers correctly implement abstract immutability. We believe that this omission leads to incorrect usages. Specifically, we wrote a dynamic analysis that reports any writes through immutability declarations. To our knowledge, this work was the first to explore how objects implement abstract immutability (or fail to implement it). Our novel study found three uses of abstract immutability: caching, delayed initialization, and unit testing. Unit testing was a surprising application of abstract immutability, and we believe that the ability to modify state is needed for proper unit testing. Next, we explore developers' revealed needs for immutability in the source code. We found that the majority of classes contain a mix of immutable and mutable methods, with a majority of the overall methods being immutable. Immutability systems with only immutable or all-mutating classes are insufficient: developers need immutability declarations at method granularity. Our study then combined developer immutability declarations with results from a static analysis to estimate the true number of immutable methods. The static analysis checked that no transitive writes to a receiver object occurred. Our results indicated the need for a sophisticated analysis to check that these apparently abstractly immutable methods were indeed abstractly immutable. Finally, we created a novel static analysis which checks that developers follow abstract immutability. Specifically, we define abstract immutability to mean that a class's set of immutable methods is collectively free of writes to exposed fields. Our analysis found incorrect usages of abstract immutability, such as incorrect caching. This analysis is particularly valuable in the context of code evolution, whereby subsequent programmers may make changes that break previously-correct cache implementations, for instance. Our work allows developers to trust that their code is abstractly immutable