Runtime Verification (RV) is a technique to monitor formally-specified properties of the software during its execution. RV has shown to be very effective for bug finding. Unfortunately, RV typically relies on formal specification languages and learning those languages be costly for developers. This paper reports on a study to assess the challenges to specify API properties for the purpose of RV. To that end, we wrote SIESTA, a minimalist specification language, extending Java with two features (the ability to catch calls to specified methods and the ability to access the event history of a given object), and asked inexperienced developers (students) to write specifications in that language for certain parts of the Java API. Among our findings, we observed that 40% of the specifications written by the students matched the ground truth perfectly. The main messages of this work are that 1) it is feasible to use a simple imperative language for specifying properties without significant loss of generality; and that 2) developers are capable of writing specifications in the (programming) language they feel comfortable.

In software product lines development, it is sometimes important to provide a flexible binding time for features such that developers can choose between static or dynamic feature activation. For example, software products designed for devices with constrained resources may use a static binding time to avoid the performance overhead introduced by dynamic binding time activation. However, other devices can exploit binding time flexibility to support products with a dynamic binding time for some of their features. To implement this kind of flexibility in a modular way, we can define AspectJ-based idioms. Researchers have proposed Edicts, an idiom based on AspectJ and design patterns. In this article, we argue that this idiom leads to an increase in code duplication, scattering, tangling and size, which can hamper code reuse, maintenance and understanding. To mitigate such issues, this paper proposes three idioms based on aspect-oriented programming to implement flexible feature binding. We apply our three idioms, along with Edicts, to implement a flexible binding time for features in four different applications. By doing so, we were able to assess the resulting implementations by using software metrics that judge code-quality factors. Our evaluation suggests that our idioms reduce the above-mentioned problems when implementing flexible feature binding for the selected features.

Although it is assumed that the implementation of design by contract is better modularized by means of aspect-oriented (AO) programming, there is no empirical evidence on the effectiveness of AO for modularizing non-trivial design by contract code in realistic development scenarios. This paper reports a quantitative and qualitative case study that evolves a real-life application to assess various facets of the adequacy of aspects for modularizing the design by contract concern. Our evaluation focused upon a number of system changes that are typically performed during software maintenance tasks. The study was driven by an analysis of fundamental modularity attributes, such as separation of concerns, coupling, conciseness, and change propagation. We have found that AO techniques improved separation of concerns and the design stability between the design by contract code and base application code throughout the development scenarios. However, contradicting the general intuition, the AO versions of the system did not present significant gains regarding four classical size metrics we employed.

Design by Contract (DbC) is a technique for developing and improving functional software correctness through definition of "contracts" between client classes and their suppliers. Such contracts are enforced during runtime and if any of them is violated a runtime error should occur. Runtime assertions checkers (RACs) are a well-known technique that enforces such contracts. Although they are largely used to implement the DbC technique in contemporary languages, like Java, studies have shown that characteristics of contemporary exception handling mechanisms can discard contract violations detected by RACs. As a result, a contract violation may not be reflected in a runtime error, breaking the supporting hypothesis of DbC. This paper presents an error recovery technique for RACs that tackles such limitations. This technique relies on aspect-oriented programming in order to extend the functionalities of existing RACs stopping contract violations from being discarded. We applied the recovery technique on top of five Java-based contemporary RACs (i.e., JML/jml, JML/ajml, JContractor, CEAP, and Jose). Preliminary results have shown that the proposed technique could actually prevent the contract violations from being discarded regardless of the characteristics of the exception handling code of the target application.

The Java Modeling Language (JML) is a behavioral interface specification language (BISL) designed for Java. It was developed with the aim of improving the functional software correctness of Java applications. The JML compiler(jmlc) generates bytecodes that use the Java reflection mechanism and data structures not supported by Java ME applications. In order to overcome this limitation, we proposethe use of AspectJ to implement a new JML compiler, which generates an instrumented byte code compliant with both Java SE and Java ME applications. The paper also includes a comparative study to demonstrate the quality of the final code generated by our compiler. Results indicate that the overhead in code size produced by our compiler is very small, which is essential for Java ME applications.