Formal semantics, modular specification, and symbolic verification of product-line behaviour

A Featured Transition System (FTS) models the behaviour of all products of a Software Product Line (SPL) in a single compact structure, by associating action-labelled transitions with features that condition their presence in product behaviour. It may however be the case that the resulting featured transitions of an FTS cannot be executed in any product (so called dead transitions) or, on the contrary, can be executed in all products (so called false optional transitions). Moreover, an FTS may contain states from which a transition can be executed only in some products (so called hidden deadlock states). It is useful to detect such ambiguities and signal them to the modeller, because dead transitions indicate an anomaly in the FTS that must be corrected, false optional transitions indicate a redundancy that may be removed, and hidden deadlocks should be made explicit in the FTS to improve the understanding of the model and to enable efficient verification—if the deadlocks in the products should not be remedied in the first place. We provide an algorithm to analyse an FTS for ambiguities and a means to transform an ambiguous FTS into an unambiguous one. The scope is twofold: an ambiguous model is typically undesired as it gives an unclear idea of the SPL and, moreover, an unambiguous FTS can efficiently be model checked. We empirically show the suitability of the algorithm by applying it to a number of benchmark SPL examples from the literature, and we show how this facilitates a kind of family-based model checking of a wide range of properties on FTSs.

Software Product Lines (SPLs) are families of similar software products built from a common set of features. As the number of products of an SPL is potentially exponential in the number of its features, the model checking problem is harder than for single software. A practical way to face this exponential blow-up is to reuse common behaviour between products. We previously introduced Featured Transition Systems (FTS), a mathematical model that serves as a basis for efficient SPL model checking techniques. In this paper, we present ProVeLines, a product line of verifiers for SPLs that incorporates the results of over three years of research on formal verification of SPLs. Being itself a product line, our tool is flexible and extensible, and offers a wide range of solutions for SPL modelling and verification.

Software product lines (SPLs) are families of software systems sharing common assets and exhibiting variabilities specific to each product member of the family. Commonalities and variabilities are often represented as features organized in a feature model. Due to combinatorial explosion of the number of products induced by possible features combinations, exhaustive testing of SPLs is intractable. Therefore, sampling and prioritization techniques have been proposed to generate sorted lists of products based on coverage criteria or weights assigned to features. Solely based on the feature model, these techniques do not take into account behavioural usage of such products as a source of prioritization. In this paper, we assess the feasibility of integrating usage models into the testing process to derive statistical testing approaches for SPLs. Usage models are given as Markov chains, enabling prioritization of probable/rare behaviours. We used featured transition systems, compactly modelling variability and behaviour for SPLs, to determine which products are realizing prioritized behaviours. Statistical prioritization can achieve a significant reduction in the state space, and modelling efforts can be rewarded by better automation. In particular, we used MaTeLo, a statistical test cases generation suite developed at ALL4TEC. We assess feasibility criteria on two systems: Claroline, a configurable course management system, and Sferion™, an embedded system providing helicopter landing assistance.

A featured transition system is a transition system in which the transitions are annotated with feature expressions: Boolean expressions on a finite number of given features. Depending on its feature expression, each individual transition can be enabled when some features are present, and disabled for other sets of features. The behavior of a featured transition system hence depends on a given set of features. There are algorithms for featured transition systems which can check their properties for all sets of features at once, for example for LTL or CTL properties. Here we introduce a model of featured weighted automata which combines featured transition systems and (semiring-) weighted automata. We show that methods and techniques from weighted automata extend to featured weighted automata and devise algorithms to compute quantitative properties of featured weighted automata for all sets of features at once. We show applications to minimum reachability and to energy properties.

Software Product Lines (SPL) are inherently difficult to test due to the\ncombinatorial explosion of the number of products to consider. To reduce the\nnumber of products to test, sampling techniques such as combinatorial\ninteraction testing have been proposed. They usually start from a feature model\nand apply a coverage criterion (e.g. pairwise feature interaction or\ndissimilarity) to generate tractable, fault-finding, lists of configurations to\nbe tested. Prioritization can also be used to sort/generate such lists,\noptimizing coverage criteria or weights assigned to features. However, current\nsampling/prioritization techniques barely take product behavior into account.\nWe explore how ideas of statistical testing, based on a usage model (a Markov\nchain), can be used to extract configurations of interest according to the\nlikelihood of their executions. These executions are gathered in featured\ntransition systems, compact representation of SPL behavior. We discuss possible\nscenarios and give a prioritization procedure illustrated on an example.\n

This PhD project aims to automatically learn transition systems capturing the behaviour of a whole family of software-based systems. Reasoning at the family level yields important economies of scale and quality improvements for a broad range of systems such as software product lines, adaptive and configurable systems. Yet, to fully benefit from the above advantages, a model of the system family's behaviour is necessary. Such a model is often prohibitively expensive to create manually due to the number of variants. For large long-lived systems with outdated specifications or for systems that continuously adapt, the modelling cost is even higher. Therefore, this PhD proposes to automate the learning of such models from existing artefacts. To advance research at a fundamental level, our learning target are Featured Transition Systems (FTS), an abstract formalism that can be used to provide a pivot semantics to a range of variability-aware state-based modelling languages. The main research questions addressed by this PhD project are: (1) Can we learn variability-aware models efficiently? (2) Can we learn FTS in a black-box fashion? (i.e., with access to execution logs but not to source code); (3) Can we learn FTS in a white/grey-box testing fashion? (i.e., with access to source code); and (4) How do the proposed techniques scale in practice?

In a software product line (SPL), a collection of software products is defined by their commonalities in terms of features rather than explicitly specifying all products one-by-one. Several verification techniques were adapted to establish temporal properties of SPLs. Symbolic and family-based model checking have been proven to be successful for tackling the combinatorial blow-up arising when reasoning about several feature combinations. However, most formal verification approaches for SPLs presented in the literature focus on the static SPLs, where the features of a product are fixed and cannot be changed during runtime. This is in contrast to dynamic SPLs, allowing to adapt feature combinations of a product dynamically after deployment.

International audience

Some domains, specially those of critical systems,require dependable software. Ensuring dependability is not atrivial problem. Model checking can be used to estimate thereliability of a software through models that represent thebehavior of the system. Through these models it is possible toestimate and measure quantitatively properties such as reliability.In the context of Software Product Lines (SPL), we need tocheck an entire family of systems. It is not feasible to builda model for each configuration of a SPL as the number ofmodels required can be very large. Some contributions directlyaddress this issue proposing techniques specifically tailored forSPL. Particularly, the technique of parametric model-checkingallows the use of a single model to obtain properties values fromdifferent configurations through an arithmetic formula. However,even an arithmetic formula may not be easy to evaluate. If thenumber of operands is large enough the cost of evaluation ofthis formula could also be large. Current techniques may imposelimitations over the variability and/or system architecture. To thebest of our knowledge, to handle variability on model checkingis still an open problem. This work is an investigation of thewhole process of obtaining a parametric arithmetic formulafor a SPL. Knowing this process and the factors that directlyaffect the growth of the formula, we are able to develop newtechniques to deal with parametric model-checking in SPL withless restrictions.

Software Product Line Engineering (SPLE) is a software engineering paradigm that focuses on reuse and variability. Although feature-oriented programming (FOP) can implement software product line efficiently, we still need a method to generate and prove correctness of all product variants more efficiently and automatically. In this context, we propose to manipulate feature modules which contain three kinds of artifacts: specification, code and correctness proof. We depict a methodology and a platform that help the user to automatically produce correct-by-construction product variants from the related feature modules. As a first step of this project, we begin by proposing a language, GFML, allowing the developer to write such feature modules. This language is designed so that the artifacts can be easily reused and composed. GFML files contain the different artifacts mentioned above.The idea is to compile them into FoCaLiZe, a language for specification, implementation and formal proof with some object-oriented flavor. In this paper, we define and illustrate this language. We also introduce a way to compose the feature modules on some examples.

Today's software systems are too complex to ensure security after the fact – security has to be built into systems by design. To this end, model-based techniques such as UMLsec support the design-time specification and analysis of security requirements by providing custom model annotations and checks. Yet, a particularly challenging type of complexity arises from the variability of software product lines. Analyzing the security of all products separately is generally infeasible. In this work, we propose SecPL, a methodology for ensuring security in a software product line. SecPL allows developers to annotate the system design model with product-line variability and security requirements. To keep the exponentially large configuration space tractable during security checks, SecPL provides a family-based security analysis. In our experiments, this analysis outperforms the naive strategy of checking all products individually. Finally, we present the results of a user study that indicates the usability of our overall methodology.

The verification of software product lines is an active research area. A challenge is to efficiently verify similar products without the need to generate and verify them individually. As solution, researchers suggest family-based verification approaches, which either transform compile-time into runtime variability or make verification tools variability-aware. Existing approaches either focus on theorem proving, model checking, or other verification techniques. For the first time, we combine theorem proving and model checking to evaluate their synergies for product-line verification. We provide tool support by connecting five existing tools, namely FeatureIDE and FeatureHouse for product-line development, as well as KeY, JPF, and OpenJML for verification of Java programs. In an experiment, we found the synergy of improved effectiveness and efficiency, especially for product lines with few defects. Further, we experienced that model checking and theorem proving are more efficient and effective if the product line contains more defects.

Trustworthy variant derivation with translation validation for safety critical product lines

The goal of a Software Product Line (SPL) is to provide a set of reusable software assets for the rapid production of a software systems family aimed at a specific market segment. The main objective of SPL engineering is to construct, as automatically as possible, specific products after selecting the particular set of features that must be included in them. Unlike traditional engineering of single systems, SPL engineering often requires dealing with three different languages at each stage of the software lifecycle: (1) a language for specifying the variability of the SPL (e.g. a feature model); (2) a language for designing the reusable software assets (e.g. UML 2.0); and (3) a language that specifies how these reusable assets must be composed for constructing specific products. There are currently available enough languages for variability specification and software assets design, but there is a general lack of languages for specifying and automating the composition of these assets. This paper presents as a novel contribution a process to engineer this kind of language. The process produces an editor and a compiler, which automates the composition of reusable assets, for a particular language. To explain this process a language has been developed to compose reusable assets of architectural models.

PROMELA is a high level modeling language for model checking purpose. PROMELA model can be checked using SPIN (Simple PROMELA Interpreter) model checker to ensure formally some specifications hold in the model. However, PROMELA does not have formal and clear semantics. It is interpreted under SPIN implementation only and thus is bounded into SPIN. With high-level language it has, PROMELA has gain fame in model checker world due to its easiness to capture process model using high level language. Describing PROMELA formal semantic is a good way to broaden PROMELA usage. One of PROMELA feature is the ability to model concurrent processes, in which the concurrent process may not start from the same time point. This feature, called dynamic process creation, is essential to be noticed, to ensure that state-transition of PROMELA model is correct. Dynamic process creation in PROMELA should be defined formally, we use Labeled Transition Systems (LTSs) to describe formal semantic of PROMELA dynamic process creation.