Mathieu Acher

Philippe Collet

Philippe Lahire

Robert B France

FAMILIAR: A Domain-Specific Language for Large Scale Management of Feature Models

Keywords: Domain-Specific Language, Feature Model, Software Product Lines, Variability, Model Management

The feature model formalism has become the de facto standard for managing variability in software product lines (SPLs). In practice, developing an SPL can involve modeling a large number of features representing different viewpoints, sub-systems or concerns of the software system. This activity is generally tedious and error-prone. In this article, we present FAMILIAR a Domain-Specific Language (DSL) that is dedicated to the large scale management of feature models and that complements existing tool support. The language provides a powerful support for separating concerns in feature modeling, through the provision of composition and decomposition operators, reasoning facilities and scripting capabilities with modularization mechanisms. We illustrate how an SPL consisting of medical imaging services can be practically managed using reusable FAMILIAR scripts that implement reasoning mechanisms. We also report on various usages and applications of FAMILIAR and its operators, to demonstrate their applicability to different domains and use for different purposes.

Introduction

In many domains, software-intensive systems have to be efficiently extended, changed, customized or configured for use in a particular context (e.g., to respond to the specific expectations of a customer) [START_REF] Svahnberg | A taxonomy of variability realization techniques: Research articles[END_REF][START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF]. The challenge for software practitioners is to develop and use the appropriate models, languages, and tool-supported techniques to produce and maintain multiple similar software products (variants), exploiting what they have in common and managing what varies among them.

To address this challenge, the paradigm of Software Product Line (SPL) engineering has recently emerged [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF][START_REF] Clements | Software Product Lines : Practices and Patterns[END_REF]. Its goal is to produce a family of related program variants, called an SPL, for a domain. When properly applied, SPLs can be used to realize substantial economies of scale, reduce defect rates and shorten time to market. These benefits are achieved by factoring out common artifacts (e.g., requirements, components and test cases) to facilitate their reuse. But a lack of flexibility in the reusable artifacts or a scope that is too large may have severe consequences on the engineering process. For instance, the capabilities of the software platform should not be overestimatedotherwise unrealizable software products can be proposed to customers. Therefore the modeling and management of variability is a critical task within SPL engineering [START_REF] Chen | A systematic review of evaluation of variability management approaches in software product lines[END_REF].

The variability of an SPL is usually described in terms of features, where a feature is a domain abstraction relevant to stakeholders, typically an increment in program functionality [START_REF] Classen | What's in a feature: a requirements engineering perspective[END_REF][START_REF] Apel | An overview of feature-oriented software development[END_REF]. Every product of an SPL then corresponds to a unique combination of features, called configuration. Feature Models (FMs) [START_REF] Kang | Feature-Oriented Domain Analysis (FODA)[END_REF][START_REF] Kang | FORM: a feature-oriented reuse method with domain-specific reference architectures[END_REF][START_REF] Batory | Feature models, grammars, and propositional formulas[END_REF][START_REF] Schobbens | Generic semantics of feature diagrams[END_REF][START_REF] Czarnecki | Feature diagrams and logics: There and back again[END_REF][START_REF] Thüm | Abstract features in feature modeling[END_REF] compactly represent SPL commonalities and variabilities in terms of optional, alternative and mandatory features as well as constraints over the features. An FM is basically an AND-OR graph with propositional constraints that characterizes the set of legal configurations supported by an SPL. FMs with formal semantics, reasoning techniques and tooling [START_REF] Apel | An overview of feature-oriented software development[END_REF][START_REF] Schobbens | Generic semantics of feature diagrams[END_REF][START_REF] Czarnecki | Feature diagrams and logics: There and back again[END_REF][START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF] have become the de facto standard for managing variability. They will also be part of the Common Variability Language (CVL), a future OMG standard for variability modeling [START_REF]Common Variability Language (CVL) standard[END_REF].

When applied to realistic SPLs, FMs can be large and complex, with possibly thousands of features related by numerous complex constraints [START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF][START_REF] Reiser | Multi-level feature trees: A pragmatic approach to managing highly complex product families[END_REF][START_REF] Mendonca | Decision-making coordination and efficient reasoning techniques for feature-based configuration[END_REF]. As an extreme case, the variability model of Linux exhibits 6000+ features [START_REF] She | Reverse engineering feature models[END_REF]. Furthermore, FMs can be multiple. Numerous authors report that maintaining a single large FM for an entire system is neither feasible nor desirable [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF][START_REF] Kang | FORM: a feature-oriented reuse method with domain-specific reference architectures[END_REF][START_REF] Metzger | Disambiguating the documentation of variability in software product lines: A separation of concerns, formalization and automated analysis[END_REF][START_REF] Dhungana | Structuring the modeling space and supporting evolution in software product line engineering[END_REF][START_REF] Zaid | Feature assembly: A new feature modeling technique[END_REF][START_REF] Dhungana | Configuration of multi product lines by bridging heterogeneous variability modeling approaches[END_REF][START_REF] Hubaux | Separation of concerns in feature diagram languages: A systematic survey[END_REF]. Numerous FMs are describing variability at various levels of abstraction, ranging from hardware descriptions [START_REF] Kang | FORM: a feature-oriented reuse method with domain-specific reference architectures[END_REF], organizational structures [START_REF] Reiser | Multi-level feature trees: A pragmatic approach to managing highly complex product families[END_REF], business or implementation details [START_REF] Metzger | Disambiguating the documentation of variability in software product lines: A separation of concerns, formalization and automated analysis[END_REF].

Our experience with developing SPLs in the medical imaging and video surveillance domains (details are given in Section 7) and numerous examples in the literature show that there is an increasing need to support the management of FMs on a large scale. As there can be multiple, FMs composition support is needed to group and evolve a set of similar FMs, and to manage a set of inter-related FMs. For instance, organizations can manage variability in product parts provided by external suppliers or vendors [START_REF] Hartmann | Using feature diagrams with context variability to model multiple product lines for software supply chains[END_REF][START_REF] Hartmann | Supplier independent feature modelling[END_REF][START_REF] Dhungana | Configuration of multi product lines by bridging heterogeneous variability modeling approaches[END_REF], by forming compositional SPLs [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF][START_REF] Van Der Storm | Variability and component composition[END_REF][START_REF] Bosch | Toward compositional software product lines[END_REF]. As FMs can be large and complex, complementary decomposition support is needed to reason about local properties or to support multi-perspectives of a large FM. For instance, it is the case when the feature-based configuration process is split into different steps, each tailored for a specific stakeholder [START_REF] Tun | Relating requirements and feature configurations: A systematic approach[END_REF][START_REF] Czarnecki | Overview of generative software development[END_REF][START_REF] Hubaux | Supporting multiple perspectives in feature-based configuration[END_REF]. Furthermore, as the number of configurations in an FM is exponential to the number of features, support should be automated as much as possible. As a result, a scalable management support is needed to handle complex, large, and multiple FMs.

In previous work [START_REF] Acher | Separation of concerns in feature modeling: Support and applications[END_REF][START_REF] Acher | Composing feature models[END_REF][START_REF] Acher | Comparing approaches to implement feature model composition[END_REF][START_REF] Acher | Slicing feature models[END_REF][START_REF] Acher | Feature Model Differences[END_REF], we developed the foundations for applying the principle of Separation of Concerns (SoC) to feature modeling. In [START_REF] Acher | Composing feature models[END_REF][START_REF] Acher | Comparing approaches to implement feature model composition[END_REF], we described a set of composition operators for FMs (insert, merge, aggregate) that preserved semantic properties expressed in terms of configuration sets of the composed FMs. In [START_REF] Acher | Slicing feature models[END_REF], we defined a decomposition operator that produces a projection of an FM (a slice) using a slicing criterion supported by an algorithm that can scale for very large FMs [START_REF] Acher | Separation of concerns in feature modeling: Support and applications[END_REF]. We also defined differencing techniques to understand, manipulate, visualize and reason about differences. Our previous research addressed the management of FMs mainly from a theoretical perspective. Yet, a practical solution is still missing for importing, exporting, composing, decomposing, manipulating, editing and reasoning about FMs. It is especially important for FM users since numerous FMs and numerous management operations have to be combined in practice.

This article is an extended version of the SAC'2011 paper in the Programming Languages track [START_REF] Acher | A Domain-Specific Language for Managing Feature Models[END_REF], in which we described how a set of FM management operators were integrated into a Domain-Specific Language (DSL) called FAMILIAR (for FeAture Model scrIpt Language for manIpulation and Automatic Reasoning [START_REF]FAMILIAR: FeAture Model scrIpt Language for manIpulation and Automatic Reasonning[END_REF]). In this article, we show how FAMILIAR constructs and its integrated composition, decomposition and differencing operators (to name a few) can be used to support large-scale management of FMs and thus realize complex variability management tasks. Our previous works [START_REF] Acher | Separation of concerns in feature modeling: Support and applications[END_REF][START_REF] Acher | Composing feature models[END_REF][START_REF] Acher | Comparing approaches to implement feature model composition[END_REF][START_REF] Acher | Slicing feature models[END_REF][START_REF] Acher | Feature Model Differences[END_REF][START_REF] Acher | A Domain-Specific Language for Managing Feature Models[END_REF] did not comprehensively describe how these operators are integrated into the FAMILIAR language and how this language brings benefits to SPL practitioners. In this article, we make the following contributions:

• The integration of all FM operators previously defined (e.g., slice, merge, aggregate) in a dedicated language, with additional DSL constructs to ensure an appropriate usage ;

• A real use of FAMILIAR for managing a repository of medical imaging services is illustrated ;

• Details about the language implementation (e.g., interpreter, reasoners) and development environment of the DSL are given ;

• An evaluation of the language is performed in different application domains (medical imaging, video surveillance) and for various purposes (e.g., reverse engineering FMs from legacy software artifacts, management of multi SPLs and supply chains, validation of SPLs).

The remainder of the article is organized as follows. After giving some background on FMs in Section 2, we motivate the needs to manage FMs on a large scale and discuss why a DSL appears to be an appropriate solution in Section 3. We give an overview of DSL constructs, syntactic facilities as well as operators provided in FAMILIAR so that FM users can import, export, edit, configure, compose, decompose, configure and reason about FMs in Section 4. We illustrate how a repository of medical imaging services can be practically managed using reusable scripts and automated reasoning techniques provided in FAMILIAR in Section 5. We describe the development environment of FAMILIAR and some implementation details (e.g., use of solvers) in Section 6. We report on various applications of FAMILIAR in different domains (medical imaging, video surveillance) and for different purposes (scientific workflow design, variability modeling from requirements to runtime, reverse engineering) in Section 7. We also show that some of the FAMILIAR capabilities turn out to be mandatory at this scale since without the language some analysis and reasoning operations would not be possible in the different applications. We finally discuss future work in Section 8.

Background: Feature Models

Feature Models (FMs) were first introduced in the FODA method [START_REF] Kang | FORM: a feature-oriented reuse method with domain-specific reference architectures[END_REF], which also provided a graphical representation through Feature Diagrams. An FM defines both a hierarchy, which structures features into levels of increasing detail, and some variability aspects expressed through several mechanisms. When decomposing a feature into subfeatures, the subfeatures may be optional or mandatory or may form Xor or Or-groups. In addition, any propositional constraints (e.g., implies or excludes) can be specified to express more complex dependencies between features. We consider that an FM is composed of a feature diagram coupled with a set of constraints expressed in propositional logic. Figure 1a shows an example of an FM. The feature diagram is depicted using a FODA-like graphical notation used throughout the article. The hierarchy of an FM is represented by a rooted tree G = (F , E, r) where F is a finite set of features and E ⊆ F × F is a finite set of edges (edges represent top-down hierarchical decomposition of features, i.e., parent-child relations between them) ; r ∈ F being the root feature.

Optional

φ f m 0 = MI // root ∧ MA ⇔ MI // mandatory ∧ AN ⇒ MI // optional // Xor-group ∧ MRI ⇒ MA ∧ CT ⇒ MA ∧ MA ⇒ MRI ∨ CT ∧ ¬MRI ∨ ¬CT // Or-group ∧ T 1 ⇒ MRI ∧ T 2 ⇒ MRI ∧ MRI ⇒ T 1 ∨ T 2 // constraints ∧ MRI ⇒ ¬AN (c) propositional formula
An FM defines a set of valid feature configurations. A valid configuration is obtained by selecting features so that i) if a feature is selected, its parent is also selected; ii) if a parent is selected, all the mandatory subfeatures, exactly one subfeature in each of its Xor-groups, and at least one of its Or groups are selected; iii) propositional constraints hold. For example, in Figure 1a, MRI and CT cannot be selected at the same time, while T1 cannot be selected without MRI due to the parent-child relation between them. In Figure 1b, the set of valid configurations characterized by the FM of Figure 1a is enumerated.

Definition 1 (Configuration Semantics).

A configuration of an FM f m 0 is defined as a set of selected features. f m 0 denotes the set of valid configurations of the FM f m 0 and is thus a set of sets of features.

FMs have been semantically related to propositional logic [START_REF] Batory | Feature models, grammars, and propositional formulas[END_REF][START_REF] Schobbens | Generic semantics of feature diagrams[END_REF][START_REF] Czarnecki | Feature diagrams and logics: There and back again[END_REF]. The set of configurations represented by an FM can be described by a propositional formula φ defined over a set of Boolean variables, where each variable corresponds to a feature (see Figure 1c for the propositional formula corresponding to the FM of Figure 1a). The translation of FMs into logic representations allows to use reasoning techniques for numerous automated FM analyses, for example, enumerating configurations, counting configurations, interactive guidance during configuration [START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF][START_REF] Mendonca | SAT-based analysis of feature models is easy[END_REF].

On Managing Multiple Feature Models

Our experience in the development of a real-world Video Surveillance Systems SPL [START_REF] Acher | Modeling Variability from Requirements to Runtime[END_REF] and a Medical Imaging Workflow SPL [START_REF] Acher | Composing Multiple Variability Artifacts to Assemble Coherent Workflows[END_REF] suggests that support for separating concerns and synthesizing large FMs from smaller FMs can significantly improve management of complex SPLs. Our experience led us to develop composition and decomposition operators that we implemented [START_REF] Acher | Comparing approaches to implement feature model composition[END_REF][START_REF] Acher | Slicing feature models[END_REF][START_REF] Acher | Composing feature models[END_REF]. Providing support for FM composition is not enough. To support effective development and management of large complex FM, SPL developers need scalable FM development environments that allow them to better control how large FMs are created, analyzed and evolved. This can be done by giving developers the means to define complex operations on FMs by combining basic FM operators that, for example, compose FMs, add new features, remove features, and support reasoning about FM properties.

Principles for Managing Large FMs

Scalable approaches to managing FMs should support, at least, i) separation of concerns and synthesis of large FMs from smaller FMs using decomposition and composition operators, and ii) rigorous reasoning about FM properties as they are created and evolved.

Support for separation of concerns may also help developers identify and act upon opportunities to reuse feature structures across different SPLs. For example, the reuse of software components between different SPLs in the consumer electronics domain is commonplace [START_REF] Hartmann | Using feature diagrams with context variability to model multiple product lines for software supply chains[END_REF]. There are many different dimensions (concerns) that can form the basis for separating concerns. For example, system variability is driven by several different dimensions (e.g., product types and geographic regions). In addition, organizations are increasingly faced with the challenge of managing variability in product parts provided by external suppliers. The same observation can be made in the semiconductor industry where a set of components from several suppliers has to be integrated into a product [START_REF] Hartmann | Supplier independent feature modelling[END_REF]. In addition, separating concerns in FMs can help developers manage decisions made by different stakeholders (e.g., external suppliers of product parts) [START_REF] Czarnecki | Staged Configuration through Specialization and Multilevel Configuration of Feature Models[END_REF]. In general, maintaining a single FM for the entire system may not be feasible and structuring the modeling space for software product lines can become an issue [START_REF] Dhungana | Structuring the modeling space and supporting evolution in software product line engineering[END_REF]. A number of techniques do provide some support for separating concerns. For example, FORM [START_REF] Kang | FORM: a feature-oriented reuse method with domain-specific reference architectures[END_REF] allows the connection of various layers of feature refinements. Pohl et al. distinguish external variability (visible to customers) from internal variability (hidden from customers) [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF]. We are not aware of any approach that addresses all the issues highlighted above.

Support for separating and composing FMs must be coupled with support for reasoning about FMs before, during, and after composition. The FM notation must have an adequate formal semantics to support reasoning [START_REF] Schobbens | Generic semantics of feature diagrams[END_REF]. FM semantics are typically expressed in terms of configuration sets, that is, the meaning of an FM is typically defined as the set of configurations that satisfy the constraints expressed in the FM.

Automated analysis of FMs focuses on properties of an FM, for example, checking that an FM contains at least one product, and determining the number of valid configurations characterized by an FM [START_REF] Batory | Feature models, grammars, and propositional formulas[END_REF][START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF]. We are not aware of any approach that allows a developer to control when and how reasoning tools are applied in an FM development environment that supports separation and composition of concerns.

Rationale for an FM Management DSL

There are at least three possible solutions to meet the requirements above. One approach is to reuse existing FM development tools and graphical editors. The other two involve using a language, either general-purpose or domainspecific.

Existing (Graphical) Tools vs a New Language

Several graphical FM editors are currently available, and some do provide support for managing some aspects of FM development, for example, pure::variants [41], Gears [START_REF] Krueger | The biglever software gears unified software product line engineering framework[END_REF], FeatureIDE [START_REF] Thüm | FeatureIDE: An extensible framework for feature-oriented software development[END_REF], SPLOT [START_REF] Mendonca | software product lines online tools[END_REF], FaMa [START_REF] Trinidad | FAMA framework[END_REF] or S 2 T 2 [START_REF] Botterweck | A design of a configurable feature model configurator[END_REF]. Gears (Big Lever Software Inc) and pure::variants (Pure Systems GmbH) are commercial tools with good support for binding FMs to other models and for code generation. FeatureIDE is a comprehensive environment that interconnects with different FM management tools and has a Java API to manipulate FMs. Integration of reasoning tools is thus facilitated, for example, a tool for FM edits [START_REF] Thüm | Reasoning about edits to feature models[END_REF] has been integrated. Nevertheless, current tools do not fully support the composition of FMs or decomposition of an FM into several separated FMs. A conceivable solution would be to integrate our FM operators (insert, aggregate and merge) as additional functionalities inside a mainstream graphical editor. Numerous examples and our case studies indicate that manipulating several FMs requires support for defining and replaying sequences of operations, observing properties as the FMs are manipulated, and organizing all these actions as reusable operations. These observations led us to consider developing a textual, executable language, that can be used in much the same way as scripting languages. Such a scripting language should provide i) basic sequencing of FM operations, ii) access to FM internals, iii) reasoning operations and iv) composition and decomposition mechanisms. A textual script performs a sequence of operations on FMs. Such operations are reproducible and reusable.

Obtaining the same properties in a graphical editor requires additional effort, for example, the implementation of an undo/redo system and serialization of the sequence of operations is not straightforward. The scripting aspect of the FAMILIAR language allows developers to perform operations on Feature Models by gluing together decomposition and composition operators in a straightforward manner.

It should be noted that our use of a textual scripting language does not preclude graphical counterparts built on top of the textual language.

A General-Purpose Language vs a Domain-Specific Language

As editors like FeatureIDE and frameworks such as FAMA or SPLOT provide an API, another conceivable solution would be to build an API extension in a mainstream programming language in order to provide support for using composition operators and other FM management operations. While this may be a feasible solution, it would require developers to be knowledgeable about the host language (i.e., Java), many require them to perform repetitive and error-prone actions (e.g., importing an FM or using reasoning operations). If the API was created with simplicity and readability as major objectives, and it is based on a limited set of concepts related to the domain of FMs, then one can argue that the API is an internal1 DSL, written on top of a host language.

An internal or external DSL should allow an FM user to more quickly build the code they need to manipulate FMs. The facilities provided to the FM users must allow the description of complex operations dedicated to FMs, in both a compact and readable way, while being understandable by an expert who may not necessarily be a software engineer. An external DSL seems particularly adequate in our work as it would provide only the necessary expressive power for anticipated FM manipulations. In addition, such an external DSL should be used more easily by FM users as the learning curve is expected to be more favorable.

The decision to develop a new DSL (e.g., when?, why? and how?) is a difficult one as it involves both advantages/disadvantages or risks/opportunities [START_REF] Fowler | Domain Specific Languages[END_REF][START_REF] Van Deursen | Little languages: little maintenance[END_REF][START_REF] Mernik | When and how to develop domain-specific languages[END_REF][START_REF] Kosar | Program comprehension of domain-specific and general-purpose languages: comparison using a family of experiments[END_REF]. Essential to this decision is the notion of domain that determines the scope of a DSL. Automated analysis of FMs is an active area of research and is gaining importance in the SPL community. The operators we have developed and thus the language we want to create, are obviously in that domain. Benavides et al. conduct a literature review and claim that [START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF]: "From the analysis of current solutions, we conclude that the analysis of FMs is maturing with an increasing number of contributions, operations, tools and empirical works."

Hence the development of an FM manipulation DSL that integrates automated analysis concepts seems particularly adequate. Furthermore, DSLs are considered as "enablers of reuse" [START_REF] Mernik | When and how to develop domain-specific languages[END_REF] and there is a clear opportunity to reuse operations already defined in the domain.

We further restrict the DSL to manipulation of propositional FMs. Our restriction to propositional FMs means that our DSL does not fully support extended FMs with feature attributes or constraints expressed in logics that go beyond propositional logic (e.g., [START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF][START_REF] Czarnecki | Formalizing Cardinality-based Feature Models and their Specialization[END_REF][START_REF] Michel | A formal semantics for feature cardinalities in feature diagrams[END_REF]). We and others consider that more research effort is needed in the domain of extended FMs. For example, the semantics and implementation of composition and decomposition operators for extended FMs are still to be developed. Moreover Benavides et al. [START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF] state that one of the research challenge in feature modeling is "to include feature attribute relationships for analyses on FMs and propose new operations of analysis leveraging extended FMs". Besides, FMs are usually mapped to other artefacts of an SPL (e.g., see [START_REF] Ziadi | Product Line Engineering with the UML: Deriving Products[END_REF][START_REF] Voelter | Product line implementation using aspect-oriented and model-driven software development[END_REF][START_REF] Czarnecki | Mapping features to models: A template approach based on superimposed variants[END_REF][START_REF] Lopez-Herrejon | Detecting inconsistencies in multi-view models with variability[END_REF][START_REF] Heidenreich | Relating feature models to other models of a software product line: A comparative study of featuremapper and vml*[END_REF][START_REF]Common Variability Language (CVL) standard[END_REF]). We do not consider the relationship between FMs and other artifacts, i.e., the domain of the DSL is restricted to FMs.

Existing Languages and Associated Support

The predominant idea is that we propose a textual language dedicated to the domain of FMs. TVL [START_REF] Classen | A text-based approach to feature modelling: Syntax and semantics of TVL[END_REF] (for Textual Variability Language) has similar characteristics but its focus is on specifying FMs and not on manipulating FMs. In particular, the support for reasoning about FMs is not integrated into the language and is provided in the form of a Java library. VELVET is a language for multi-dimensional feature modeling [START_REF] Rosenmüller | Multi-Dimensional Variability Modeling[END_REF]. It provides mechanisms (inheritance, aggregation, etc.) to compose2 separated FMs on demand and aims at improving the reuse of FMs. Yet support for automated decomposition or automated reasoning (e.g., detection of anomalies in an FM) is not part of the language and is devoted to an external API. We consider that FMs expressed in TVL and VELVET can be used as inputs of an DSL for managing FMs.

Besides FeatureIDE, FaMa, SPLOT, and TVL frameworks do not pursue the objective of managing multiple FMs. Reasoning operations are dedicated to be applied on an unique FM. More importantly and to the best of our knowledge, there is no comprehensive support for composing and decomposing FMs. Moreover, framework users have typically to deal with details about FM imports or reasoning solvers. As a result, manipulations are not encapsulated by operations that hide low-level programming language level details (i.e., additional effort beyond simply manipulating FM concepts is needed) and developers are required to master the framework as well as advanced skills in Java language.

The FAMILIAR Language

The next subsections will detail and illustrate the main constructs of the language as well as important FM management operators.

FAMILIAR DSL constructs

We first describe the constructs of the DSL. To structure the explanations and show the specific emphasize of the constructs, we choose to explain the DSL in terms of concepts used to study general-purpose languages [START_REF] Sun | Is my DSL a modeling or programming language?[END_REF][START_REF] Watt | Programming Language Concepts and Paradigms[END_REF]: values and types, storage and variables, bindings and encapsulation, abstractions, sequencers.

Values and Types

FAMILIAR is a typed language that supports both complex and primitive types. The various types supported by the language have been chosen according to the domain concepts identified in the previous section. Complex types are domain-specific (Feature Model, Configuration, Feature, Constraint, etc.) or generic Set which represents container values. Primitive types include String (e.g., feature names are strings), Boolean, Enum, Integer and Real.

A set of operations, called operators, are defined for a given type. To prevent FAMILIAR scripts from performing illegal operations on data, type checking is performed at run-time. Operators evaluate expression and yield one value. For example, the operator counting performs on a Feature Model and yields an Integer value (see Listing 1,line 9). More examples of FM management operators are given in the remainder of the section. Basic arithmetic, logical, set and string operators are also provided and perform on Integer, Real, Boolean, Set and String.

Storage and Variables

We provide user-defined variables to store values. Variables representing complex types record a reference to the data whereas other variables record the data value itself. (The notions of reference and value are similar to the ones used in the Java programming language). Therefore variables may be inspected and updated. In Listing 1, lines 1-4 define two variables of type Feature Model: mi1 and mi2. More details about the operator FM and the internal concrete syntax for specifying FMs are given in Section 4.2.

For variables with complex types we may need to compare either the reference or the content of the recorded data so that we propose two operators. Lines 5 and 6 illustrate the use of content equality (eq) and reference equality (==) on complex types. Lines 7 and 8 show assignments to variables of type String (str) and Set ( f mS et is a set of FMs). Listing 1: A first glimpse: variables and basic operations Note that for the variable str, the use of content or reference equality would return the same result which corresponds to content equality.

As stated above, types come with a set of operators. In particular, types have accessors for observing the content of a variable. Lines 13-17 of Listing 1 illustrate the use of accessors. In line 13, variable f1 records a reference to feature Modality (the parent of feature MRI). We consider that features are uniquely identified by their names in an FM. In line 14, variable f2 contains a reference to the feature MedicalImage (the root of the FM mi3). The remaining lines [START_REF] Reiser | Multi-level feature trees: A pragmatic approach to managing highly complex product families[END_REF][START_REF] Mendonca | Decision-making coordination and efficient reasoning techniques for feature-based configuration[END_REF][START_REF] She | Reverse engineering feature models[END_REF] illustrate operations returning i) the name of a feature, ii) the set of direct subfeatures of a given feature and iii) the number of elements of a set.

We provide a conditional construct (i.e., a classical if then else) and a loop control structure (i.e., foreach). Lines 2-5 in Listing 2 illustrate how to iterate over a set of variables (e.g., representing FMs, features, and configurations). A script writer can use a wildcard "*" to access to a set of elements (e.g., FMs, features). It may be placed just after "." or anywhere within a variable or feature name. For example, line 1 gathers in varset all the features of mi1. varset = mi1.* // it can be written: varset = features mi1 foreach (f in varset) do newName = strConcat "new_" f renameFeature f as newName end Listing 2: Foreach and wildcard: each feature name of FM mi1 becomes prefixed with "new_"

Bindings and Encapsulation

Let us consider again the FAMILIAR script of Listing 1. In line 19, the identifier Analyze is used. It corresponds to the feature Analyze of the FM mi3. As shown in line 20, it could be expressed in an equivalent but more explicit manner. Indeed, an identifier may refer to a variable identifier (e.g., oldFeatureBis in line 20 of Listing 1) or to a feature in an FM (e.g., MRI in line 13 of Listing 1).

It may happen though that two features with the same identifier are present in two different FMs (see line 21). In this case, the execution of the script is stopped and the error is reported to the FAMILIAR user.

To allow disambiguation of variables having the same name, FAMILIAR relies on namespaces. By default, a namespace is attached to each variable of type Feature Model so that it is possible to identify a feature by specifying the name of the variable of type FM followed by "."

Lines 1-2 of Listing 3 illustrate the use of namespace. Although features Modality and MedicalImage are present in two FMs, mi1 and mi2, they can be identified thanks to the namespace mechanism. Note that, in 3 of Listing 3, MRI appears only in mi3 and is non-ambiguous so that there is no need to explicitly use the namespace. Moreover FAMILIAR provides modularization mechanisms that allow for the creation and use of multiple scripts in a single SPL project, and that support the definition of reusable scripts. Namespaces are also used to logically group related variables of a script, making the development more modular.

Listing 4 illustrates how FAMILIAR supports the reuse of existing scripts. Line 1 shows how to run a script contained in the file fooScript1 from the current script. The namespace script -declaration is an abstract container providing context for all the variables of the script fooScript1. Then, in line 2 (resp. 4), we access to the set of all variables of script -declaration (resp. all variables starting by mi in script -declaration) using the wildcard previously explained. By default, a script makes visible to other scripts all its variables. Using export with several variable names means that only those variables remain visible. Using hide instead means that all variables mentioned are not visible. FAMILIAR provides a fixed set of abstractions. It is not possible to create a new type. We consider that predefined types are sufficient for managing FMs. Besides, a script embodies a sequence of operations and can be parameterized using an ordered list of parameters (see lines 2-3 in Listing 5). A parameter records a variable and, optionally, the type expected. Parameterized scripts are typically used to develop reusable analysis procedures for FMs and configurations. Listing 6 illustrates how a parameterized script can be called.

Sequencers

A sequencer is a construct that varies the normal flow of control. We provide only two sequencers, exit and assert. Both stop the execution of FAMILIAR. Specifically, the operator assert stops whenever the evaluation of the Boolean expression yields false.

Operators in a Nutshell

In the remainder of the section, we describe some important FM management operators.

Importing and Exporting FMs

We provide multiple notations for importing and exporting FMs. It includes the support 3 of SPLOT, FeatureIDE, a subset of TVL, a subset of FAMA, and S 2 T 2 . A FAMILIAR user can i) load FMs in these notations (using FM constructor) ; ii) serialize the FMs in these notations (using serialize). FAMILIAR also provides a concise notation, largely inspired from FeatureIDE [START_REF] Thüm | FeatureIDE: An extensible framework for feature-oriented software development[END_REF] and the feature-modelsynthesis project. Let us explain the notation and consider Listing 7. In line 1, the variable fm0 actually corresponds to the FM depicted in Figure 1a, page 3. MedicalImage is the root feature. ModalityAcquisition and Anonymized are child-features of MedicalImage: ModalityAcquisition is mandatory while Anonymized is optional. MRI and CT form a Xor-group and are child-features of ModalityAcquisition. T1 and T2 form an Or-group and are child-features of MRI. In line 4, MRI excludes Anonymized corresponds to a propositional constraint over the set of features of fm0 (i.e., the constraint states that features MRI and Anonymized are mutually exclusive).

Then, the variable fm0 can be used, for example in line 5, to obtain its set of configurations (the same set enumerated in Figure 1b, page 3). FMs can also be imported in other notations using the same FM constructor (in line 6 we import a TVL model while in line 7 we import an FM in FeatureIDE notation). Line 8 gives an example of a serialization in SPLOT notation.

Handling FM configurations

The language also allows FAMILIAR users to create FM configurations, and then select, deselect, or unselect a feature. To select a feature means that the configuration includes the feature. To deselect means that it will not be part of the configuration. To unselect means that no decision has been made: the feature is neither selected nor deselected. Each of these configuration manipulation operations returns a boolean value, i.e., true if the feature selected/deselected/unselected does exist and if the choices are conformant to the constraints of the FM.

An exemplified usage of these operators is given in Listing 8. In line 1, the operator configuration creates and initializes a configuration of the FM mi1 as follows: features that appear in every configuration are automatically "selected", features that appear in any configuration are automatically "deselected" while others are considered as "unselected". Lines 2-4 provide examples of the configuration manipulations. In addition, the accessors selectedF, deselectedF, unselectedF return respectively the set of selected, deselected and unselected features of a configuration. FAMILIAR provides several operators to support reasoning about FMs and configurations. Listing 9 provides a few examples of the FM manipulation and reasoning operators. The isValid operator checks whether a configuration is consistent according to its FM (see line 1). Indeed, a selection or deselection of feature may lead to an invalid configuration (e.g., when two mutually exclusive features are selected). The isValid operator can also perform on an FM (see line 3) and determines its satisfiability (i.e., an FM is unsatisfiable if it represents no configurations). The operator isComplete checks whether a configuration is complete, that is, whether all features have been selected or deselected. In addition, the compare operation is proposed to determine whether an FM is a refactoring, a generalization, a specialization or an arbitrary edit of another FM. This operation is based on the algorithm and terminology used in [START_REF] Thüm | Reasoning about edits to feature models[END_REF] (see Definition 2). Line 4 of Listing 9 illustrates comparison capabilities based on sets of configurations of FMs. cmp is an Enum type whose possible values can be REFACTORING, SPECIALIZATION, GENERALIZATION and ARBITRARY. In the example above, cmp has the value REFACTORING since mi1 and mi2 represent the same set of configurations.

Other operators have been defined in FAMILIAR for reasoning about differences of two FMs. The interested reader is referred to [START_REF] Acher | Feature Model Differences[END_REF][START_REF]Differencing techniques for feature models in familiar[END_REF] for further details.

Definition 2 (Kind of edits and Comparison). Let f and g be two FMs. f is a specialization of g if f ⊂ g . f is a generalization of g if g ⊂ f . f is a refactoring of g if g = f . f is an arbitrary edit of g if f is neither a specialization, a generalization nor a refactoring of g. A comparison computes the relationship between two FMs.

Decomposition

Managing a large number of features, governed by many and often complex rules, is obviously a problem per se for an SPL practitioner. Dividing FMs into localized and separated parts seem particularly well-suited solution to the problem, because SPL practitioners can focus their attention on one part at a time.

A first basic mechanism is to "copy" a sub-tree of an FM, including cross-tree constraints involving features of the subtree. It is the role of the extract operator. For example, let us consider f m1 (see Figure 2a). The extraction of the sub-tree rooted at feature A gives the FM depicted in Figure 2b.

This operator is purely syntactical and has two important limits. First, the operator ignores cross-tree constraints that involve features not present in the sub-tree. However these constraints may have an impact on the set of configurations. For example, considering the example of Figure 2a, the basic extraction fails to infer the transitivity of implications (e.g., D implies E) or that features E and F are mutually exclusive. Second, using the extract operator, features must belong to the same sub-tree whereas a more generic technique would be to consider any set of features of an FM (i.e., wherever they are located in the FM).

To raise the two limitations of the extract operator 4 , we developed another decomposition mechanism, called slice in FAMILIAR. The overall idea behind FM slicing is similar to program slicing [START_REF] Weiser | Program slicing[END_REF]. Program slicing techniques proceed in two steps: the subset of elements of interest (e.g., a set of variables of interest and a program location), called the slicing criterion, is first identified ; then, a slice (e.g., a subset of the source code) is computed. In the context of FMs, we define the slicing criterion as a set of features considered to be pertinent by an SPL practitioner while the slice is a new FM. It should be noted that the slicing criterion is no longer restricted to a set of features located in a specific sub-tree.

Another important difference with the extract operator is that the slice operator takes the configuration semantics of the FM into account. The operator produces a partial view of an FM that characterizes a projected set of configurations based on a criterion. The properties guaranteed by the slice are recalled in Definition 3 and illustrated hereafter. The interested reader is referred to [START_REF] Acher | Separation of concerns in feature modeling: Support and applications[END_REF][START_REF] Acher | Slicing feature models[END_REF] for a formal definition. Implementation details of the operator are discussed in Section 6. Definition 3 (Slice). We define slice as an operation on FM, denoted Π F slice (F M), where F slice = { f t 1 , f t 2 , ..., f t n } ⊆ F is a set of features. The result of the slice operation is a new FM, F M slice , such that:

F M slice = { x ∩ F slice | x ∈ F M }
F M slice is called the projected set of configurations. Furthermore, the feature hierarchy of F M slice is defined as follows: its features are connected to their closest ancestor if their parent is not part of the slicing criterion.

In order to be practically used in FAMILIAR, we developed a specific syntax for the slice operator: fmS = slice anFM including | excluding setOfFeatures Listing 10: Syntax of the slice operator anFM is the input FM to be sliced and fmS is the resulting FM (note that anFM remains unchanged). The set of features that constitutes the slicing criterion can be specified either by inclusion (keyword: including) or exclusion (keyword: excluding). Language facilities are offered by FAMILIAR to specify the slicing criterion. A specific notation allows an SPL practitioner to select a set of features. Basic operators to perform the union, intersection or difference of feature sets are also provided. Some syntax examples of the slice operator are given in Figure 3.

In Figure 3a, fm1.P* corresponds to a set of features including feature P plus the descendant features of feature P in f m1. We can notice that the features R and S form an Xor-group in f m3 whereas these features form an Orgroup in the original FM f m1. The presence of an Or-group in f m1 can be seen as an anomaly, since the variability information is not correctly modeled [START_REF] Trinidad | Automated error analysis for the agilization of feature modeling[END_REF][START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF]. These anomalies can be the consequence of a human design error or an an automated operation (e.g., when two FMs are composed, see below for an example). Generally, these anomalies are regarded as a negative property of an FM since it can decrease its maintainability or understandability. Therefore the slice can be used to correct some anomalies.

In Figure 3b, fm1.A* corresponds to a set of features including feature A plus the descendant features of feature A in f m1. We can notice that features E and F now form an Xor-group, thus showing again the corrective capabilities of the slice operator. In Figure 3c, the features of the slicing criterion do not necessary belong to the same sub-tree: {A, E, D, F} corresponds to a set of four features A, E, D, F of fm1.

Composition

Two forms of composition, aggregate and merge, are described hereafter.

Merging FMs. The merge operator is dedicated to the composition of FMs that exhibit similar features (i.e., features with the same name). In this case, the merge operator can be used to merge the overlapping parts of the input FMs and then to obtain a new integrated FM. The merge uses name-based matching: two features match if and only if they have the same name.

The syntax and the semantics of the merge operator relies on the information provided in Table 1 where the properties of the merged feature model are summarized with respect to the sets of configurations of input FMs and the mode (intersection, union, diff). The hierarchy of a merged FM restores as much as possible the parent-child relationships of the input FMs. Algorithms for automatically merging FMs are given and compared in [START_REF] Acher | Composing feature models[END_REF][START_REF] Acher | Comparing approaches to implement feature model composition[END_REF]. We give some implementation details in Section 6.

In FAMILIAR, the merge operators act on a set of FMs and produce FMs with semantics properties according to the mode specified by the programmer. For example, the merge in intersection mode computes a new FM that represents the set of common configurations of the input FMs 5 .

Listing 11 is part of a script that uses the merge operator in intersection mode. In line 5, the merge operator in intersection mode is applied on mi4 and mi5 and produces a new FM that can be manipulated through the variable mi -inter. In line 8, we check that mi -inter is equal to mi -inter -expected. The binary operator eq is specific to variable complex types. In particular, two variables of FM type are equal if i) they represent the same set of configurations, i.e., the compare operator applied to the two variables returns REFACTORING and ii) they have the same hierarchy. In line 9, the merge operator in union mode is applied on mi4 and mi5 and produces a new FM that can be manipulated through the variable mi -union. In lines 10-12, we check the following property:

Mode

Semantics properties Mathematical notation FAMILIAR notation Intersection

F M 1 ∩ F M 2 ∩ . . . F M 1 ⊕ ∩ F M 2 ⊕ ∩ . . . fmr = merge intersection { fm1 ∩ F M n = F M r ⊕ ∩ F M n = F M r fm2 ... fmn} Union F M 1 ∪ F M 2 ∪ . . . F M 1 ⊕ ∪s F M 2 ⊕ ∪s . . . fmr = merge union { fm1 ∪ F M n = F M r ⊕ ∪s F M n = F M r fm2 ... fmn} Diff {x ∈ F M 1 | x F M 2 } F M 1 \ F M 2 = F M r fmr = merge diff { fm1 fm2 } = F M r
| mi4 ∪ mi5 | = | mi4 | + | mi5 | -| mi4 ∩ mi5 | = | mi -union |
using counting operations (i.e., the value of n is equal to | mi -union |).

Aggregating FMs. A second form of composition is the aggregate operator. Contrary to the merge operator, it assumes that separated FMs do not have features with the same name. It also supports cross-tree constraints, written in propositional logics, over the set of features so that separated FMs can be inter-related. The input FMs are aggregated under a synthetic root synthetic so that the root features of input FMs are child-mandatory features of synthetic. In addition, the propositional constraints are added in the resulting FM. For example, the aggregate operator can be used to compose three FMs f m5, f m6 and f m7 together with constraints (see Figure 4).

When FMs are related through constraints, some features may become dead (see Definition 4) or core features (see Definition 5). For example, the feature E is a dead feature in f m8 (see Figure 4), resulting from the aggregation of f m5, f m6 and f m7. FAMILIAR provides two operators to compute the set of core and dead features of an FM (see lines 7-8 of Listing 12).

Definition 4 (Dead features).

A feature f of F M is dead if it cannot be part of any of the valid configurations of F M. The set of dead features of F M is noted deads

(F M) = { f ∈ F | ∀c ∈ F M , f c} Definition 5 (Core features). A feature f of F M is a core feature if it is part of all valid configurations of F M. The set of core features of F M is noted cores(F M) = { f ∈ F | ∀c ∈ F M , f ∈ c}
The presence of dead features is usually considered as an anomaly [START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF] Such "anomalies" can be reported to an FM user. But it would be even better to automatically remove the anomalies. For this purpose, we use the slice operator (see line 11 of Listing 12) and its corrective capabilities [START_REF] Acher | Separation of concerns in feature modeling: Support and applications[END_REF] to i) remove dead features (here: E is removed due to the constraint C ⇒ ¬E) ii) to set the variability information (here: the feature C, originally optional, becomes mandatory due to the constraints). Figure 4 recaps the situation at the end of the script execution.

The simple example shows that the composition of FMs (i.e., f m5, f m6, f m7) can lead to the presence of anomalies and that FAMILIAR operators can be used to automatically detect and remove them. Listing 12: Composition of FMs, anomalies detection and correction

An Illustrative Application: Management of Multiple SPLs

In some SPL environments, support for manipulating multiple SPLs (i.e., a set of SPLs) may be needed [START_REF] Van Ommering | Building product populations with software components[END_REF][START_REF] Van Der Storm | Variability and component composition[END_REF][START_REF] Reiser | Multi-level feature trees: A pragmatic approach to managing highly complex product families[END_REF][START_REF] Hartmann | Supplier independent feature modelling[END_REF][START_REF] Dhungana | Structuring the modeling space and supporting evolution in software product line engineering[END_REF][START_REF] Dhungana | Configuration of multi product lines by bridging heterogeneous variability modeling approaches[END_REF]. Some of these SPLs may be developed and maintained by external vendors or suppliers, and some of them may compete to deliver similar products. For example, in [START_REF] Acher | A Domain-Specific Language for Managing Feature Models[END_REF], we developed a case study in which a family of laptops is constituted of customizable components (chipsets, processors, graphic cards, etc.) provided by competing vendors. In this section we illustrate how FAMILIAR can be used to support the management of multiple SPLs in the medical imaging domain (see also the case study in Section 7).

Motivating Scenario. In the medical imaging domain, several highly customized software services are provided by different suppliers (e.g., researchers or scientific teams). The goal for a medical imaging expert is to assemble these services in a processing chain, called workflow. The tasks of identifying, tailoring and composing these services with their variability become tedious and error-prone. There is thus a strong need to manage the variability so that developers can more easily choose, configure and compose those services. To tackle this problem, our approach is to consider services as SPLs while the entire workflow is then seen as a multiple SPL in which the different service SPLs are composed. An example scenario is presented in Figure 5. The scenario involves three steps.

In the first step the medical imaging expert produces an FM with no assumptions about the services provided by external suppliers -see . A family of workflow is designed for the different processes of the workflow: for example, Intensity Correction, Segmentation, Registration. It corresponds to an aggregation of several FMs, each describing the variability of a process. The next step is to choose which suppliers' services (if any) fulfill the features specified for each process of the workflow. In the scenario, for instance, the need for an external supplier for a Registration medical imaging service is identified. This requirement results in the generation of an FM that represents the offerings of the three suppliers for the Registration (see ). The FM of each supplier's services is built from its services' descriptions. Once the requirements of the medical imaging expert is mapped with the suppliers' offers (see ), reasoning operations can be performed. Among others, the medical imaging expert can use FMs to i) determine whether the set of suppliers is able to provide the entire set of services and to cover all combinations of features or to ii) identify missing services, and to iii) eliminate the suppliers that do not provide the required services.

Building FMs' Repositories. In the script presented in Listing 13, S upplier 1 proposes eight registration services, each one being distinguished from the others by features. (Note that we can use the same name convention for all suppliers since namespaces are used to disambiguate names.) The set of registration services can then be organized We consider that services exhibit no variability: Each registration service description is represented as an FM in which all features are mandatory (see Listing 13). Building an FM from the set of existing services can be done by applying the merge operator in union mode on the set of corresponding FMs (e.g., line 3 in Listing 14). An FM is produced for each supplier (e.g., Regspl -1 FM for S upplier 1 ). Listing 14: Building a repository of FMs with the merge operator A repository of registration services is represented by a set of different FMs (one per supplier). Similarly, other repositories can be built for other kinds of services (intensity correction, segmentation, etc.) and imported in a script (see lines 4-6 in Listing 15). // workflowScenario.fml: implementation of suppliers' scenario run "newworkflow" // new family of workflow firstly designed // load repositories run "repositoryReg" into Reg run "repositorySegm" into Segm run "repositoryIntensity" into intensity Listing 15: Loading the workflow specification (see Figure 5) and the repositories of FM services (part 1 of "work-flowScenario.fml") Mapping Repositories. The FAMILIAR script presented in Listing 16 describes mappings from FMs in repositories to the medical imaging expert's FM. For each part of the family of workflow (specified by the script newworkflow.fml of Figure 5), it is necessary to determine which FMs and suppliers are suitable to provide the given service. Indeed, the family of workflow specifies different alternatives for the choice of a registration service. In order to reason about the registration service of FM work f low, the variability information of the registration service (sub-tree rooted at feature Registration) is first extracted. We use the slice operator to extract the FM, originalReg (line 9 in Listing 16).

Workflow

Repository of Registration Services

Each valid configuration of originalReg should correspond to at least one service provided by a supplier and present in the registration service repository. It may happen that such a property is not respected and two cases have to be considered. First, the intersection between the set of services of originalReg and the set of suppliers' service may be empty (lines [START_REF] Mendonca | Decision-making coordination and efficient reasoning techniques for feature-based configuration[END_REF][START_REF] She | Reverse engineering feature models[END_REF][START_REF] Metzger | Disambiguating the documentation of variability in software product lines: A separation of concerns, formalization and automated analysis[END_REF][START_REF] Dhungana | Structuring the modeling space and supporting evolution in software product line engineering[END_REF][START_REF] Zaid | Feature assembly: A new feature modeling technique[END_REF]. Verifying this property can be done by first performing the merge operations on originalReg, Regspl -1, Regspl -2 and Regspl -3 (line 16). This gives a new FM mi -merged and its satisfiability can then be controlled, i.e., checking whether or not there is at least one valid configuration (lines [START_REF] She | Reverse engineering feature models[END_REF][START_REF] Metzger | Disambiguating the documentation of variability in software product lines: A separation of concerns, formalization and automated analysis[END_REF][START_REF] Dhungana | Structuring the modeling space and supporting evolution in software product line engineering[END_REF][START_REF] Zaid | Feature assembly: A new feature modeling technique[END_REF]. Another possibility is that the family of workflow offers to medical imaging experts some services that cannot be entirely provided by suppliers (lines [START_REF] Hubaux | Separation of concerns in feature diagram languages: A systematic survey[END_REF][START_REF] Hartmann | Using feature diagrams with context variability to model multiple product lines for software supply chains[END_REF][START_REF] Hartmann | Supplier independent feature modelling[END_REF][START_REF] Van Der Storm | Variability and component composition[END_REF][START_REF] Bosch | Toward compositional software product lines[END_REF][START_REF] Tun | Relating requirements and feature configurations: A systematic approach[END_REF]. In this case, originalReg is a generalization or an an arbitrary edit of the union of set of suppliers' services (line 22). Performing a merge diff operation (see Table 1) assists users in understanding which set of services is missing (line [START_REF] Hartmann | Using feature diagrams with context variability to model multiple product lines for software supply chains[END_REF][START_REF] Hartmann | Supplier independent feature modelling[END_REF][START_REF] Van Der Storm | Variability and component composition[END_REF][START_REF] Bosch | Toward compositional software product lines[END_REF]. In other cases, all services of originalReg can be provided by suppliers. For example, the property holds for the FMs depicted in Figure 6: the set of configurations of originalReg is included or equal to the union of set of suppliers' services (we assert this property in line 28).

Selecting Suppliers. At this point, the medical imaging expert needs to determine which suppliers can provide a subset of the services of originalReg. We now consider the lines 29-40 of Listing 17 that implement a solution.

First, some suppliers cannot provide at least one service corresponding to any configuration of originalReg (lines 31-33) and so should not be considered. Figure 6 illustrates the situation: S upplier 3 is no longer available since the intersection between originalReg and Regspl -3 is the empty set. Some suppliers offer services that correspond to a valid configuration of originalReg but also offer out-of scope services. To remove these services, a merge in intersection mode is systematically performed to restrict attention to the set of relevant supplier services (line 31). For example, the feature Multi is no longer included in the set of services of S upplier 1 and S upplier 2 (see Regspl -1 and Regspl -2 in Figure 6) while S upplier 2 is now able to deliver only one service.

At the end of the loop, Reg -suppliers -in corresponds to a set of FMs, where each FM represents a family of services offered by a given supplier. Then some choices can performed in originalReg (e.g., in order to fix a given medical imaging format) and similar sequences of merge operations are executed to update the suppliers offer.

Refactoring and Reusable Scripts. The FAMILIAR script depicted in Listing 15, 16 and 17 can fully realize the scenario of Figure 5. Nevertheless, the script has some limitations.

First, when users select or deselect features, some suppliers may become unable to provide services corresponding to the new requirements. We want to perform validity checks at each step of the configuration process. An approach where sequences of code are copied from above and pasted in again is not desirable. Listing 17: Determining suppliers that provide registration services (part 3 of "workflowScenario.fml") Second, reasoning operations are planned to be performed on each part of the workflow (as done with the registration service). The current script does not allow a programmer to reuse the repetitive tasks performed on FMs, leading again to duplicate code.

Modularization mechanisms provided by FAMILIAR can be applied to raise the limitations mentioned above. In particular, the checking operations (i.e., i) for checking availability of services and ii) for computing available suppliers) can be performed in two parameterized scripts. When performing choices, users can have feedback from available suppliers (even if the set of features is not fully selected or deselected) by calling the two parameterized scripts. Listing 18 illustrates the principle for registration services. For each service of the workflow (e.g., segmentation and intensity correction services), similar checking operations and scripts can be reused.

Environment and Implementation

We provide an Eclipse-based development environment (see Figure 7) for FAMILIAR that is composed of: • an interpreter that executes the various FAMILIAR scripts ;

• an interactive toplevel, connected with graphical editors. Ecosystem. FAMILIAR is developed in Java language using Xtext [START_REF]Xtext[END_REF], a framework for the development of external DSLs. We reuse Xtext facilities to parse FAMILIAR scripts and develop the Eclipse text editor. FAMILIAR is connected with several other languages and frameworks (see Figure 7). Therefore several notations can be used for specifying and serializing FMs (as mentioned in Section 4.2). Some notations (TVL, FaMa) support feature attributes and non-Boolean constructs. As FAMILIAR is restricted to the management of propositional FMs (see Section 3.2), we only consider their Boolean forms. Other notations (SPLOT, FeatureIDE, S 2 T 2 ) are expressively complete with respect to propositional logics. Therefore their semantic domain is the same and there are only syntactical differences. The formats supported by FeatureIDE and S 2 T 2 only allow one feature group per feature whereas FAMILIAR, as SPLOT, supports FMs with several features groups per feature. When exporting an FM to FeatureIDE and S 2 T 2 the kinds of transformations described in [START_REF] Cao | Automating feature-oriented domain analysis[END_REF] are internally applied. They eliminate feature groups that belong to a same parent feature by introducing new intermediate features.

The connection with other languages and frameworks has several benefits. First, the support of different notations encourages interoperability between feature modeling tools. As an FM or a configuration can be exported (using the serialized operation), outputs generated by FAMILIAR can be processed by other third party tools. Specifically, the connection with the FeatureIDE framework [START_REF] Thüm | FeatureIDE: An extensible framework for feature-oriented software development[END_REF] allows us to reuse the graphical editors (for editing and configuring FMs). All graphical edits are synchronized with the content of program variables and all interactive commands are synchronized with the graphical editors. We also developed a bridge with the configurator S 2 T 2 [START_REF]S 2 T 2 configurator[END_REF] that provides interactive visualization mechanisms [START_REF] Pleuss | Integrating automated product derivation and individual user interface design[END_REF].

Perhaps more importantly, the support of different formats allows one to easily reuse state-of-the-art reasoning operations already implemented in existing frameworks. For implementing the compare operator, we reuse an efficient technique to reason about edits described in [START_REF] Thüm | Reasoning about edits to feature models[END_REF] and implemented in FeatureIDE [START_REF] Thüm | FeatureIDE: An extensible framework for feature-oriented software development[END_REF]. The project feature-model-synthesis implements an algorithm to synthesize an FM from a propositional formula. We reuse and adapt some techniques of the algorithm to implement the merge and the slice operators [START_REF] Acher | Slicing feature models[END_REF]. We also reuse some heuristics developed in SPLOT [START_REF] Mendonca | software product lines online tools[END_REF] to compile large FMs into BDDs. More details are given below.

Implementation of Operators. Numerous operators of FAMILIAR manipulate or reason about the set of configurations of FMs. These operations are difficult computational problems (most of them are NP-complete) and require efficient algorithms. We rely on state-of-the-art techniques that consist in encoding an FM as a propositional formula (see Section 2). Constraint Satisfaction Problem (CSP), SAT (for SATisfiability) or Binary Decision Diagrams (BDDs) solvers can then be applied to implement FM operators. In FAMILIAR, two reasoning back-ends are internally used and perform over propositional formulae: SAT solvers (using SAT4J) and BDDs (using JavaBDD) -see Figure 7. Both have strengths and weaknesses when reasoning about FMs (see below for more details).

We extensively reuse the efficient techniques developed in SPLOT and FeatureIDE framework to implement FAMILIAR operators such as isValid, cores, compare, etc. The implementation of the merge and slice operators also relies on satisfiability techniques. A key property of the two operators is that they compute a new propositional formula representing the expected set of configurations (i.e., the projected set of configuration in the case of the slice, and the union, intersection and difference of sets of configurations in the case of the merge). This new formula is then used by other reasoning operators. For example, in lines 2 and 3 of Listing 19, the formula of the merged FM f mR is used to count the number of its configurations or compute its core features. In some cases (e.g., when an FM has to be visualized or serialized), though, we need to construct a complete FM, including its hierarchy, variability information and cross-tree constraints. For example, in line 4 of Listing 19, we need to serialize f mR. The key idea is to synthesis an FM from the propositional formula. Details of the synthesis procedure (e.g., how we select a hierarchy and restitute variability information) are out of the scope of this article and are described in [START_REF] Acher | Separation of concerns in feature modeling: Support and applications[END_REF][START_REF] Acher | Feature Model Differences[END_REF].

FAMILIAR implements a lazy strategy: for all merge and slice operations, we synthesize the FM from the propositional formula only when needs be (e.g., it is the case in line 4 of Listing 19). The lazy strategy is useful since the synthesis procedure extensively relies on satisfiability techniques and is thus costly in time and space (see [START_REF] Czarnecki | Feature diagrams and logics: There and back again[END_REF][START_REF] Acher | Separation of concerns in feature modeling: Support and applications[END_REF][START_REF] She | Reverse engineering feature models[END_REF][START_REF] Andersen | Efficient synthesis of feature models[END_REF][START_REF] Acher | Feature Model Differences[END_REF] for more details).

Reasoning back-end and Performance Analysis. A notable benefit for FAMILIAR users is that they do not have to deal with implementation details. They can directly use operators, thus focusing on domain concepts (FMs, configuration) and avoid accidental complexity. In practice, the order of complexity of FMs publicly available in SPLOT's repository [START_REF] Mendonca | software product lines online tools[END_REF] can be handled without any difficulty with the operators provided in FAMILIAR.

Yet, we chose to provide more control to FAMILIAR users. We indeed observed that the choice of a reasoning back-end can influence the performance of an operator, especially for larger FMs with thousands of features (i.e., randomly generated or the Linux FM). As an extreme case, it can even preclude the use of an operator (e.g., due to an excessive memory usage). FAMILIAR makes possible to choose a SAT or BDD-based implementation (except for the merge operator, see below). Using some annotations (see Listing 20 for an example), FAMILIAR users can fix the choice of a particular reasoning back-end for a given operator; otherwise, reasoning back-ends are chosen by default. Listing 20: Setting the reasoning back-end for particular operations We now discuss empirical results, reported in the literature [START_REF] Thüm | Reasoning about edits to feature models[END_REF][START_REF] Pohl | A performance comparison of contemporary algorithmic approaches for automated analysis operations on feature models[END_REF][START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF][START_REF] Acher | Separation of concerns in feature modeling: Support and applications[END_REF][START_REF] Mendonca | Efficient compilation techniques for large scale feature models[END_REF][START_REF] Trinidad | FAMA framework[END_REF], that can help to efficiently choose such reasoning back-ends for operators of FAMILIAR.

Benavides et al. analyzed the performance of CSP, SAT, and BDD solvers [START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF][START_REF] Benavides | A first step towards a framework for the automated analysis of feature models[END_REF] in checking satisfiability of an FM (corresponding to isValid operator) and counting the number of valid configurations of an FM (corresponding to counting operator). They reported that i) BDDs are faster than SAT solvers for the isValid operator, but with a ten times higher memory usage ; ii) SAT solvers do not scale well when counting an FM whereas BDDs are much faster for the same operation. Pohl et al. [START_REF] Pohl | A performance comparison of contemporary algorithmic approaches for automated analysis operations on feature models[END_REF] present a performance comparison regarding nine contemporary high-performance solvers, three for each base problem structure (BDD, CSP, and SAT). Some operations on 90 FMs from the SPLOT repository [START_REF] Mendonca | software product lines online tools[END_REF] are considered and correspond to the operators isValid, configs and counting of FAMILIAR. The results confirm the findings of Benavides et al. by showing that BDD solvers outperform other solvers on real large FMs. As stated, the results of their study "facilitate the choice of the appropriate solver depending on the size of the models to be analyzed and the intended analysis operation".

The two previous studies only focus on some reasoning operations. Many others are still to be considered and empirically evaluated. Thüm et al. empirically showed that their SAT-based algorithm (reused in FAMILIAR) can efficiently compare FMs with thousands of features [START_REF] Thüm | Reasoning about edits to feature models[END_REF]. To the best of our knowledge, there is no empirical study of a BDD-based implementation of the same operator. Mendonca et al. report that FMs with a number of features up to 2000 cannot be compiled to BDD, even with the use of heuristics [START_REF] Mendonca | Efficient compilation techniques for large scale feature models[END_REF]. Therefore a SAT-based implementation can handle larger FMs than a BDD-based implementation. As future work, we plan to empirically compare the response time of the two reasoning back-ends for this operator.

The memory limit of a BDD-based implementation has also consequences on other operators. For example, it is not possible to use the slice operator with BDDs for FMs with 2000+ features. In [START_REF] Acher | Separation of concerns in feature modeling: Support and applications[END_REF], we developed heuristics for SAT solvers and showed that the slice operator can handle FMs with 10000 features. Finally, the performance of the merge operator is reported in [START_REF] Acher | Separation of concerns in feature modeling: Support and applications[END_REF]. Currently, FAMILIAR only proposes a BDD-based implementation of the merge operator. To the best of our knowledge, there is no existing work proposing the use of SAT solvers for this operator. Hence we cannot compare the two kinds of implementation.

FAMILIAR reuses state-of-the-art reasoning techniques. It allows FM users to efficiently operate over complex FMs with thousands of features. Another benefit of reuse is that the empirical results mentioned above also apply to FAMILIAR operators. We exploit these results to choose default reasoning back-ends (e.g., the choice of BDD for counting and isValid, the choice of SAT solvers for slice and compare). Nevertheless, some choices are still arbitrary for some operators of FAMILIAR. We recognize that an empirical comparison of BDD and SAT-based implementations for each FAMILIAR operator is needed. It would perhaps improve our default choices. For this purpose, existing benchmarks found in the literature have to be extended. We leave it as future work.

Evaluation

We now report on our experience with FAMILIAR in five different case studies. We then discuss key properties of the FAMILIAR DSL.

Case Studies

Table 2 summarizes the different case studies in which FAMILIAR has been involved. We believe the case studies are representative of large-scale management problems: FMs are large (hundreds of features), complex (numerous relationships between the FMs) and multiple. For each case study, we briefly describe the application context (domain and goal), the stakeholders involved, how FAMILIAR has been used, the order of complexity in terms of feature modeling and the benefits observed. In the medical imaging domain, we proposed a comprehensive modeling process and tooling support (including FAMILIAR and a set of domain specific languages) for combining multiple variability artifacts with the purpose of assembling coherent processing chains, called workflows. Separated FMs are used to describe the variability of the different artifacts. At each step of the workflow design, automated reasoning techniques assist medical imaging experts in selecting services from among sets of competing services organized in a repository while guaranteeing that the composition of services does not violate important constraints. Repositories of FMs are built and organized as reusable FAMILIAR scripts. As shown in Section 5, FMs that document variability of services are merged together; querying a repository of FMs is realized using FAMILIAR operators (merge, compare, slice, etc.).

Variability Requirements Specification. FAMILIAR is used to specify variability requirements (e.g., medical image formats, algorithm method, deployment information, etc.) within services of the workflow. More precisely, FAMILIAR is embedded into the DSL Wfamily which enables stakeholders to:

• import FMs from external files while performing some high-level operations (extraction, renaming/removal of features, etc.). For example, the user can load an existing FM from a repository, then extract the sub-parts that are of interest and finally specialize the different FMs ;

• weave FMs to specific places of the workflow ;

• constrain FMs within and across services by specifying propositional constraints. Each FM that have been woven has an unique identifier and can be related to another through cross-tree constraints.

Fully-fledged Workflow Configuration. FAMILIAR code is generated from the workflow analysis and a Wfamily specification, for example, to reason about data compatibility between services. The FAMILIAR code is then interpreted to check the consistency of the whole workflow, to report errors to users as well as to automatically propagate choices. Users can incrementally configure, using graphical facilities provided by FeatureIDE editors, the various FMs of the workflow. Finally, in order to derive a final workflow product, competing services can be chosen from among sets of services in the repository using FAMILIAR reusable scripts. Our first experimental results showed that the overall approach offers an adequate user assistance and degree of automation for managing the large number of features and FMs, thereby decreasing the effort and time needed [START_REF] Acher | Composing Multiple Variability Artifacts to Assemble Coherent Workflows[END_REF].

Modeling Variability From Requirements to Runtime. In the development of video surveillance systems, we observed multiple variability factors, both for i) specifying an application, including the environments and contexts where an application is deployed and run (e.g., lighting conditions, information on the objects to recognize), the quality of service required, etc. ii) describing the software platform, including the number of components, their variations due to choices among possible algorithms, the different ways to assemble them, the number of tunable parameters, etc. We applied the principles of Separation of Concerns and represented the variability of the application requirements and the variability of the software platform as two separated FMs [START_REF] Acher | Modeling Variability from Requirements to Runtime[END_REF]. 77 features and 10 8 configurations were present in the application requirements FM, noted vsar (for Video Surveillance Application Requirements), while 51 features and 10 6 configurations were present in the software platform FM, noted pfc (for PlatForm Configuration). The relationships between the two FMs were described as 39 rules (propositional constraints) relating features across models.

Reachability Property Checking. Before the execution of a system, FMs are used to verify important properties. Among others, one want to guarantee the reachability property, i.e., that for all valid specifications and contexts, there exists at least one valid software configuration. In terms of FMs, the reachability property can be formally expressed as follows:

∀c ∈ vsar , c ∈ Π F vsar (VS f ull ) (1)
where VS f ull is the aggregation of vsar, pfc together with cross model constraints, while F vsar denotes the set of features of vsar. Intuitively, if the projection of the vsar features to VS f ull is equivalent to the original vsar , the constraints map S o f tPL has no effect on the vsar part of VS f ull and thus the reachability property holds. Otherwise some specifications (i.e., configurations of vsar) cannot be reached. The property of Equation 1 can then be implemented with the combined use of A brute force strategy which consists in enumerating all possible specifications and then checking the existence of a software configuration would be clearly inappropriate, especially in our case where we have more than 10 8 valid specifications and more than 10 6 software configurations. The combined use of slice and compare are a much more scalable technique. As exposed in Section 6, slice and compare operate over a propositional formula and can scale for very large FMs. Without these capabilities, this kind of reasoning would not be made possible for the order of complexity encountered in this case study.

Step-wise Specialization and Choices Propagation. In line with specific requirements and deployment scenarios, the video surveillance expert step-wise specialized vsar by removing some features, by modifying some feature groups, etc. After the specialization of vsar, automated techniques were used to update the software platform FM. To do so, the specialized vsar FM and the software platform FM together with rules were aggregated. Finally, we used the slice operator on the aggregated FM, only including the set of features related to the software platform.

We observed that from a specification of a context, the possible configurations in the software platform can be highly reduced. We applied the techniques on six different scenarios: the average number of features to consider in the software platform FM was less than 10 4 (instead of 10 6 configurations). In the six scenarios, we reused i) the FMs and the constraints and ii) automated procedures to control the specialization process and reduce the variability in the software part.

Management of Product Line Variability and Software Variability. In SPL engineering, two concerns of variability are usually distinguished [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF][START_REF] Metzger | Disambiguating the documentation of variability in software product lines: A separation of concerns, formalization and automated analysis[END_REF]: software variability, related to technical details and hidden from customers (also called internal variability), as opposed to product line (PL) variability, proposing a set of products that are visible to them (also called external variability). In [START_REF] Metzger | Disambiguating the documentation of variability in software product lines: A separation of concerns, formalization and automated analysis[END_REF], Metzger et al. proposed a formal and concise approach for separating PL variability and software variability and enabling automatic analysis. The two concerns are modeled as two FMs and inter-related by constraints. The authors mention several properties that should be checked when reasoning about the two kinds of variability.

The operators provided in FAMILIAR can be combined to support separation of concerns in this context and to reason about the two kinds of variability. Let f m PL be the FM documenting the PL variability, f m so f tware be the FM documenting the software variability and map S o f tPL be the constraints relating the two FMs.

Realized-by Property Checking. An important property of an SPL is realizability, that is, whether the set of products that the PL management decides to offer is fully covered by the set of products that the software platform allows for building. In terms of feature modeling, we want to ensure that for each valid selection/deselection of features of f m PL performed by a customer, there exists at least one corresponding software product described by f m so f tware . The realized-by property is similar to the reachability property described above: aggregate, slice, compare and merge operators in diff and intersection modes can be used to automatically check this property. The FAMILIAR scripts developed in the context of video surveillance systems have been reused. Usefulness Property Checking. Another important property is to determine whether a product is useful (i.e., if it is a possible realization of a PL member). As argued in [START_REF] Metzger | Disambiguating the documentation of variability in software product lines: A separation of concerns, formalization and automated analysis[END_REF], the list of non-useful products is a symptom of unused flexibility of the software platform. The usefulness property can be seen as the "symmetric" of the realized-by property: FAMILIAR parameterized scripts are called and reused.

Evolving the FMs. In some circumstances, the realized-by or/and usefulness property may not hold. It can be on purpose, for example, justified by future marketing extensions. It can also be an unexpected property, (i.e., an error). FAMILIAR scripts are used to assist stakeholders in detecting the error and identifying the missing configurations in f m PL or/and f m so f tware .

For this purpose, the differencing operators, formally presented in [START_REF] Acher | Feature Model Differences[END_REF] and integrated (see [START_REF]Differencing techniques for feature models in familiar[END_REF] for more details) into FAMILIAR, are used. Based on differencing information, stakeholders can correct f m PL , f m so f tware or the mapping between the two FMs (map S o f tPL ) and reiterate the process until the expected properties hold. The corrective instructions consist in reusing FAMILIAR facilities to edit FMs while checking operations can be performed afterwards. In this case, the FAMILIAR language offers a comprehensive solution to manage PL and software variability, including their specifications, their checking and their evolutions.

On Scalability. We revisited the approach defended in [START_REF] Metzger | Disambiguating the documentation of variability in software product lines: A separation of concerns, formalization and automated analysis[END_REF]. We applied the techniques using the larger example described in the reference. We successfully retrieved the same results, but our approach is more efficient since we do not enumerate configurations/products. Hence, for larger FMs, the use of our proposed techniques are mandatory since without them the checking of some important properties (e.g., realizability) would not be possible.

Reverse Engineering Architectural Feature Models. FAMILIAR was evaluated when applied to FraSCAti [START_REF] Seinturier | A component-based middleware platform for reconfigurable service-oriented architectures[END_REF], a large and highly configurable component and plugin-based system. The goal was to reverse engineer a variability model of the FraSCAti architecture, i.e., obtain a software architecture FM.

The idea was that the software architecture FM, noted F M Arch 150 , originally produced by an extraction procedure, represents only an over approximation in terms of sets of valid configurations. Hence several sources of information, namely software architecture (F M Arch 150 ), plugin dependencies (F M Plug ) and the correspondences between software elements and plugins, were combined using the aggregate operator. Intuitively, the presence of constraints in the aggregated FM reduces the legal combinations of F M Arch 150 's features. This is the role of the slice operator to compute the projection corresponding to the software architecture part of the aggregated FM. Figure 8 illustrates the process using a simplified example. The FAMILIAR script presented in Listing 22 implements a solution. The aggregated FM resulting from the combination of different variability sources and the bidirectional mapping contains 92 features and 158 cross-tree constraints. The slicing technique significantly reduced the over approximation of the original architectural FM (from ≈ 10 11 to ≈ 10 6 ) so that we obtained a more accurate variability representation of the architecture.

Step-wise Refinement. The architectural FM resulting from the automatic extraction was compared with another architectural FM, this time manually designed by the software architect (SA) of FraSCAti. Unfortunately, the direct comparison yielded to unexploitable results, mainly due to the difference of granularity (i.e., some features in one FM are not present in the other). Basic manual edits of FMs were unpractical and the slice operator was extensively applied as we needed to safely remove features involved in several constraints or that were in the middle of the hierarchy. Once the two FMs have been reconciled, they were compared and differences were identified (e.g., using the merge operator in diff mode or the compare operator). This encouraged the SA to correct his initial model and the architectural FM produced by the automatic procedure [START_REF] Acher | Reverse engineering architectural feature models[END_REF]. FAMILIAR is now used to manage the development and releases of FraSCAti (see http://frascati.ow2.org/doc/1.4/ch12.html).

From Product Descriptions to Feature Models. The task of manually building FMs may prove very arduous for practitionners, especially when they have to collect and model them from such inputs as unstructured product descriptions, tabular data or product matrices [START_REF] Lora-Michiels | A method based on association rules to construct product line models[END_REF][START_REF] Haslinger | Reverse engineering feature models from programs' feature sets[END_REF][START_REF] Alves | An exploratory study of information retrieval techniques in domain analysis[END_REF][START_REF] Ryssel | Extraction of feature models from formal contexts[END_REF][START_REF] Dumitru | On-demand feature recommendations derived from mining public product descriptions[END_REF]. In [START_REF] Acher | On extracting feature models from product descriptions[END_REF] we proposed to semi-automatically extract FMs from several tabular data files documenting a set of products. First, practitionners can specify directives (variability interpretation, hierarchical representation, etc.) to build as much FMs as there are products. Second, the FMs of the products are merged, producing a new FM that compactly represents valid combinations of features supported by the set of products. It is similar to the building of FM services' repository (see Section 5). To realize the extraction process, FAMILIAR instructions are generated:

• insert, aggregate and editing operators are used to build FMs corresponding to products ;

• merge in union mode is applied.

We applied the extraction procedure on public data, involving hundreds of features per FMs and dozens of FMs [START_REF] Acher | On extracting feature models from product descriptions[END_REF]. FAMILIAR plays a key role and fully automates the synthesis of an FM from the composition of smaller ones.

Discussions

We can observe that FAMILIAR has been used in different application domains (medical imaging, video surveillance), for different purposes (scientific workflow design, variability modeling from requirements to runtime, reverse engineering FMs) and by different kinds of stakeholders (e.g., domain experts, software engineer). In the different case studies, the main benefits are an adequate and scalable support for separation of concerns and automated reasoningtwo important properties identified in Section 3.

Separation of Concerns (SoC). In the five case studies, support for SoC is clearly needed and can be justified by two phenomena. Firstly, the FMs may be originally separated: It is the case when one describes the variability of services that are by nature modular entities or when independent suppliers describe the variability of their different products (see case study ). It is also the case when two FMs need to be integrated or reconciled (see case study ). Finally, in case study , several FMs are grouped together. As a result, the composition operators merge and aggregate were extensively used in all case studies.

Secondly, it can be the intention of an SPL practitioner to modularize the variability description of the system according to different criteria or concerns. It is the case when separating the requirements variability from the software variability (see case study ), when PL variability is distinguished from software variability (see case study ): Stakeholders can focus on their know-how while co-evolution and maintenance of the two FMs are facilitated. In these cases, the decomposition operator (slice) and differencing techniques (e.g., compare, merge in diff mode) were required.

Furthermore, the modular mechanisms of FAMILIAR allow an FM user to reuse FMs and reasoning procedures. In the case study , vsar and pfc have been reused in the six deployment scenarios as well as parameterized scripts to control the realizability property. In the case study , the catalog of FMs has been reused to configure different workflows. In the case study , the PL and software variability can be incrementally managed: edits to the two FMs are applied while reasoning operations can be repeated. Automated Reasoning. For most of the management activities used in the case studies, a manual intervention is both error-prone, labor-intensive and time-consuming. In practice, there are hundreds of features whose legal combinations are governed by many and often complex rules. This complexity has already been observed on a scale of one FM in the literature, but it becomes even more complex with multiple FMs, like in the case studies. It is thus of crucial importance to be able to automate the decision making process as much as possible. Another important aspect is the ability of techniques to reason about FMs. As previously shown, FAMILIAR does provide a set of automated reasoning techniques (operators) that can scale for large FMs and a large number of constraints. In particular, the FMs involved in the case studies can be efficiently handled.

In all case studies, large-scale management is needed. FM users have to combine numerous operators, perform sequences of composition and decomposition on several FMs, while reasoning about intermediate results. The FAMILIAR language brings such capabilities to the FM users. Without these new capabilities, some analysis and reasoning operations would not be made possible, for example, in the case study where an enumerative technique is not adequate.

Conclusion

As variability modeling is a key activity in a growing number of software engineering contexts, techniques and support to manage the complexity of larger variability models (i.e., feature models) are needed. In this article, we introduced FAMILIAR, a textual and executable domain-specific language that provides a practical support for managing feature models. We gave an overview of syntactic facilities, modular mechanisms, as well as operators provided in FAMILIAR so that feature model users can import, export, edit, configure, compose, decompose, configure and reason about feature models. We illustrated how a repository of medical imaging services can be practically managed using both reusable scripts and automated reasoning techniques provided by FAMILIAR. We also reported on various applications of FAMILIAR in different domains (medical imaging, video surveillance) and for different purposes (scientific workflow design, variability modeling from requirements to runtime, reverse engineering), demonstrating its applicability. The FAMILIAR constructs enable feature model users to realize complex variability management tasks as needed in the different case studies. Besides some of the FAMILIAR capabilities turn out to be mandatory at a large scale since without the language some analysis and reasoning operations would not be made possible in the different applications.

As future work, we plan to evaluate the FAMILIAR language from a user perspective. The different qualities of a domain-specific language, such as learnability, expressiveness, and usability, are likely to be considered. We hope to conduct the experiments in various settings, i.e., in industrial and academic contexts, in different application domains, and with various kinds of participants having different degrees of expertise. We will also investigate how FAMILIAR can be combined with other tools to manage both feature models and associated artefacts (e.g., source code, design models).

  FODA-like representation f m0 = { {MI, MA, MRI, T 1}, {MI, MA, MRI, T 2}, {MI, MA, MRI, T 1, T 2}, {MI, MA, CT }, {MI, MA, CT, AN}, } (b) set of configurations

Figure 1 :

 1 Figure 1: FM, set of configurations and propositional logic encoding (MI: Medical Image, MA: Modality Acquisition, AN: Anonymized)

  mi1 = FM ( MedicalImage: Modality Format Anatomy [Anonymized]; Modality: (PET | CT); Format: (DICOM|Nifti); Anatomy: Brain;) mi2 = FM ( MedicalImage: Modality Format Anatomy [Anonymized]; Modality: (PET | CT); Format: (DICOM|Nifti); Anatomy: Brain;) b1 = mi1 eq mi2 // b1 is true b2 = mi1 == mi2 // b2 is false str = "PET" // str records the value "PET" fmSet = { mi1 mi2 } // fmSet records a reference to a set n = counting mi1 // n is an integer mi3 = FM ( MedicalImage: Modality Format Anatomy Anonymized; Modality: (MRI | CT); Format: Analyze; Anatomy: Kidney;) f1 = parent MRI // f1 refers to feature named 'Modality' in mi3 f2 = root mi3 // f2 refers to feature named 'MedicalImage' in mi3 s1 = name f2 // s1 is a string "MedicalImage" fs = children f1 // set of features named 'MRI' and 'CT' in mi3 nfs = size fs // 2 oldFeature = parent Analyze // 'Format' feature of mi3 oldFeatureBis = parent mi3.Analyze // 'Format' feature of mi3 conflictingFeature = parent DICOM // feature present in mi1 and mi2

  children mi1.Modality // explicit notation needed mi2.MedicalImage // MedicalImage exists also in mi1 and mi3 parent MRI // non ambiguous: equivalent to mi3.MRI Listing 3: Namespaces and encapsulation

/

  / fooParameterizedScript.fml: a parameterized script parameter fmA : FeatureModel parameter fmB : FeatureModel // type specification is optional c1 = cores fmA c2 = cores fmB //... Listing 5: A parameterized script 4.1.

  newMI = FM (MedicalImage: Anatomy [Header]; Anatomy: (Brain|n256);) newMI2 = copy newMI setMandatory newMI2.Header // editing facilities: Header is now a... //... mandatory feature in newMI2 run "fooParameterizedScript" { newMI newMI2 } Listing 6: Calling a parameterized script

  fm0 = FM (MedicalImage : ModalityAcquisition [Anonymized] ; ModalityAcquisition : (MRI|CT); // Xor-group MRI : (T1|T2)+ ; // Or-group MRI excludes Anonymized ; // constraint ) sfm0 = configs fm0 // set of configurations fm0tvl = FM ("fm0.tvl") // TVL notation fm0m = FM ("fm0.m") // FeatureIDE notation serialize fm0 into SPLOT // export in SPLOT notation Listing 7: Importing and exporting FMs

  conf1 = configuration mi1 // create a configuration of mi1 b1 = select Anonymized in conf1 // feature Anonymized is selected b2 = deselect Anonymized in conf1 // override the previous selection b3 = unselect Anonymized in conf1 // neither selected nor deselected Listing 8: Configuration facilities 4.2.3. Reasoning about FMs and Configurations

  b1 = isValid conf1 b2 = isComplete conf1 b3 = isValid mi1 cmp = compare mi1 mi2 // refactoring Listing 9: Some operators for reasoning about configurations and FMs

  f m2Extract, basic extraction

Figure 2 :

 2 Figure 2: FM to be decomposed and naive decomposition (extract)

Figure 3 :

 3 Figure 3: Examples of slice operation applied on the FM of Figure 2a.

  mi4 = FM ( MedicalImage: Modality Format Anatomy [Anonymized]; Modality: (v10.1|v10) ; Format: (NiftiII|Analyze) ; Anatomy: Brain;) mi5 = FM ( MedicalImage: Modality Format Anatomy [Header]; Modality: (v10.1|v10|v9) ; Format: NiftiII ; Anatomy: (Kidney|Brain);) mi_inter = merge intersection { mi4 mi5 } mi_inter_expected = FM ( MedicalImage: Modality Format Anatomy ; Modality: (v10.1|v10) ; Format: NiftiII ; Anatomy: Brain ;) assert (mi_inter eq mi_inter_expected) mi_union = merge union { mi4 mi5 } n_union = counting mi_union // number of valid configurations n_expected = counting mi4 + counting mi5 -counting mi_inter assert (n_union eq n_expected) Listing 11: Merge operator in union and intersection mode

  fm5 = FM (A : B [C] [D] ; D : (E|F); C excludes E; ) // E, F: Xor fm6 = FM (I : J [K] L ; ) // K is optional fm7 = FM (M : (N|O|P)+ ; ) // M, N, O, P form an Or-group cst = constraints (J implies C ; ) fm8 = aggregate fm* withMapping cst // recall: fm* is equivalent to { fm5 fm6 fm7 } dfm8 = deads fm8 cfm8 = cores fm8 // simplify fm8 (e.g., by removing dead features) fm9 = slice fm8 including fm8.* op = operator fm9.F assert (op eq mand) // E is mandatory and no longer in an Xor-group // renaming of the root feature rfm9 = root fm9 renameFeature rfm9 as "MySPL"

Figure 4 :

 4 Figure 4: The two FMs f m8 and f m9 at the end of FAMILIAR script execution (see Listing 12)

Figure 5 :

 5 Figure 5: Managing Multiple SPLs

/

  / RegSupplier_1.fml: registr. services' specification of Supplier_1 Regservice1 = FM ( Reg: Modality Format Anatomy ; Modality: MRI ; ..) Regservice2 = FM ( Reg: Modality Format Anatomy ; Modality: CT ; ..) //... Regservice8 = FM ( Reg: Modality Format Anatomy Anonymized ; Modality: CT ; ..) Listing 13: Descriptions of registration services

/

  / repositoryReg.fml: repository of registration services run "RegSupplier_1" into Regsupp1 Regspl_1 = merge union Regsupp1.* run "RegSupplier_2" into Regsupp2 Regspl_2 = merge union Regsupp2.* run "RegSupplier_3" into Regsupp3 Regspl_3 = merge union Regsupp3.* renameFeature Regspl_1.MIFormat as "Format" // aligning terms export Regspl_* // export the three suppliers' FMs/SPLs

/

  / we map the FM Reg (workflow) with the FM registration repository allServicesReg = merge union Reg.* // Regspl_1, Regspl_2, Regspl_3 originalReg = slice workflow.Registration* // semantical "extraction" // alignment: renaming terms to be coherent with the repository renameFeature originalReg.MIFormat as "Format" renameFeature originalReg.Registration as "Reg" //... /***** checking the availability of services *****/ mi_merged = merge intersection { originalReg allServicesReg } if (not (isValid mi_merged)) then print "No service can be provided" exit // stop the program end cmp_mi = (compare originalReg allServicesReg) if (cmp_mi eq GENERALIZATION || cmp_mi eq ARBITRARY) then mi_losed = merge diff { originalReg allServicesReg } // missing s_losed = configs mi_losed // set of configurations of mi_losed n_losed = counting mi_losed // number of configurations println n_losed " service(s) cannot be provided: " s_losed end assert (cmp_mi eq REFACTORING || cmp_mi eq SPECIALIZATION) Listing 16: Checking availability of registration services (part 2 of "workflowScenario.fml")

Figure 6 :

 6 Figure 6: Available suppliers and services

/

  / workflowScenario2.fml // originalReg, allServicesReg and Reg are loaded as // previously illustrated with workflowScenario.fml run "checkAvailability" { originalReg allServicesReg } into mi_availability if (mi_availability.available) then run "availableSuppliers" { Reg.* originalReg } into mi_suppliers end Listing 18: Refactoring of "workflowScenario.fml": modularizing the code • an Eclipse text editor (including syntax highlighting, formatting, code-completion, etc.) ;

Figure 7 :

 7 Figure 7: FAMILIAR: ecosystem and environment

  fmR = merge intersection { fmA fmB fmC } // formula is computed nR = counting fmR // propositional formula is used cR = cores fmR // propositional formula is used serialize fmR into SPLOT // synthesis of FM is needed Listing 19: Propositional formula and lazy synthesis

1

  counting @backend=SAT fm1 // SAT solvers are used 2 counting fm1 // BDDs are used (default)

Figure 8 :

 8 Figure 8: Enforcing an FM using aggregate and slice

Table 1 :

 1 Merge: semantics properties and notation

Registration Brain Kidney Anatomy MIFormat Segmentation 2 3 Intensity Correction Mapping and Selection Design of a new workflow family 1 // newworkflow.fml: a new workflow family

								workflow = FM ( Workflow: IntensityCorrection
										Segmentation [Registration] ; ... ; ... ;
											... ;
											... ; ... ;
											... ; )
								export workflow
	Regspl_3	Reg			Regspl_2	Reg			Regspl_1	Reg
	Modality	Format	Anatomy	Vertex	Modality	Format Anatomy	Header	Modality	MIFormat Anatomy	Header
	MRI	PET	Nifti	Brain Kidney		CT	MRI	Nifti DICOM Brain	CT	MRI	Nifti	Analyze Kidney
			Supplier 3					Supplier 2				Supplier 1
			Services					Services				Services

Table 2 :

 2 Case studies and FAMILIARComposing Multiple Variability Artifacts to Assemble Coherent Workflows.

  slice, aggregate and compare operators. More precisely, Equation 1 implies to check if vsar is a refactoring of Π F vsar (VS f ull ). The checking can be realized with a few lines of FAMILIAR (seeListing 21).

	// reachability property
	VSFull = aggregate { VSARfm PFCfm } withMapping prules
	VSARfm2 = slice VSFull including VSFull.VSApplicationRequirement*
	if (compare VSARfm2 VSARfm eq SPECIALIZATION) then
	println "For some specifications, no software configuration..."
	// differencing techniques
	// ...
	else
	println "Reachability property holds."

end Listing 21: Checking reachability: for all valid configurations of VSARfm, there exists at least one valid configuration in PFCfm.

The external/internal dichotomy is generally used to characterize DSLs. An external DSL is a completely separate language and has its own custom syntax. An internal DSL is more or less a set of APIs written on top of a host language (e.g., Java). Internal DSL is limited to the syntax and structure of its host language. Both internal and external DSLs have strengths and weaknesses (learning curve, cost of building, programmer familiarity, communication with domain experts, mixing in the host language, strong expressiveness boundary, etc.)[START_REF] Fowler | Domain Specific Languages[END_REF]

The comparison of the compositional mechanisms offered by the VELVET language and the composition operators developed in[32,

[START_REF] Acher | Separation of concerns in feature modeling: Support and applications[END_REF] is out of the scope of this article.

Details about interoperability between notations and implementation of import/export mechanisms are given in Section 6.

Despite its limitations, the operator is still part of the language since we consider that such a syntactical manipulation may be useful in some circumstances.

The merge in intersection and diff mode can be arguably seen as decomposition operators since the resulting FM is typically smaller than the input FMs. Nevertheless, we prefer to use the term "composition" to reflect the idea of combining different models together.

Acknowledgments

Dr. Acher's work was partially funded by the FP7 Marie-Curie COFUND program. The authors thank Foudil Bendjabeur and Aleksandar Jaksić for their work with FAMILIAR.