Simon Urli
email: urli@i3s.unice.fr

Mireille Blay-Fornarino

Philippe Collet
email: collet@i3s.unice.fr

Sébastien Mosser
email: sebastien.mosser@sintef.no

Using Composite Feature Models to Support Agile Software Product Line Evolution

Keywords: Software product line, Agile, Evolution, Feature model

Managing continuous change in a Software Product Line (SPL) is one of the challenges now faced by the SPL engineering community. On the one hand, the SPL paradigm captures the intrinsic variability of a software based on a systemic vision of the software to model. On the other hand, Agile Software Development advocates the incremental development of software based on constant interaction with a customer community. In this paper, we present an approach based on Composite Feature Models (CFM) to support the agile evolution of a SPL. This study is driven by the refactoring of a daily used application (information broadcasting system), in the context of a nationally funded project. Preliminary results show that CFMs support the incremental development of a SPL based on interactions with a community, tackling the challenge of SPL continuous evolution.

INTRODUCTION

In many domains software maintenance and evolution lead to abstract the domain concepts in a model-driven engineering process while supporting variability and extension points. The latter corresponds to the application of the Software Product Line (SPL) paradigm, which consists in systematically reusing development assets in an application domain [START_REF] Clements | Software Product Lines : Practices and Patterns[END_REF], reducing time-to-market and improving quality.

Still willing to improve software development efficiency, Agile Software Development (ASD) advocates the incremental development of a software based on constant interaction with a customer community [START_REF] Fowler | The agile manifesto[END_REF]. Contrary to SPL techniques, in ASD the focus is neither on scoping, predictability nor reuse. ASD primarily aims at addressing the immedi-ate customer demands with development efforts at a smaller scale. While both approaches aim at handling variability, they are not built to be directly used together, even if some studies have been already conducted [START_REF] Carbon | Integrating Product Line Engineering and Agile Methods : Flexible Design Up-Front vs. Incremental Design[END_REF][START_REF] Geir | Process Fusion: An Industrial Case study on Agile Software Product Line Engineering[END_REF][START_REF] Ghanam | Extreme Product Line Engineering -Refactoring for Variability : A Test-Driven Approach[END_REF].

Nowadays software-intensive systems are built in a day-today manner through communities that follow the rules of an architectural framework, similar to a SPL. A crucial issue is then to evolve towards a community-driven SPL, following agile principles. The community would constantly provide new requirements and change requests, while the reasoning and generative capabilities provided by the SPL framework should be preserved or adapted accordingly, following agile principles. Based on our current experience on the reengineering as a SPL of a concrete and daily used application, an information broadcasting system, we propose in this paper an approach to support the agile evolution of an SPL.

After discussing the current state of the art on agile SPL evolution (see Section 2), we introduce our case study and discuss issues related to its reengineering as a SPL (see Section 2). We show that current variability modeling techniques are not powerful enough to handle the faced problems. We discuss how the evolution of domain objects can be managed by introducing an extension of feature models [START_REF] Kang | Feature-Oriented Domain Analysis (FODA)[END_REF], (a widely used formalism for variability modeling), called Composite Feature Models (CFM, see Section 4). To manage dependencies between these evolving objects, we describe a model-driven configuration process (see Section 5). We then conclude by discussing remaining difficulties in our proposal and by evoking future work (see Section 6).

ON AGILE SPL EVOLUTION

The SPL paradigm models the intrinsic variability of a family of software systems based on a systemic vision of the software to model. It usually relies on reusable artifacts that encapsulate both common and variable aspects so as to facilitate planned and systematic reuse [START_REF] Clements | Software Product Lines : Practices and Patterns[END_REF]. An SPL is by nature scoped, i.e., it handles changes inside the software family by configuration, providing a tailored product. This means that all the changes are known in advance and captured in some variability models, such as Feature Models (FM) [START_REF] Kang | Feature-Oriented Domain Analysis (FODA)[END_REF]. Evolving an SPL out of its original scope is therefore a challenging activity, as it breaks the closed world assumption. Some recent work focuses on providing safe evolution principles for SPLs [START_REF] Neves | Investigating the Safe Evolution of Software Product Lines[END_REF], but are restricted to change patterns that follow a refinement notion. At the FM level, we observe the application of classic software engineering approaches: reasoning on FM edits [START_REF] Thüm | Reasoning about Edits to Feature Models[END_REF], providing some consistency notions when FM evolves [START_REF] Guo | Towards Consistent Evolution of Feature Models[END_REF] or semantically differentiating FMs [START_REF] Acher | Feature Model Differences[END_REF]. But in many domains now, several factors raise the stakes on the SPL engineering techniques and call for appropriate evolution management techniques: third party components are used, software ecosystems are moving to open-source and community-based management, thus continuous requirement changes must be handled [START_REF] Bosch | Toward Compositional Software Product Lines[END_REF]. In this context, managing continuous change in an SPL becomes a crucial challenge, to which agility provides answers [START_REF] Fowler | The agile manifesto[END_REF].

The interactions between SPL engineering and agility has been studied according to several viewpoints. The usage of agile techniques when tailoring a product within the fixed scope of a SPL was investigated in [START_REF] Carbon | Integrating Product Line Engineering and Agile Methods : Flexible Design Up-Front vs. Incremental Design[END_REF]. Different industrial studies show some complementarity in the planning, with long-term strategy devoted to SPL management and shortterm tactical decisions with agile principles [START_REF] Geir | Process Fusion: An Industrial Case study on Agile Software Product Line Engineering[END_REF], as well as some need to change team organisation according to the compositional form of today SPLs [START_REF] Bosch | Toward Compositional Software Product Lines[END_REF]. Besides a test-driven approach is also proposed in [START_REF] Ghanam | Extreme Product Line Engineering -Refactoring for Variability : A Test-Driven Approach[END_REF], where the variability is incrementally introduced into software by refactoring existing code in a agile way.

To the best of our knowledge, no approach has been provided to handle the evolution of a SPL (especially communitydriven), following agile principles. We advocate that this problem can be tackled by managing the evolution of several notions and software artifacts. First, as the domain is constantly evolving, the evolution management of domain objects must be handled, taking into account the complexity of both the objects and their variability models. Second, dependencies between these domain objects must be handled, facilitating both the direct usage of simple users of the SPL, and the long-term management of the SPL by their architects.

FROM JSEDUITE TO YOURCAST

This section presents our case study, the re-engineering of a broadcasting system as a SPL.

JSeduite : the legacy system

The development of the jSeduite1 system started in 2004. Used to broadcast information in academic institutions, the system is connected to academic partners (e.g., transportation network, cafeterias) that act as sources of information. This information is then dispatched to multiple devices (e.g., public screens, smartphones) that render it. The system is implemented as a Service-Oriented Architecture (SOA), and has been recognized as a prototypical usage of SOA [START_REF] Mosser | From Aspect-oriented Requirements Models to Aspect-oriented Business Process Design Models[END_REF], used as a validation case study in the Faros national project. The final version of jSeduite was released in 2010, and counts circa 70,000 lines of code. This system is today used in several french campuses.

Two kinds of persons interact with jSeduite. On the one hand, final users (e.g., students, lecturers) see the broadcast-ing devices. They express their needs in terms of information delivery (i.e., a "product configuration" according to the SPL terminology) using their own vocabulary, e.g., "I want to display the timetable and the news from the University on cafeteria's screens". On the other hand, developers work at the code level to implement web services (e.g., timetable provider, news feed reader) and business processes orchestrating these services to support information broadcasting (e.g., aggregating the two services to merge their information streams). Developers also interact with the code of the display client, customizing it to their institution (e.g., logo, color codes, layout).

One of the interesting dimension of jSeduite is that the system federates a community of users and developers. The system was started as an engineering school project, and was quickly enriched through student initiatives, adding new sources of information to the system. Several broadcasting policies were empirically identified to manage the growing set of available information on the screens (e.g., restricting to the latest ones, prioritizing certain kinds of information during breaks). Two institutions dedicated to visually impaired children are involved in this community, which triggers new challenges in the way information is rendered through the GUI (e.g., text-to-speech, dedicated fonts and color codes).

YourCast: toward an agile SPL

The jSeduite system suffered from several issues. First, it was originally targeting small institutions. Thus, we encountered scalability problems while deploying a jSeduite instance on large institutions (e.g., multiplicity of users, variability of devices). The second issue is triggered by the richness of the source set and their associated parameters, which make it difficult to customize as is. Empirically, we identified that the customization of a jSeduite instance by an end user is tedious and error-prone.

The YourCast project2 aims to address these two issues, using a SPL approach to support end-users. An end-user wishing to have a broadcasting system selects the wanted features, and the YourCast engine generates the final product based on this selection. This is directly related to the first agile principle: "satisfy the customer " [12, principle 1]. Moreover this SPL should evolve to include the contributions of a community of developers, creating new pieces of software, or modifying them to enrich and maintain the product family. We can make a parallel here with two other agile principles: the need to "embrace change" and to "give frequent deliveries" [12, principles 2 and 3]. Each contribution of the community to evolve the SPL comes from a change and must give at least a new usable delivery of the system.

We distinguish two groups of stakeholders: (i) users of the SPL itself that create a Broadcasting System (BS) by selection and then generate it. We call them BS-User; (ii) developers who enrich the SPL. They form a community and we note them BS-Dev.

From the perspective of a BS-User, we identified the following concepts: a BS is composed of a set of sources, each one being formatted to their liking to be displayed (renderer ) in a layout. Before it can be processed by one policy or more The arrows and the cardinalities in bold represent the requirements to make a valid broadcasting system (e.g., "at least one source"). The other lines and cardinalities represent dependencies between concepts (e.g., "a source need to be connected with exactly one renderer").

The purpose of a BS-User is to create a BS that is aligned with her information system and the sources she finds on the web, while benefiting from a display in adequacy with her context of use, e.g., graphic standard, type of population (e.g., young, disabled, corporate), or field conditions. Goals of developers (BS-Dev) are multiple, e.g., to add or adapt sources, create its own renderers, offer new layouts. These developments are driven by the consideration of technological changes and by needs from the field experiments.

EVOLUTION OF DOMAIN OBJECTS

The evolution of the Web 2.0 increases the possible sources of information (e.g., RSS feeds, user-driven news channels) by the publication of shared or legacy services. This evolution translates into a reduced time-to-market for new business solutions. The YourCast SPL must in turn support this evolution by demonstrating its ability to absorb evolving requirements and priorities.

Requirements

R1: Reactivity to domain evolution. Broadcasting systems embrace different sub-domains (e.g., sources, visualization technique, display, policies) that are in constant evolution. Our developer community aims to integrate these new domain objects in existing or new broadcasting systems. Yourcast must support the integration of these various domain objects. For example, if a new service to share pictures is widely used, a BS-Dev might decide to implement software assets to use it in a broadcasting system. These assets have to be reified in the SPL.

R2: Reactivity to domain objects evolution. Adding new domain object is not sufficient to support the evolution of the SPL. Services on the web are constantly evolving: APIs are changing and new features appear. The BS-Dev have to modify the SPL, reifying the changes. For example, the previously defined service offers now the capacity to manage secured picture albums, and a BS-Dev adds this feature in the SPL.

R3: Human understability. For a simple broadcasting system, we need to use many concepts. Each concept has com-mon and variant parts that represent the different domain objects available. But even the domain objects have their own variability that has to be represented. For example, a source like Picasa must be represented with all the relevant ways to use it: it is possible (the list is not exhaustive) to use the service as a search engine, or to get a precise picture album, to sort pictures by date or by alphabetic order. That means a simple domain object could be represented by a large FM reflecting what the BS-User wants to manipulate (e.g., the Picasa source corresponds to 18 features in the running system). In the end, getting the variability of all the domain objects quickly leads us to a very complex FM. So BS-Dev need some ways to manage that complexity. In our example, 7 domain object sources correspond to 27 features and 36 valid configurations, 35 domain object renderers correspond to more than 50 features.

R4: User-driven vocabulary. The last need concerns the vocabulary employed in the SPL. Empirically, the introduction of objects in the SPL requires to characterize the domain objects in terms faimiar to the BS-User. This step is difficult. Therefore it is necessary to support vocabulary changes in the SPL itself following the experiments. For example, the "screen name" term comes from Twitter API and is used to filter information (thus modeled as a feature). But it is not as clear as "pseudonym" to a user who does not know the Twitter API.

Solution: Composite Feature Models

This section describes the solution defined in the context of the YourCast national project to address these requirements. This solution is based on the definition of Composite Feature Models, according to the following pillars: (i) separation of concerns, (ii) bottom-up modeling and (iii) automated refactoring.

Separation of concerns.

The usual way to represent a system using a FM consists in gathering information about the domain and the existing system and in creating a FM with this knowledge. In case of evolution, the designer of SPL knows all about the FM and computes the changes. Our first requirement (R1) triggers two challenges: first, we need to manage different domains for each concept used in the global SPL; second, in each of these domains new domain objects appear and should be modeled in the SPL. Moreover, the third requirement (R3) is directly linked to the "keep things simple" agile principle [12, principle 10]. Splitting a large problem into many small ones is a well known solution to manage complexity and is widely encouraged in software engineering generally through principles like separation of concerns.

SPLs do not intrinsically support separation of concerns. In front of the need to model a SPL using several models to be composed, the notion of multiple SPL was identified [START_REF] El-Sharkawy | Supporting Heterogeneous Compositional Multi Software Product Lines[END_REF][START_REF] Acher | Feature Model Differences[END_REF] Bottom-up modeling. Separating general and domain object specific functionalities is non trivial a priori [START_REF] Bosch | Product Instantiation in Software Product Lines: A Case Study[END_REF]. Even with smaller FMs evolutions are tedious and error prone. Modifying a FM to reflect a change in a domain object as it is specified in the second requirement (R2) needs to perfectly understand the whole FM. But it is contradictory with the idea of a community making evolutions: in that kind of process, each member of the community has a little piece of knowledge. Moreover, the third requirement (R3) emphasizes the need for complexity management.

To address this point, we assume that each element to be added or modified exists as a software artifact. Thus, it is possible to model this artifact and the associated ones as a FM, based on the local knowledge. The integration of this "partial" FM dedicated to a given evolution into the composite feature model is delegated to an automated algorithm used to merge them together [START_REF] Mathieu Acher | Separation of Concerns in Feature Modeling: Support and Applications[END_REF]. The algorithm can be used in union, intersection or diff mode to compute a feature model supporting respectively: the union of configurations providing by feature models in input ; the intersection of configurations existing in feature models in input ; and the difference of possible configurations. We use it here in union to propagate the evolution of the domain objects into the existing FM, freeing the BS-Dev from this tedious task. The operation will automatically add the new available configurations to the old ones. We illustrate in Fig. 3 how the merge algorithm is used to build a simplified source FM. Each software artifact related to a source exists, and defines a feature (e.g., Picasa, FlickR, Twitter ). These features are modeled as independent FMs, and the merge algorithm is used to build the final FM that captures the associated variability.

Automated refactoring.

Finally we now are able to manage the evolution of SPL FMs, but we still have to deal with the evolution of vocabularies (R4). FMs are not created and used by the same people, so we need to be sure that they all share the same vocabulary and if not, we have to give tools to modify this vocabulary: this need is directly linked to the agile principle which stands that every project needs to support "face-to-face conversation" with customers [12, principle 6]. Furthermore, in feature modeling the notion of vocabulary is essential, all their usage usually standing on feature names.

As SPL FMs are obtained by merging smaller ones, a change in a vocabulary may imply modifications in lots of FMs. The process of renaming each FM is still tedious and error prone. Moreover the usage of text editor operations, like regular expression replacement, is not always sufficient: a change in a domain vocabulary may imply to add a finer granularity or on the contrary to abstract things. Then we use a feature modeling language (Familiar [START_REF] Mathieu Acher | A domain-specific language for managing feature models[END_REF]) offering scripting capabilities to automate these refactoring tasks. We are then able to rename a feature in a set, to add or remove features and so on, in a simple and explicit way.

MANAGING DEPENDENCIES

According to Bosch [START_REF] Bosch | Toward Compositional Software Product Lines[END_REF], the product line's success causes a significant increase in the number and complexity of dependencies among components in the SPL. Dependency management is thus essential to the consistency of a SPL and should not be an obstacle to its evolution. Our first solution to manage complexity of SPLs was to split its representation into several feature models corresponding to domain concepts. In a FM, constraints are then automatically deduced from the merging of domain objects FMs, making their maintenance transparent to the BS-Dev. However the domain concepts are themselves interrelated. It is therefore necessary to support the expression and management of these dependencies so that the agility gained is preserved.

Requirements

R5: Implicit modeling of dependencies and inferences.

The domain modeling induces dependencies among domain concepts. For example, a renderer processing a particular type of information can only be linked to a source providing the same type of information. The SPL should take care of these dependencies to facilitate and ensure a rapid and consistent evolution of the SPL. Thus, BS-Dev in charge of renderers implementation focus on their artifacts, and the SPL tooling ensures that only adequate sources are connected with the renderers.

R6: Helping the BS-Dev to express dependencies. Some evolutions related to the integration of new domain objects require the management of specific dependencies (e.g., adding a new source corresponding to a legacy information system may require the use of a dedicated renderer). Similarly, changing optional features of a concept may involve the establishment of new dependencies to guide the selections by BS-User (e.g.,, adding a title as a feature of some zone may imply to only accept renderers supporting such a feature).

As it is necessary to handle dependencies between domain concepts, it is also necessary to allow the BS-Dev to express dependencies between specific domain objects.

R7: Enforcing SPL consistency. The number of composite configurations in which a domain object can be used is substantial. If it cannot be used in any composite configuration, it is useless and should not be part of the SPL. Verifying compatibility of a new domain object with all contexts in which it can be used, and more generally how changes impact the valid composite configurations is a challenge that we face.

Solution: Model Driven Evolution Process

It is known that FMs are not as expressive as metamodels: "Feature models are well adapted to capture simple selections from predefined (mostly) boolean choices within a fixed choices within a fixed (tree) structure; and metamodels support making new structures by creating multiple instances of classes and connecting them via object references." [START_REF] Bak | Feature and Meta-models in Clafer: Mixed, Specialized, and Coupled[END_REF]. In accordance with the identified needs and the previous observations, we choose to make explicit the relationships at model level. Their role is then to lead the configuration process. The proposed solution relies on (i) a metamodeling approach, (ii) the definition or restriction functions on models and finally (iii) the definition and verification of a realizability property to ensure the validity of the configurable products.

Metamodeling. To manage the relationship between FMs we have defined a metamodel that supports the definition of domain models as a composition of concepts corresponding to FMs and reifies the dependencies between them. These different elements support expression of cardinalities described in our case study. The metamodel is accessible from the project website 3 . Figure 1 is a simplification of a domain model conforms to our metamodel. This approach preserves a simple view of the product line from the BS-Dev viewpoint.

Restriction functions. Relations between the FMs lead the process of construction of composite configurations. Selecting a configuration in a FM can reduce the set of available selections in other linked FMs. To support these operations, restriction functions are associated to relations between FMs. A function is defined by a Familiar script [START_REF] Mathieu Acher | A domain-specific language for managing feature models[END_REF] that makes explicit how FMs are related. These functions are defined by BS-Dev using composition operators between FMs. If the implementation of certain operators can be complex, it is hidden. Implementation and understanding of dependencies is then facilitated promoting the consideration of change. These functions meet the requirements R5 and R6.

A propagation algorithm based on these functions has been defined. It supports automatic propagation of user choices in building different contexts according to the cardinality defined at the level of models. For example, the choice of a source reduced locally all renderers that may be associated. This selection does not change the set of possible renderers for other sources. Conversely, the selection of some layouts may globally prohibit selecting some sources. When a source and a renderer are associated it is no longer possible to associate them with a different source or renderer.

Realizability checking. If the individual understanding of

dependencies is simple, their composition can be very complex, making the strength of the approach. To ensure that the selection of a configuration does not prohibit the construction of a valid composite configuration (see R7), we check this realizability property [START_REF] Metzger | Disambiguating the documentation of variability in software product lines: A separation of concerns, formalization and automated analysis[END_REF] after each addition or modification.

A minimal kernel is initially created in which a composite configuration is always possible for all selected configurations. The FMs are then considered as sets of configurations. Adding or editing a set of domain objects thus implies to check the existence of valid configurations containing these domain objects. We proceed by a traversal of the graph corresponding to the domain model from those domain objects. The non-existence of a valid composite configuration leads to the refusal of the element.

CONCLUSION AND PERSPECTIVES

Feature-oriented modeling advocates the definition of feature models to support the variability of large software and SPL. However, the need for evolution in these feature models is not widely studied for now. In this paper, we used a large piece of software, started eight years ago and currently reengineered as a SPL, to illustrate such a need. Based on this example and the encountered evolutions, we focused on two points: (i) the evolution of domain objects captured in the feature models and (ii) the evolution of dependencies between the domain objects in the models. For each point, we expressed its requirements based on our field experience and proposed a solution to address these requirements. Our solutions rely on the definition of composite feature models, and the use of a model-driven evolution process to support it on large real systems.

One of the immediate perspectives of this work is to apply it to other software in order to strengthen its empirical validation. We plan to use SensApp4 , a scalable application used to collect data provided by sensors, supporting the definition of "Internet of Things" pieces of software. We also plan to address several difficulties encountered while implementing composite feature models. First of all, keeping aligned the vocabulary used in the different models is challenging without support from the semantics domain. We plan to use ontologies and associated alignment mechanisms to support such a task [START_REF] Czarnecki | Feature Models are Views on Ontologies[END_REF][START_REF] Fagereng Johansen | Exploring the Synergies Between Feature Models and Ontologies[END_REF]. Another challenge we plan to address is how to maintain consistency between the different elements of a composite feature model and the associated configuration set. For example, adding a new constraint in the feature models may restrict the set of available configurations. How one can detect such a situation, and take accurate decisions with respect to the existing set of products already derived from the modeled product line?

Figure 1 :

 1 Figure 1: Simplified domain model of BS

Figure 3 :

 3 Figure 3: Using a merge algorithm to build a FM

http://www.jseduite.org

http://www.yourcast.fr, ANR EMERGENCE

http://www.yourcast.fr/me12/

http://sensapp.modelbased.net

Acknowledgments

The work reported in this paper is partly funded by the ANR YourCast project under contract ANR-2011-EMMA-013-01.


Simon Urli
email: urli@i3s.unice.fr

Sébastien Mosser
email: mosser@i3s.unice.fr

Mireille Blay-Fornarino

Philippe Collet
email: collet@i3s.unice.fr

How to Exploit Domain Knowledge in Multiple Software Product Lines?

Keywords: Software Product Lines, Feature Modeling, Domain Model, Digital Signage, Cloud Computing

As Software Product Lines (SPL) are inevitably moving towards a multiple form to tackle issues of reuse and complexity, variability management across the composed SPLs is still addressed with basic inter-constraints. Based on two disjoint case studies (digital signage and cloud computing), we identified this challenging problem for the SPL community. In this paper we describe how the domain knowledge needs to be exploited to support a more complete definition of Multiple Software Product Lines (MSPL). Such an exploitation implies the definition of a domain-driven definition of configuration and an order independent configuration process.

I. INTRODUCTION

Software Product Line (SPL) engineering is concerned with systematically reusing development assets in a given domain, capturing their common and variable aspects [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF]. But with complex large-scale systems reusing all forms of software components, variabilities come from different domains or deal with different concerns, empeding their capture in a single SPL. Multiple Software Product Lines (MSPL) are defined as a way to tame the intrinsic complexity of capturing variability in a complex domain [START_REF] Holl | A systematic review and an expert survey on capabilities supporting multi product lines[END_REF], [START_REF] Bosch | Toward compositional software product lines[END_REF].

Managing variability across different SPLs to compose them is supported by different approaches and tools based on feature models. Such approaches mainly relate their variability descriptions with inter-SPL constraints expressed as logical relations [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF], [START_REF] Buhne | Modelling requirements variability across product lines[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]. Then constraints are usually expressed using low-level tooling of the SPL implementation instead of the business domain. It contradicts the essence of the SPL paradigm, that is being domain-oriented. The objective of this paper is to describe this problem, i.e., the need for domainoriented modeling to support the definition of MSPLs based on multiple feature models. Starting from two disjoint largescale case studies, the same problem was identified by different stakeholders (Section 2). We refine it as three challenges regarding domain modeling of a MSPL (Section 3): i) how to manage fully-fledged relationships (e.g., aggregation with cardinality, instantiation) between the domain model and the corresponding input SPLs, as well as between these SPLs; ii) how to define the notion of configuration at the MSPL level, relating it to the domain while reusing configurations of the input SPLs; iii) how to support an order-independent and safe configuration process so that any configuration action at any level (MSPL or input SPLs) can be done in a consistent way, thus providing a very general framework for MSPL management. We finally discuss some success criteria for candidate solutions and present ongoing and future work (Section 4).

II. CASE STUDIES

This section is dedicated to the description of the two case studies used to identify the problem. It is worth to note that the two case studies are disjoint, and implemented by different research groups, emphasizing the concreteness of the identified issues.

A. SensApp (Cloud Computing)

The SensApp [START_REF] Mosser | SENSAPP as a Reference Platform to Support Cloud Experiments: From the Internet of Things to the Internet of Services[END_REF] platform supports the definition of innovative applications, based on the Internet of Things (IoT). Connected "things" push data to the SensApp platform, which acts as a middleware between things and pieces of software exploiting sensed data. For example in an intelligent building, temperature sensors collect room temperatures, and radiators (or A/C systems) are remotely activated by a dedicated piece of software to adjust it. The main challenge for SensApp is to scale w.r.t. the load (e.g., data size, bandwidth, response time) generated by realistic IoT applications. The cloudcomputing paradigm supports the on-demand deployment of Virtual Machines (VM) able to absorb such a load. Thus, SensApp is developed to exploit cloud scaling capabilities, requiring a fine-grained customization of each layer of the whole cloud stack (i.e., Infrastructure, Platform and Service). Several product lines are defined (upper right part of Fig. 1) to support such a configuration, for example to customize the operating system used to host the system, or the virtual machine characteristics to be used (e.g., strong processor, large storage). As SensApp is designed to be distributed among several nodes, these SPLs must be instantiated multiple times. Moreover, as each SPL represents a dedicated body of knowledge, the configuration process involves several actors working simultaneously on the same product (e.g., a network topology expert does not know how to tune a Linux kernel to improve its performance w.r.t. disk inputs/outputs).

B. YourCast (Digital Signage)

YourCast [START_REF] Urli | Using Composite Feature Models to Support Agile Software Product Line Evolution[END_REF] is a system designed to support the definition of customized digital signage system. It pursues the research made by the I3S laboratory on the JSeduite platform [START_REF] Mosser | Web Services Orchestration Evolution : A Merge Process For Behavioral Evolution[END_REF], started in 2005 and deployed in 3 institutions. Based on the experience gained while implementing the JSeduite digital signage platform (70K LoC, 9 contributors), YourCast captures the variability of such systems, and provides a user friendly way of configuration. The project is funded in the aim of an industrial transfer. It involves 2 SMEs interested by the automatic generation of digital signage systems applied to large associations meetings, conferences, or sport events (e.g., Tour de France). YourCast targets non-specialist users (e.g., association member), who have to compose (i) information sources implemented through common Internet services (e.g., RSS feeds, Twitter), (ii) screens look and feel, and (iii) information rendering mechanisms. Consequently, there is a large amount of diverse variabilities to be managed to create a consistent digital signage system adapted to users' requirements. This leads to the need of a MSPL (e.g., information sources, layouts, renderings), where several elements must also be multi-instantiated.

III. CHALLENGES IN DOMAIN-ORIENTED MSPL

We analyze here three main challenges to exploit domain knowledge in MSPL and we introduce each of them using concrete examples of issues encountered during the case studies.

C1. Managing Relationship at the Domain-Level

The first challenge is to exploit a domain-driven approach to express relationships between SPLs.

SensApp: The SensApp platform involves different body of knowledge (e.g., virtual machine customization, network topology definition), captured as SPLs by each expert. Thus, the existing relationships between features defined in different SPLs reify some knowledge that cross the boundary of a single domain of expertise. For example, a data storage service based on NoSQL technologies requires (i) an immense amount of RAM available for the VM and (ii) the deactivation of kernel parameters like diratime to improve the available input/outputs per seconds (IOPS) at the hard drive level. Relying on a syntactical binding at the SPLs level to support such relationships is a time consuming and error-prone task, as it does not capture the intention associated to a relationship like "NoSQL ⇒ IOPS". To properly manage the SensApp platform as a whole and address a fully-fledged cloud stack, SensApp' architects built a domain model reifying the relationship between all the elements and expressing these relations in a domain-oriented way.

YourCast: At the domain level, a digital signage system is a composition of information sources connected to renderers and displayed using a given layout as shown in Fig. 1 (label C1). An information source broadcasts a given type of information and can only be connected to renderers able to process the same type of information. In terms of configurations it means that only some configurations of source can be connected to given configurations of renderer. Moreover, some components could be used several times in a given system: end-users want to display different sources using each time one renderer and perhaps several times the same kind of renderer. For example, a school headmaster wants to display calendars which are considered as sources. As several kind of renderers could be used to display calendars (e.g., displaying informations by day, weeks, months...) this user will be able to use many times the same kind of renderer in the same digital signage system.

In the literature, MSPL are defined as "a set of several selfcontained but still interdependent product lines that together represent a large scale-scale or ultra-large-scale system" [START_REF] Holl | A systematic review and an expert survey on capabilities supporting multi product lines[END_REF]. In order to link several feature models and to be able to create multiple instances, Czarnecki et al. defined the cardinalitybased feature model formalism allowing to enrich features with cardinalities, and to make references to external feature models [START_REF] Czarnecki | Staged configuration through specialization and multilevel configuration of feature models[END_REF]. However this solution is only syntactic and does not refer to the domain knowledge. Different challenges are described by Schirmeier et al. regarding multiple instances and dependencies between SPLs, but without referring to the exploitation of domain knowledge [START_REF] Schirmeier | Challenges in software product line composition[END_REF]. Besides the Common Variability Language (CVL) proposes the notion of configurable unit that aims at being a composite variability model [START_REF] Haugen | Common Variability Language (CVL)[END_REF]. Configurable units can be referred to and composed, enabling a form of SPL composition, but there is no specific mechanism to handle a domain model of the MSPL as described in our case studies.

C2. Relating Configuration Concept to the Domain

At the domain level, a part of a system consists of a composition of model elements. At the SPL level, a configuration is defined as follows: "Given a feature model with a set of features F, a configuration is a 2-tuple of the form (S, R) such that S, R ⊆ F being S the set of features to be selected and R the set of features to be removed such that S ∩ R = ∅." [START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF]. As there is no concept of configuration for MSPL, it must be defined to consistently take care of multiplicities and relationships that exists in a business domain.

SensApp: The platform is defined as a distributed one. As a consequence, a SensApp instance is intended to be deployed on several network nodes. It is part of the domain expertise to properly distribute the services involved in SensApp (e.g. data dispatcher, data storage, data verification, data conversion) according to their specificities and the associated cost. For example, a "small" deployment involves only two VMs to reduce cost: the first one has a lot of available disk space to support the storage of sensed data, and the second one is computation-oriented and has more RAM to quicky handle the incoming data. But a "real" deployment actually involves more VMs, coupled to load balancing mechanisms for elastic scaling and redundant storage to ensure data availability. Thus, a domain decision (i.e., small or real deployment) while configuring a SensApp deployment impacts the variability offered by the defined SPLs, and also impacts the associated cardinalities. As a user, the selection of a "small" deployment will restrict the variability available in the VM SPL, but also restrict the deployment to only two VMs.

YourCast: A digital signage system is an assembly of components (e.g., sources, renderers) conforming to the rules of the domain: e.g., a source of information must be displayed using exactly one renderer. Thus the composition of the various elements of such a system is the responsibility of the final user (Fig. 1 (label C2)), e.g. she selects the renderer associated to a given source. The resulting assembly must conform to the domain. elements in the model level" [START_REF] Filho | Leveraging variability modeling for multi-dimensional Model-driven Software Product Lines[END_REF]. This issue is even more important when we consider a MSPL. However MSPLs are often defined using nested or composed feature models: in this precise case a configuration of the MSPL is equivalent to a configuration of a SPL [START_REF] Acher | Separation of Concerns in Feature Modeling: Support and Applications[END_REF], [START_REF] Czarnecki | Staged configuration through specialization and multilevel configuration of feature models[END_REF]. Other works advocate the use of a class diagram to reify SPL instances and links between them [START_REF] Rosenmüller | Automating the configuration of multi software product lines[END_REF]. This approach introduces domain knowledge at the model level but does not allow the end-user to choose the exact amount of instances she wants at configuration time, so the model is clearly not expressive and flexible enough for our two case studies.

According to Filho et al., "a consistent configuration in the features level [may] lead to an inconsistent composition of

C3. Supporting Domain-Driven Configuration Process

While deriving a product, the user needs to be guided by her own interpretation of the domain knowledge. Such an interpretation differs from one to another leading to different configuration paths.

SensApp: The SPLs involved in SensApp address different domains of expertise. Based on our experience while deploying SensApp instances in different contexts, it is not possible to predict the way a customer will perform its configuration. On the one hand, cloud experts start at the Infrastructure level, configuring the VMs they want to use to support SensApp on a cost basis (e.g., no more than $25/month). They expect the system to automatically prune the variability in the other SPLs to only show residual configurations. On the other hand, business experts start at the Service level, based on their knowledge of their sensor infrastructure. Their intention is to properly select the needed services, and they expect the system to automatically prune available topologies and VMs able to support such needs. In small institutions, these two personas are often instantiated by the same user who tries to find a consensus between costs and needs. These users actually expect the MSPL to guide the configuration of a SensApp deployment based on their domain knowledge.

YourCast: Based on our experience, setting up a digital signage system is performed by one user at a time, but depending on institution they don't follow the same path to configure it. For instance, a school headmaster begins selecting all sources of information she wants, while the director of an institute for people with visual disabilities starts by defining the layout and put more emphasis on the visualization of the content. On average, the assembly of a concrete digital signage system corresponds to about fifteen sources and renderers (the same source may be viewed differently in different areas of the screen). It is therefore important not to delay the detection of inconsistencies in the derivation process while allowing an order-independent process.

One of the needed capability in MSPL identified by Holl et al. is the "user guidance and support for product derivation": "People working on different product lines in an MSPL need to be made aware of the impacts of their changes on other product lines and vice versa. Such impacts need to be propagated for instance through dependencies between the product lines." [START_REF] Holl | A systematic review and an expert survey on capabilities supporting multi product lines[END_REF]. Current state of the art solutions are not directly applicable in this context as they usually consider an ordered process. The multistage configuration defined by Czarnecki et al. allows to create only valid configuration but with a predefined process [START_REF] Czarnecki | Staged configuration through specialization and multilevel configuration of feature models[END_REF]. This idea is reinforced by Hubaux et al. with the configuration workflows [START_REF] Hubaux | Formal modelling of feature configuration workflows[END_REF]. Existing works on ensuring consistency while deriving products in MSPLs also rely on ordered process [START_REF] Vierhauser | Applying a Consistency Checking Framework for Heterogeneous Models and Artifacts in Industrial Product Lines[END_REF], [START_REF] Elsner | Consistent Product Line Configuration across File Type and Product Line Boundaries[END_REF].

IV. DISCUSSIONS AND PERSPECTIVES We discuss in this section what criteria we will use to evaluate success in solving the above mentioned issues and present briefly our ongoing work to address this problems.

A. Success Criteria

As the problem is to exploit domain knowledge to support MSPL, we advocate that the success of candidate solutions will be measured in terms of exploitation capabilities.

The constrained relationships will be expressed at a domain level relying on unextended, i.e., unmodified, input SPLs and assets. User-centric experiments should be able to also evaluate the expressiveness of the solution, i.e., to which extent the MSPL domain is really and easily captured, taking into account the multiplicity in the domain elements and in the input SPLs.

Regarding the MSPL configuration (challenge C2), an important success criterion is the kind of consistency property the proposed concept of configuration will be able to enforce. For example, we have to ensure that any (un/de-)selection made on the MSPL is propagated through the relationships so that the input SPLs are consistently configured and the global configuration is still consistent regarding the domain knowledge. Another criterion is the capacity to detect inconsistency during a MSPL configuration to raise it at a domain-level.

To measure success w.r.t C3, we have to assess that the configuration processes supported by the candidate solution cover the needs of any domain-experts.

Finally, the scalability of all the central operations of the whole approach has to be validated both on formal and experimental ways. Propagating configuration choices and detecting inconsistencies are certainly costly operations that must be implemented with the barrier of dealing with large numbers of features, intra constraints in input SPLs, and inter-constraints created by the relationships with cardinality.

B. Ongoing and Future Work

We are currently defining a tool supported solution to the problems described in this paper. We are experimenting an integrated approach by defining the MSPL as a domain model and its relationships to the constituting SPLs. Each of these SPLs is described by a feature model and a model, which conforms to a metamodel that defines the relationships between the FMs. While being currently fine-tuned and tested on our case studies, we already observed that the resulting model makes explicit the multiplicity between feature models and between assets. In addition, we are also formalizing the resulting concept of MSPL, so to ensure some salient properties and to drive a safe and order-independent composition process. Some tool support is also undergoing implementation, based on feature model composition operators [START_REF] Acher | Separation of Concerns in Feature Modeling: Support and Applications[END_REF] and on the FAMILIAR DSL [START_REF] Acher | FAMILIAR: A Domain-Specific Language for Large Scale Management of Feature Models[END_REF].

AKNOWLEDGEMENTS

Fig. 1 .

 1 Fig. 1. A simplified view of the challenges applied to the case studies

The work reported in this paper is partly funded by the ANR YourCast project under contract ANR-2011-EMMA-013-01. SensApp co-development is funded by the IDOL project (PHC Aurora program, #28864TK). Empirical experiences with cloud deployment are funded by Amazon through the Mod4Cloud research grant.