From Featured Transition Systems to Modal Transition Systems with Variability Constraints

Abstract

Abstract. We present an automatic technique to transform a subclass of featured transition systems into modal transition systems with additional sets of variability constraints in the specific format accepted by the variability model checker VMC. Both formal models are widely used in the field of software product line engineering and both come with a dedicated model checker. The transformation serves two purposes. First, it contributes to a better understanding of the fundamental differences between the two approaches, basically concerning the way in which variability constraints are represented (in terms of features and actions, respectively). Second, it paves the way to compare the modelling and analysis of product line behaviour in two different settings.

Static Analysis of Featured Transition Systems

“…In Fig. 6, we depict an example FTS modelling the behaviour of a configurable vending machine selling soda and tea from [27], an FTS benchmark which was used in numerous publications, among which [5,6,11,30,32,[42][43][44][45]47]. Its feature model can be represented by the formula s ∨ t over the 4 features { f , c, s, t }, thus resulting in 12 products (i.e., 2 4 −4, excluding ∅, { f }, {c}, { f , c}).…”

“…However, the transformation of an ambiguous FTS into an unambiguous FTS also serves another purpose, viz. to facilitate family-based model checking of properties expressed in a fragment of the variability-aware action-based and state-based branchingtime modal temporal logic v-ACTL and interpreted on so-called 'live' MTSs [5,[11][12][13]. A Modal Transition System (MTS) is an LTS that distinguishes admissible ('may'), necessary ('must'), and optional (may but not must) transitions such that by definition all necessary and optional transitions are also admissible [53,54].…”

“…(1) AG AF pay ∨free ⊤: infinitely often, either action pay or action free is executed; (2) AG [open] AF close ⊤: it is always the case that the execution of action open is eventually followed by that of action close; (3) AG AF cancel ∨serveSoda ∨serveTea ⊤: infinitely often, either action cancel or action serveSoda or action serveTea is executed; (4) ¬E [⊤ ¬tea U serveTea ⊤]: it is not possible that action serveTea is executed without being preceded by an execution of action tea; (5) [pay] AF take ∨cancel ⊤: whenever action pay is executed, eventually also either action take or action cancel is executed. 5 Such type of formulas can efficiently be verified with the variability model checker VMC, which is a tool for the analysis of behavioural SPL models specified as an MTS together with a set of logical variability constraints (akin to feature expressions) [17,18]. VMC is the most recent member of the KandISTI product line of model checkers developed at ISTI-CNR over the past decades [13,14].…”

Using FMC for family-based analysis of software product lines

“…We have also shown how to automatically obtain a process-algebraic model from an FTS that can directly serve as input for FMC. In [7], we undertook a similar approach by providing an automatic technique to transform FTSs into MTSs with additional sets of variability constraints in the specific format accepted by VMC. This technique was illustrated on the same example.…”

“…However, the procedure can easily be automated, such that SPL developers would not even have to look at or understand the encoding. In [7], an automatic technique is provided that transforms any action-based FTS (with an associated feature model) into an MTS (with additional sets of variability constraints) in the specific format accepted by the Variability Model Checker VMC [17,19].…”