Getting through a PhD and thinking about the next steps afterwards can be daunting. In this talk, I will provide advise about what I think can make your PhD experience more enjoyable and things I might have done differently. I will also touch upon job options after a PhD and what I learned from my personal job hunt experience.
In popular continuous integration (CI) practice, coding is followed by building, integration and system testing, pre-release inspection and deploying artifacts. This can reduce integration risk and speed up development process. But large number of CI build failures may interrupt normal software development process. So, the failures need to be analyzed and fixed quickly. Although various automated program repair techniques have great potential to resolve software failures, the existing techniques mostly focus on repairing source code. So, those techniques cannot directly help resolve software build failures. Apart from that, a special challenge to fix build failures in CI environment is that the failures are often involved with both source code and build scripts. This paper outlines promising preliminary work towards automatic build repair in CI environment that involves both source code and build script. As first step we conducted an empirical study on software build failures and build fix patterns. Based on the findings of the empirical study, we developed an approach that can automatically fix build errors involving build scripts. We plan to extend this repair approach considering both source code and build script. Moreover, we plan to quantify our automatic fixes by user study and comparison between fixes generated by our approach and actual fixes.
Continuous Integration (CI) is a widely-adopted software engineering practice. Despite its undisputed benefits, like higher software quality and improved developer productivity, mastering CI is not easy. Among the several barriers when transitioning to CI, developers need to face a new type of software failures (i.e., build failures). Even when a team has successfully adopted a CI culture, living up to its principles and improving the CI practice are also challenging. In my research, I want to provide developers with support for establishing CI and proper recommendation for continuously improving their CI process.
High-fidelity GUI prototyping provides a meaningful manner for illustrating the developers’ understanding of the requirements formulated by the customer and can be used for productive discussions and clarification of requirements and expectations. However, high-fidelity prototypes are time-consuming and expensive to develop. Furthermore, the interpretation of requirements expressed in informal natural language is often error-prone due to ambiguities and misunderstandings. In this dissertation project, we will develop a methodology based on Natural Language Processing (NLP) for supporting GUI prototyping by automatically translating Natural Language Requirements (NLR) into a formal Domain-Specific Language (DSL) describing the GUI and its navigational schema. The generated DSL can be further translated into corresponding target platform prototypes and directly provided to the user for inspection. Most related systems stop after generating artifacts, however, we introduce an intelligent and automatic interaction mechanism that allows users to provide natural language feedback on generated prototypes in an iterative fashion, which accordingly will be translated into respective prototype changes.
Fork-based development is a lightweight mechanism that allows developers to collaborate with or without explicit coordination. Although it is easy to use and popular, when developers each create their own fork and develop independently, their contributions are usually not easily visible to others. When the number of forks grows, it becomes very difficult to maintain an overview of what happens in individual forks, which would lead to additional problems and inefficient practices: lost contributions, redundant development, fragmented communities, and so on. Facing the problems mentioned above, we developed two complementary strategies: (1) Identifying existing best practices and suggesting evidence-based interventions for projects that are inefficient; (2) designing new interventions that could improve the awareness of a community using fork-based development, and help developers to detect redundant development to reduce unnecessary effort.
Over the past decades, various techniques for the application of formal program analysis of software systems have been proposed. However, the application of formal methods for software verification is still limited in practise. It is acknowledged that the task of formally specifying requirements by creating property specifications and the need of the interaction by the engineer with the prover during the execution of the proof are valid hindrances. The objectives of the presented PhD project are the automated inference of declarative property specifications from example scenarios during the phase of Requirements Engineering and their automated verification on abstract model level and on code level. Applying Inductive Logic Programming, we introduce the necessary modifications and extensions of the methodology in order to enable property specification mining from example data. Example data are to be collected with the guidance by the Scenario Modeling Strategies to ensure the necessary coverage of the scenario that is stated with the application in order to correct use of the provided information in the property specification mining algorithm. However, the specification mining algorithm is expected to produce too many property specifications. To turn the weakness into strength, our approach proposes to use the properties to automate the proof and by this, reduce the necessary interaction with the prover.
Bugs in commercial software and third-party components are an undesirable and expensive phenomenon. Such software is usually released to users only in binary form. The lack of source code renders users of such software dependent on their software vendors for repairs of bugs. Such dependence is even more harmful if the bugs introduce new vulnerabilities in the software. Automatically repairing security and functionality bugs in binary code increases software robustness without any developer effort. In this research, we propose development of a binary program repair tool that uses existing bug-free fragments of code to repair buggy code.
The error repair process in software systems is,historically, a resource-consuming task that relies heavily in developer manual effort. Automatic program repair approaches enable the repair of software with minimum human interaction,therefore, mitigating the burden from developers. However, a problem automatically generated patches commonly suffer is generating low-quality patches (which overfit to one program specification, thus not generalizing to an independent oracle evaluation). This work proposes a set of mechanisms to increase the quality of plausible patches including an analysis of test suite behavior and their key characteristics for automatic program repair, analyzing developer behavior to inform the mutation operator selection distribution, and a study of patch diversity as a means to create consolidated higher quality fixes.
The increasing popularity of dynamically-typed programming languages, such as JavaScript or Python, requires specific support methods for developers to avoid pitfalls arising from the dynamic nature of these languages. Static analyses are frequently used but the dynamic type systems limit their applicability. Dynamic analyses, in contrast, depend on the execution of the code under analysis, and thus depend on the quality of existing tests. This quality of the test suite can be improved by the use of automated test generation but automated test generation for dynamically-typed programming languages itself is hard due to the lack of type information in the programs. The limitations of each of these approaches will be overcome by iteratively combining test generation with static and dynamic analysis techniques for dynamically-typed programs.
Datasets are imperative to the development and progression of software tools, not only to facilitate a fair and unbiased evaluation of their effectiveness, but also to inspire and enable the community to advance the state of the art. In this talk, I will describe BugSwarm, an infrastructure that leverages continuous integration (CI) to automatically create a continuously growing dataset of reproducible failures and fixes. BugSwarm comprises an infrastructure, dataset, REST API, and website. The current dataset consists of 3,140 pairs of failures and fixes mined from Java and Python open-source projects. The talk will also discuss initial research studies that use the BugSwarm dataset, and future directions for the BugSwarm infrastructure.
Software engineers tend to document their systems’ architectures sporadically and superficially. Additionally, engineers frequently neglect to carefully consider the architectural impact of their changes to a system’s implementation. As a result, an existing system’s architecture will over time deviate from the engineers’ intent, and it will decay through unplanned introduction of new and/or invalidation of existing design decisions. Technical debt accumulates through architectural decay, increasing the cost of making modifications to a system and decreasing the system’s dependability. In this talk, I will introduce ARCADE, an integrated collection of tools for isolating three types of architectural information from the details readily available about a system’s implementation: architectural design decisions, change, and decay. I will show how ARCADE uses this information to identify the locations in a software system’s implementation that reflect the architectural decay, the points in a system’s lifetime when that decay tends to occur, and the reasons why it occurs. I will show how architectural decay tends to correlate with the occurrence of commonly reported implementation-level issues, and how it can be predicted. Finally, I will identify steps that engineers can take to manage the accumulated technical debt by stemming the decay. Data obtained by analyzing dozens of versions of several well-known systems - Android, Hadoop, Cassandra, Struts, etc. - will be used to illustrate the discussion throughout.
For large-scale mobile apps, software reliability is of critical importance. At the same time, developers need to be able to move fast in developing new features and products. In this talk, I will describe two recent projects on using pluggable type systems to reduce the tension between these seemingly-conflicting needs. First, I will present NullAway, a novel nullability type system for Java. NullAway improves on previous work by reducing build-time overhead and requiring fewer annotations through carefully-targeted unsoundness. Then, I will describe more recent work on the Object Construction Checker, a novel type system to ensure the safe usage of builders and other complex schemes for flexible object construction.
Software architecture plays an important role in facilitating the maintenance of a software system. Over the past two decades, software architecture research has yielded many different tools and techniques for understanding and maintaining the architectures of large, complex software systems. However, empirical research and technology transfer are impeded by myriad disjoint research and development environments, lack of a shared infrastructure, high initial costs associated with developing robust tools, and a lack of datasets needed to conduct empirical research in this domain. To address these challenges, a team of software-engineering and software-architecture researchers, in collaboration with nearly 50 researchers worldwide, are producing the Software Architecture INfrastructure (SAIN), a community-wide research infrastructure to support empirical research at the intersection of software maintenance and software architecture. SAIN will address challenges involving (1) time wasted by researchers who need to “reinvent the wheel” due to tools that are inaccessible or not reusable; (2) a lack of benchmarks or datasets that can be used to conduct architecture-oriented empirical research; and (3) issues with reproducibility or replicability.
Our Normalized Java Resource (NJR) provides a dataset of Java programs that is searchable, scriptable, and executable. So far, we have normalized the representation of 50,000 Java programs and have the goal to reach 100,000. The normalization enables uniform processing of the entire dataset. I will show how NJR lets us compare static analysis tools and lets us find programs that cause tools such as decompilers to fail.
