Enforcing Behavioral Constraints in Evolving Aspect-Oriented Programs

Reasoning, specification, and verification of Aspect-Oriented (AO) programs presents unique challenges especially as such programs evolve over time. Components, base-code and aspects alike, may be easily added, removed, interchanged, or presently unavailable at unpredictable frequencies. Consequently, modular reasoning of such programs is highly attractive as it enables tractable evolution, otherwise necessitating that the entire program be reexamined each time a component is changed. It is well known, however, that modular reasoning about AO programs is difficult. In this paper, we present our ongoing work in constructing a rely-guarantee style reasoning system for the Aspect-Oriented Programming (AOP) paradigm, adopting a trace-based approach to deal with the plug-n-play nature inherent to these programs, thus easing AOP evolution

Translucid contracts: Expressive specification and modular verification of aspect oriented interfaces

As aspect-oriented (AO) programming techniques become more widely used, their use in critical systems such as aircraft and telephone networks, will become more widespread. However, careful reasoning about AO code seems difficult because: (1) advice may apply in too many places, and (2) standard specification techniques do not limit the control effects of advice. Commonly used black box specification techniques cannot easily specify control effects, such as advice that does not proceed to the advised code. In this work we avoid the first problem by using Ptolemy, a language with explicit event announcement. To solve the second problem we give a simple and understandable specification technique, translucid contracts, that not only allows programmers to write modular specifications for advice and advised code, but also allows them to reason about the code\u27s control effects. We show that translucid contracts support sound modular verification of typical interaction patterns used in AO code. We also show that translucid contracts allow interesting control effects to be specified and enforced

Actor Concurrency Bugs: A Comprehensive Study on Symptoms, Root Causes, API Usages, and Differences

Actor concurrency is becoming increasingly important in the development of real-world software systems. Although actor concurrency may be less susceptible to some multithreaded concurrency bugs, such as low-level data races and deadlocks, it comes with its own bugs that may be different. However, the fundamental characteristics of actor concurrency bugs, including their symptoms, root causes, API usages, examples, and differences when they come from different sources are still largely unknown. Actor software development can significantly benefit from a comprehensive qualitative and quantitative understanding of these characteristics, which is the focus of this work, to foster better API documentations, development practices, testing, debugging, repairing, and verification frameworks. To conduct this study, we take the following major steps. First, we construct a set of 184 real-world Stackoverflow and Github actor bugs by manual analysis of 3,924 Stackoverflow questions, answers, and comments and 3,315 Github commits, messages, original and modified code snippets, issues, and pull requests. Second, we manually study these actor bugs and their fixes to understand and classify their symptoms, root causes, and API usages. Third, we study the differences between the commonalities and distributions of symptoms, root causes, and API usages of Stackoverflow and Github actor bugs. Fourth, we discuss real-world examples of bugs with these root causes and symptoms. Finally, we investigate the relation of our findings with the findings of previous work and discuss the implications of our findings using the anecdotal evidence of our actor bug examples. A few findings of our study are: (1) Symptoms of actor bugs can be classified into 5 categories with Error and Incorrect Exceptions being the most and least common symptoms (2) Root causes of actor bugs can be classified into 10 categories with Logic and Untyped Communication being the most and least common root causes (3) A small number of API packages are responsible for most of API usages by actor bugs (4) Stackoverflow and Github actors can differ significantly in the commonality and distribution of symptoms, root causes, and API usages (5) Actor developers may need help not only with complex, unknown, or semantic bugs in the development code but also with simple, well-known, well-documented, or syntactic bugs in the test code. While some of our findings are in agreement with the findings of the previous work, others are in sharp contrast