Flexible Correct-by-Construction Programming

Correctness-by-Construction (CbC) is an incremental program construction process to construct functionally correct programs. The programs are constructed stepwise along with a specification that is inherently guaranteed to be satisfied. CbC is complex to use without specialized tool support, since it needs a set of predefined refinement rules of fixed granularity which are additional rules on top of the programming language. Each refinement rule introduces a specific programming statement and developers cannot depart from these rules to construct programs. CbC allows to develop software in a structured and incremental way to ensure correctness, but the limited flexibility is a disadvantage of CbC. In this work, we compare classic CbC with CbC-Block and TraitCbC. Both approaches CbC-Block and TraitCbC, are related to CbC, but they have new language constructs that enable a more flexible software construction approach. We provide for both approaches a programming guideline, which similar to CbC, leads to well-structured programs. CbC-Block extends CbC by adding a refinement rule to insert any block of statements. Therefore, we introduce CbC-Block as an extension of CbC. TraitCbC implements correctness-by-construction on the basis of traits with specified methods. We formally introduce TraitCbC and prove soundness of the construction strategy. All three development approaches are qualitatively compared regarding their programming constructs, tool support, and usability to assess which is best suited for certain tasks and developers.Comment: arXiv admin note: substantial text overlap with arXiv:2204.0564

Derivation of subset product lines in FeatureIDE

The development and configuration of software product lines can be challenging tasks. During development, engineers often need to focus on a particular subset of features that is relevant for them. In such cases, it would be beneficial to hide other features and their implementation. During product configuration, requirements of potentially multiple stakeholders need to be considered. Therefore, configuration often happens in stages, in which different people contribute configuration decisions for different features. Moreover, in some cases, stakeholders want to share a set of products rather than a specific one. In all these cases, the necessary operation is the same: some features from the product line are assigned a value (e.g., via a partial configuration) while other features remain configurable. In this work, we propose a subset operation that takes a product line and a partial configuration to derive a subset product line comprising only the desired subset of features and implementation artifacts. Furthermore, we present, evaluate, and publish our implementation of the proposed subset operation within the FeatureIDE framework

Variability-aware Datalog

Variability-aware computing is the efficient application of programs to different sets of inputs that exhibit some variability. One example is program analyses applied to Software Product Lines (SPLs). In this paper we present the design and development of a variability-aware version of the Souffl\'{e} Datalog engine. The engine can take facts annotated with Presence Conditions (PCs) as input, and compute the PCs of its inferred facts, eliminating facts that do not exist in any valid configuration. We evaluate our variability-aware Souffl\'{e} implementation on several fact sets annotated with PCs to measure the associated overhead in terms of processing time and database size.Comment: PADL'20 pape

AspectJML: modular specification and runtime checking for crosscutting contracts

Aspect-oriented programming (AOP) is a popular technique for modularizing crosscutting concerns. In this context, researchers have found that the realization of design by contract (DbC) is crosscutting and fares better when modularized by AOP. However, previous efforts aimed at supporting crosscutting contract modularity might actually compromise the main DbC principles. For example, in AspectJ-style, reasoning about the correctness of a method call may require a whole-program analysis to determine what advice applies and what that advice does relative to DbC implementation and checking. Also, when contracts are separated from classes a programmer may not know about them and may break them inadvertently. In this paper we solve these problems with AspectJML, a new specification language that supports crosscutting contracts for Java code. We also show how AspectJML supports the main DbC principles of modular reasoning and contracts as documentation