Variability Modules

,


Introduction
The modeling of variability aspects of complex systems poses challenges currently not adequately met by standard approaches to software product line engineering (SPLE) [6,27]. A rst modeling challenge is the situation when more than one product line is involved and these product lines depend on each other. Such sets of related and interdependent product lines are known as multi product lines (MPL) [17]. A second modeling challenge is the situation when dierent product variants from the same product line need to co-exist in the same context and must be interoperable.
In Sect. 2 we exemplify both of these situations in the context of an industrial case study from the literature [20,21], performed for Deutsche Bahn Netz AG, where: (i) several interdependent product lines for networks, signals, switches, etc., occur; and (ii) for example, mechanic and electric rail switches are dierent variants of the same product line, and some train stations include both. Overall, multi product lines give rise to the quest for mechanisms for hiding implementation details, reducing dependencies, controlling access to elements, etc. [17].
Challenges similar to those mentioned above were formulated in the SPLC 2018 challenge track [8] and resulted in two proposals. The rst [34] is based on an UML-style model, the second [9] is based on the variability-aware active object language ABS [16,19]. The main drawback of either is their relative complexity, which makes these solutions unlikely to be adopted by practitioners. At the same time, supporting interoperability and encapsulation for multiple product variants from multiple product lines remains an important issue to be dealt with in a satisfactory manner. In this paper we propose a novel solution.
The central idea is to take the standard concept of a module, used to structure large software systems since the 1970s, as a baseline. Software modules are implemented in many programming and modeling languages, including ABS, Ada, Haskell, Java, Scala, to name just a few. Because modules are intended to support interoperability and encapsulation, no further ad hoc concepts are needed for this purpose. We merely add variability to modules, rendering each module a product line of standard, variability-free modules. We call the resulting language concept variability module (VM).
The main advantage of VMs is their conceptual simplicity: as a straightforward extension of standard software modules, they are rather intuitive to use for anyone familiar with modules and with software product lines. Each VM is both a module and a product line of modules. This reduction of concepts not only drastically simplies syntax, but reduces the cognitive burden on the modeler.
We substantiate this claim: in Sect. 2 we illustrate the railways MPL case study in terms of VMs without the need to introduce any formal concepts. Only in Sect. 3 we introduce the syntax of VMs formally as an extension of the standard module system of the ABS language.
We stress that VMs can be added to any class-based programming language that has modules. Moreover, while variability support is a major implementation issue, the choice of the specic approach used to implement variability [1] is orthogonal to the concept of VM. The VM incarnation given in this paper is based on the ABS language [16,19], which supports delta-oriented programming (DOP) [1, Sect. 6.6.1], [29] to implement variability. We chose ABS mainly because it features a native implementation of DOP that was successfully used in industrial case studies [21,25,38].
The formal underpinnings of VMs are covered in Sects. 35. In Sect. 3 we declare the VM syntax and spell out consistency requirements. Sect. 4 formalizes a statically checkable property of VMs: the principle of encapsulated variability, which ensures that any dependency among VMs can be reduced to dependencies among standard variability-free modules. In Sect. 5 we dene variant generation in terms of a attening semantics: the variants requested from an SPL represented by a VM, together with necessary variants of other VMs it depends upon, are generated by translating each VM into a set of variability-free, standard modules (one for per variant). This results in a variability-free program with suitably disambiguated identiers and is sucient to dene the semantics of VMs precisely, to compile and to run them.
Sect. 6 describes how the VM concept is integrated into the existing ABS tool chain and evaluates it by means of case studies. The main point is that, as long as one has control over the parser and abstract syntax tree, it is relatively straightforward to realize the attening algorithm of Sect. 5. In Sect. 7 we discuss the main decisions taken during VM design. We discuss related work in Sect. 8 and conclude in Sect. 9 by outlining ongoing work.

Overview and Motivating Example
We illustrate VMs with an example based on an industrial case study from railway engineering [21]. The scenario contains signals, switches, interlocking systems that use multiple variants of signals and switches, and a railway station that uses multiple variants of interlocking systems.  Switches and tracks are modeled by the VM in Fig. 3. It is structurally similar to Signals. A switch is either electric (controlled from the interlocking system) or mechanic (controlled locally by a lever). Class CTrack contains a reference to class CSwitch, which is not declared unique. So, even though class CTrack is not modied/removed by any delta, its declaration cannot be annotated with unique.

Variability Module Syntax
The abridged syntax of ABS with VMs (ABS-VM, for short) is given in Fig. 6.
It denes the OO fragment of ABS [16,19], extended with VM concepts. A program is a sequence of VMsas usual, X denotes a possibly empty nite sequence of elements X. A VM consists of a header (MdlH), a core part (MdlC), and a delta part (MdlD). A VM header comprises the keyword module followed by the name of the VM, by some (possibly none) import and export clauses (listing the class/interface/conguration/products names that are exported or imported by the VM, respectively), by the optional denition of a feature model (where Both the module core part and the module delta part may be empty. A module core part comprises a sequence of class and interface denitions Defn. As an extension to ABS syntax, each of these denitions may be prexed by the keyword unique. Each use of a class, interface or product name imported from another module may be prexed by the name of the modulethe name of the module must be used if there are ambiguities (e.g., when an interface with name I is imported from two modules). Moreover, each use of a non-unique class or interface imported from another module must be followed by a with-clause, specifying (by means of a conguration expression) the variant of the VM it is taken from. From now on, we consider only ABS-VM programs containing one main module (see the last paragraph of Sect. 2) and such that any other VM does not contain the keyword init. Observe that a VFM (see the last paragraph of Sect. 2) without product denition (a VFM may contain a closed product denition of the form product P for · · ·) and no occurrences of the with keyword is a variability-free ABS module.
A module delta part comprises a sequence of delta denitions Dlt followed by conguration knowledge CK. Each delta species a number of changes to the module core part. A delta comprises the keyword delta followed by the name of the delta, by a sequence of class operations CO and by a sequence of interface operations IO. An interface operation can add or remove an interface denition, or modify it by adding/removing names to the list of the extended interfaces or by adding/removing method headers. A class operation can add or remove a class denition, or modify it by adding/removing names to the list of the implemented interfaces, by adding/removing elds or by adding/removing/modifying methods. Modifying a method means to replace its body with a new body. The new body may call the reserved method name original, which during delta application is bound to the previous implementation of the method.
Conguration knowledge CK provides a mapping from products to variants by describing the connection between deltas and features: it species an activation condition Φ (a propositional formula over features) for each delta D by means of a DAC clause; and it species an application ordering between deltas by means of a sequence of DAO clauses. Each DAO clause species a partial order over the set of deltas in terms of a total order on disjoint subsets of delta namesa DAO clause allows developers to express (as a partial order) dependencies between the deltas (which are usually semantic requires relations [3]). The overall delta application order is the union of these partial ordersthe compiler checks that the resulting relation R represents a specication that is consistent (i.e., R is a partial order) and unambiguous (i.e., all the total delta application orders that respect R generate the same variant for each product). Techniques for checking that R is unambiguous are described in the literature [3,23].
The following denition of normal form formalizes a minimum consistency requirement on ABS-VM programs. mdlDelta(Prg, M, π) where π is a product of M, for any ordered sequence Dlt containing exactly those deltas of M that are activated by π, respecting the order among deltas specied in the conguration knowledge of M.
The meaning of with-free-dependencies or open with-dependencies δ occurring in a VM M is relative to the product π of M being considered. We say a dependency δ is ground to mean that it is either with-free or the conguration expression KE in its with-clause is a set of features π = {F1,. . .,Fn} (n ≥ 0). The following denition introduces notations for extracting the meaning of ground dependencies occurring in the core part of a given VM of a given program. Let all the dependencies occurring in the core part MdlC of M be ground. Then we dene ⇑ (Prg, M, MdlC, xc) as the VM core MdlC' obtained from MdlC by replacing each dependency δ occurring in it with ⇑ (Prg, M, δ, xc).

Flattening
The following denition formalizes the application of an ordered sequence of deltas Dlt (the deltas activated by a product π of a VM M) to to a sequence Defn of interface/class denitions (the non-unique class/interface denitions in the module core part MdlC of M) as described for ABS in the literaturee.g., for the Featherweight Delta ABS (FDABS) calculus [7]. Denition 9 (Delta Application). Given a sequence of declarations Defn and an ordered sequence of deltas Dlt, we write ( Dlt, Defn) → * Defn' to mean that Defn' is the outcome of the procedure described in Appendix A.1.
For all VMs M of Prg, if the products π of M are given, then the right-hand side of each open product denition product P = · · · or product P for M' = · · · in M can be evaluated to a product. This denes a mapping, denoted with genP(Prg, M, π), from open product names to products. Moreover, given a sequence of interface/class denitions Defn and a mapping σ from open product names (at least the open product names occurring in Defn) to products, we denote with σ(Defn) the denitions obtained from Defn by replacing each occurrence of an open product name P with σ(P).
Denition 10 (Grounding with-clauses). Given a Module Core Part MdlC that does not contain occurrences of product names, we write MdlC * MdlC' to mean that the module core part MdlC' has been obtained from MdlC by replacing the righthand side of each with-clause (which is a set-theoretic expression over sets of features) by the corresponding set of features (which, since the overall program is assumed in normal-form, is a product). where: Prg' (either or a variability-free ABS program) is a partial result of the attening of Prg; the set A1 identies the already generated variability-free ABS modules; the set D1 identies the variability-free ABS modules that must be generated to fulll the dependencies in Prg'; the variability-free ABS program Prg'' is obtained by adding to Prg' the code of one of the variability-free ABS modules identied by D1; the sets A2 and D2 are obtained by suitably updating A1 and D2, respectively. Let The sets A and D above refer to dependencies in the original program Prg. The implementation is available at https://github.com/abstools/abstools/ tree/local_productlines.
To integrate VMs into the ABS compiler tool chain, only the frontend (i.e., parser and preprocessor) needed to be changed. This is, because attening (Sect. 5) produces variability-free ABS code, keeping ABS code generation and semantic analysis (type checking) as is. The ABS parser's grammar is extended with the constructs described in Sect. 3. As expected, ABS's existing delta application mechanism (including calls to original(...)) could be fully reused. The implementation also includes: (i) the normal form check (Def. 1), with error reporting in case it is violated (not yet fully implemented); (ii) the PEV check (Sect. 4) with error reporting in case PEV is violated; (iii) the attening mechanism described in Sect. 5; (iv) adjustment of the feature model (needed, because VMs use a simpler feature modeling language than ABS's µT V L [5]).
Case Studies ABS-VM was used in three case studiesthe source code of the studies is available at the URL given above.
AISCO (Adaptive Information System for Charity Organizations) [35], is a modular web portal that supports the business processes (information, reporting, spending, expenditure) of charity organizations. It consists of an SPL implemented in ABS and its variability reects the diering legal and operational requirements of the organizations. The code is in production at https: //aisco.splelive.id/. The previous architecture required co-existence of multiple ABS variants of, e.g., nancial reporting. As this is not supported by classical SPL approaches, a Java framework on top of ABS handled interoperability at runtime. For the case study, the main aspects of AISCO were re-implemented in ABS-VM in 160 lines of code, one VM with four features and ve dierent deltas for nancial reporting. All variants can interoperate within one and the same program generated from the ABS-VM code.
The second case study is a portal to compare insurance services [26]. It contains a product line model with three VMs in nearly 700 lines of code with eight features.
6 It uses VMs to model dierent insurance oers. Their interoperability is required so that users can compare them in the portal.
The third case study is a re-modeling of the industrial FormbaR case study [21] (the basis of the example in Sect. 2). VMs are useful to model infrastructure elements, such as signals coming in dierent variants that must coexist and interoperate within the same infrastructure model. Ca. 20% of the code is amenable for remodeling with VM, up to now we remodeled ca. 4% of the overall code.
The partial refactoring showed that by introducing a VM with ve features (Main, Pre, Speed, Signal, PoV) and seven deltas, the total number of lines for the 6 The model contains four further features for the legacy SPL mechanism of ABS, kept for backwards compatibility. Implicit Export/Import Flattening. Each VM M must declare the union of the exports/imports of all its variants. Then the attening generates the export/import clauses of each variant by dropping export clauses for classes/interfaces not present in that variant, and by creating the import clauses for the required variants of the VMs mentioned in the import clauses of M. This design choice avoids the programming burden of writing delta operations on export/import clauses and reduces the cognitive burden to understand VM code.
We remark that to extend VMs with delta operations on export clauses, allowing to sometimes reduce export clauses, would be straightforward. On the other hand, since implicit attening drops all unused imports, deltas on import clauses provide no advantage. 7 Main signals, presignals, speed limiters, pre-speed limiters and points of visibility [21]. 8 Traits [15] are sets of methods that can be added to a class. The ABS-VM implementation supports traits. Since traits are orthogonal to the notion of VM we have not included them in the fragment of ABS-VM formalized in this paper. We refer to Damiani et al. [7] for a presentation of the notion of traits supported by ABS.
Family-based checking. The implementation of VM as part of the ABS compiler tool chain (Sect. 6) includes normal form and PEV checks before attening. We plan to add a family-based analysis [37] to checkbefore attening whether a program Prg is delta-application sound (thus ensuring, according to Theorem 2, that attening will succeed), whether the generated variability-free ABS program will be well typed, and, more generally, whether the variants of the VMs in Prg as a whole (including those not generated by attening Prg) would form a well-typed variability-free ABS program (see Sect. 9).

Related Work
Schröter et al. [32] advocate the use of suitable interfaces to support compositional analysis of MPLs consisting of feature-oriented programming 9 (FOP) [1, Sect. 6.1], [2] for SPLs in Java during dierent stages of the development process. Damiani et al. [13] informally outlined an extension of DOP to implement MPLs of Java programs by proposing linguistic constructs for dening an MPL as an SPL that imports other SPLs. In their proposal the feature model and artifact base of the importing SPL is entwined with the feature models and artifact bases of the imported SPLs. Therefore, in contrast to VMs, the proposal does not support encapsulation at SPL level. More recently, Damiani et al. [11,12] formalized an extension of DOP to implement MPLs in terms of a core calculus, where products are written in an imperative version of Featherweight Java [18].
The idea was to lift to the SPL level the use of dependent feature models to capture MPLs as advocated by Schröter et al. [31,33]. Like the earlier paper [13], the proposed SPL construct [12] models dependencies among dierent SPLs at the feature model level: to use two (or more) SPLs together, one must compose their feature models. In contrast, VMs do not require feature model composition.
The proposals mentioned above do not support variant interoperabilty. Damiani et al. [9] addressed variant interoperability in the context of ABS by considering a set of product lines, each comprising a set of modules. However, encapsulation is not realized by the mechanisms at the module level (as in VMs).
Instead, unique declarations are supported (unsatisfactorily) by common modules (which is not ne-grained enough), and the concepts of modularity (through modules) and variability (through product lines) are mixed up. In contrast, the VM concept proposed in this paper unies modules and product lines by adding variability modeling directly to modules: each module is a product line, each product line is a module. This drastically simplies the language, yet allows more far-reaching reuse of the DOP mechanism natively supported by ABS.
Furthermore, VM ease the cognitive burden of variability modeling, extending a common module framework, instead of adding another layer on top of it. 9 FOP can be characterized as the restriction of DOP, where there is a one-to-one mapping between deltas and features (each delta is activated if and only if the corresponding feature is selected), the application order is total, and there are no class/interface/eld/method removal operations [30].
Kästner et al. [22] propose a variability-aware module system (VAMS) for procedural languages. Like in our proposal, each VAMS module is an SPL. We outline the main dierences: (i) VAMS is formalized by building on a calculus in the spirit of Cardelli's module system formalization [4], where a module consists of a set of imported typed function declarations and a list of typed function denitions, and is implemented as a module system for C code.  [24] which, in turn, are inspired by a family-based analysis for FOP SPLs of Java-like programs proposed by Delaware et al. [14], as partially implemented in the AHEAD Tool Suite [36].
The VM concept can, in principle, be added to any programming language where a suitable notion of module is present (or could be added). It is worth observing that the notion of VM is orthogonal to the actual approach used to model variability. In our VM setting on top of the ABS language we use DOP, because ABS has a native DOP implementation. However, a dierent approach to implement variability (e.g., the annotative approach [1]) would work as well.
The case studies reported in this paper suggest that VMs are a good t for an object-based modeling language like ABS. Further investigations are needed to asses their suitability for general purpose languages like Java.

A For Reviewers' Convenience Only
This appendix contains additional material intended for reviewers, but not for publication in the nal version.

A.1 Delta Application Rules
In this appendix we present the rules describing the application of an ordered sequence of deltas Dlt to to a sequence of interface/class denitions Defn (see Denition 9).
The rules fall into the following categories: Rules for a Sequence of Deltas The rules in Fig