Keywords: SUCCEED, Software Product Line Engineering, Software Product Line Evolution, Software Product Variants, Software Reuse, Software Derivation, Clone-and-Own, Feature Location, Feature Model, Software Variability. i SUCCEED, Ingénierie des Lignes de Produits Logiciels, Evolution des Lignes de Produits Logiciels, Variantes de Produits Logiciels, Réutilisation de Logiciels, Dérivation de Logiciels, Clone-and-Own, Identification des Caractéristiques, Diagramme de Caractéristiques, Variabilité Logicielle

A Software Product Line (SPL) manages commonalities and variability of a related software products family. This approach is characterized by a systematic reuse that reduces development cost and time to market and increases software quality. However, building an SPL requires an initial expensive investment. Therefore, organizations that are not able to deal with such an up-front investment, tend to develop a family of software products using simple and intuitive practices. Clone-and-Own (C&O) is an approach adopted widely by software developers to construct new product variants from existing ones. However, the efficiency of this practice degrades proportionally to the growth of the family of products in concern, that becomes difficult to manage. In this dissertation, we propose a hybrid approach that utilizes both SPL and C&O to develop and evolve a family of software products. An automatic mechanism of identification of the correspondences between the features of the products and the software artifacts, allows the migration of the product variants developed in C&O in an SPL. The originality of this work is then to help the derivation of new products by proposing different scenarios of C&O operations to be performed to derive a new product from the required features. The developer can then reduce these possibilities by expressing her preferences (e.g. products, artifacts) and using the proposed cost estimations on the operations. We realized our approach by developing SUCCEED, a framework for SUpporting Clone-and-own with Cost-EstimatEd Derivation. We validate our works on a case study of families of web portals.

Context and Motivation

In software industry, many are the organizations that develop a family of software products for a group of customers, that belong to the same market segment. These organizations vary in size, in terms of staff, intellectual and financial resources, from start-ups and small organizations to large enterprises [START_REF] Trigaux | Software Product Lines : State of the art[END_REF].

In general, large enterprises study and identify their market segment and product portfolio, as an initial step, before starting the development process [START_REF] Clements | Software Product Lines : Practices and Patterns[END_REF][START_REF] Pohl | Software Product Line Engineering[END_REF]. Similarly to other domains in industry, such as automotive industry, mass customization is adopted by organizations that focus on developing and maintaining a family of software products instead of developing many individual products [START_REF] Krueger | Easing the transition to software mass customization[END_REF][START_REF] Pohl | Software Product Line Engineering[END_REF]. Therefore, they are able to determine the main features of the family of products to develop, and plan to develop these products in a way that allows their reuse. Some of these organizations adopt Software Product Line Engineering (SPLE) approach, which consists on developing artifacts adaptable in several products in a domain engineering process, before deriving the products in an application engineering process by exploiting the developed artifacts [WL99, PBV05, DSB05, LSR07, ACR09]. A Software Product Line (SPL) is a set of software products that belong to the same domain and have some characteristics in common [START_REF] Clements | Software Product Lines : Practices and Patterns[END_REF]. These characteristics are known as features [BLR + 15]. A Feature Model (FM) is one of the abstract representations of SPL products variability [KCH + 90]. A configuration is a selection of features that respects the constraints imposed by the FM and generally reflects a product of the SPL [BEG + 11]. SPLs permit a systematic reuse of software artifacts, which reduces development cost and increases time to market and software quality [START_REF] Trigaux | Software Product Lines : State of the art[END_REF][START_REF] Pohl | Software Product Line Engineering[END_REF].

Developing the artifacts of an SPL through the domain engineering process, before deriving new products throught an application engineering phase, is considered as a large and expensive up-front investment, that several organizations are not able to afford [START_REF] Pohl | Software Product Line Engineering[END_REF]. Therefore, in practice, most small organizations do not develop an SPL from scratch [START_REF] Al-Msie'deen | Reverse Engineering Feature Models from Software Variants to Build Software Product Lines[END_REF], but often, start with developing a successful product, that grows later on into a family of products [START_REF] Bosch | Introducing agile customer-centered development in a legacy software product line[END_REF]. For instance, a start-up or a small organization aiming to develop software products, focuses on providing high quality and fast delivered products to its very new customers, in order to position itself on the market and attract more customers. Thus, it concentrates on developing a single product at a time without planning for future products releases. Short-term thinking prevents some organizations from initially predicting that they are going to develop a family of products, and they realize it when customers requirements emerge over time. Consequently, this prevents organizations from investing enough time and resources to support and manage reuse during development process [DRB + 13]. Such organizations develop software products by adopting a simple ad-hoc technique such as copy-paste-modify [START_REF] Ziadi | Feature identification from the source code of product variants[END_REF][START_REF] Martinez | Mining software artefact variants for product line migration and analysis[END_REF], or the well-known Clone-and-Own (C&O) adopted when developing products through a Version Control System (VCS). C&O is an approach that consists in cloning an existing Product Variant (PV) then modifying it to add and/or remove some functionalities in order to obtain a new PV [ZPXZ12, DRB + 13, FLLHE14, LBC16]. Due to simplicity, availability and rapidity that it provides, this approach is practically adopted by many organizations as "favorable and natural" solution to develop a family of related software systems [DRB + 13]. Although being a time and cost saving practice, C&O might turn into an expensive and inefficient solution if tracking about the artifacts existing in several clones is lacked, which produces an incertitude in identifying the PV(s) to be considered as source for cloning [DRB + 13, AM14, LBC16]. A possible alternative is the migration of the existing PVs into an SPL, in order to manage their variability and benefit from a systematic reuse [START_REF] Clements | Software Product Lines : Practices and Patterns[END_REF]. This process is known as extractive [START_REF] Krueger | Easing the transition to software mass customization[END_REF] or bottom-up [MZB + 15b] adoption, or re-engineering [ZHP + 14, AM14, ALHL + 17] of software product lines. As per Ziadi et al., a manual reverse engineering is errorprone and time-consuming [START_REF] Ziadi | Feature identification from the source code of product variants[END_REF]. Thus, an automated approach is required to integrate the existing PVs into an SPL.

Evolving a family of software products consists often in deriving new variants by reusing the existing ones. Despite that SPLs provide systematic reuse, due to variability management, product derivation is restricted to the product line portfolio. Hence, deriving new products consists of evolving the SPL at both domain and application engineering levels, a task that is considered complex due to variability and interdependency between products [START_REF] Botterweck | Evolution of Software Product Lines[END_REF].

Several works in literature have proposed extractive SPL adoption frameworks and approaches to enhance C&O [AmSH + 13, RC13a, FLLHE14, MZB + 15b]. These frameworks disparately allow the integration of existing PVs, support their systematic reuse and enhance C&O with possible derivation -automated or sometimes assisted with hints -and integration of new PVs. However, these approaches do not provide software engineers with the freedom that C&O offers them to create new PVs. In C&O, during product derivation, software engineers are the decision makers. The "own" is gained when software engineers are aware how the product is constructed, since they decide what and how to clone. The proposed approaches aim to automate the clone and impose their solution on software engineers, that are not able to recognize from which PVs the artifacts of the derived PV where cloned. C&O practitioners consider that any alternative approach, in order to convince them, must offer the advantages provided by C&O such as availability, simplicity and independence [DRB + 13].

Running Example

We illustrate in the upcoming example, three PVs for managing soccer matches 1 . The PVs are web applications implemented using markup (HTML), style sheet (CSS), scripting (JavaScript), and object-oriented (Java classes and servlets) languages. 1.1 shows the business functionalities -a.k.a features -implemented by each variant, and Table 1.2 shows an excerpt of the files -a.k.a. assets -used by each variant to implement the features, and their corresponding versions. Product p 1 allows to manage, add and modify matches. Product p 2 allows to delete matches in addition. Product p 3 allows to manage and add matches only. For simplicity and to make the example comprehensive, we show in Table 1.2 only an excerpt of the assets, and we represent the assets by their names and not their relative path within the projects. For instance, DeleteM atch.java refers to src/M atch/DeleteM atch.java. Figure 1.1 shows the main interfaces of the 3 variants. We demonstrate our approach on this running example throughout the dissertation.

Challenges

In this section, we identify the challenges that might face an organization at development level when constructing and evolving a family of software products. In our dissertation, we do not address other aspects such as organizational challenges that were addressed widely by Bosch [START_REF] Bosch | Toward compositional software product lines[END_REF][START_REF] Bosch | Introducing agile customer-centered development in a legacy software product line[END_REF].

Challenge 1: Supporting the derivation of new product variants How to guide software engineers to derive new product variants?

A family of software products is composed of a set of products that are developed to respond to the requirements of a group of customers that belong to the same market segment. Thus, these products share a set of common characteristics, while they differ from each other due to some variable characteristics that are implemented by some products and not by others, and product specific characteristics where each is implemented specifically by a single product of the family [START_REF] Botterweck | Evolution of Software Product Lines[END_REF]. Arising customer requirements and technology changes necessitate the development of new product variants. Hence, the derivation of a new product variant is needed whenever the family of software products does not offer a variant that implements all and only the required features. Given the family of products presented in the running example, to deliver a product that allows to manage, add and delete matches, a new product variant -say p 4 -has to be derived, since none of the existing variants implements all and only the requested features.

Challenge 1.a: Mapping features to assets How to determine which assets contribute in the implementation of each feature?

When the derivation of a new product variant is needed, reusing the artifacts of existing variants is advantageous. To do so, first the features implemented by each existing product variant have to be identified. For instance, to reuse the feature DeleteM atches to derive p 4 , one must know that it is implemented only by product p 2 . The implementation of a feature is realized in one or more assets of the products that implement the feature. Therefore, identifying the assets that contribute in the implementation of a certain feature is necessary for reuse in order to determine which assets are required for the derivation of the new product.

Challenge 1.b: Identifying the possible scenarios and operations to achieve the derivation What are the products or combinations of products that can be a source of reuse to achieve the derivation, and respectively, what are the operations that must be performed on the cloned assets to construct the new product?

A feature required for the derivation of a new product can be implemented by several existing products. Further, the set of the required features can be spread on several products which necessitate the reuse of assets that belong to different products. Thus, determining the combinations of products that implement the set of required features for the derivation is a major task. An existing product might implement some features that are not required for the derivation of the new product, and therefore, those features must be identified. For instance, a possible scenario to derive p 4 is to clone p 2 and remove from the clone the implementation fragments corresponding to feature M odif yM atches. Consequently, the assets of those products that implement the required features might implement also some unrequired features. Hence, for each required asset that has to be cloned, the operation that must be performed on it has to be specified. For example, considering that the asset SaveM atch.java of the product p 2 is mapped to the feature M odif yM atches, since the latter is not required, the operation to be performed on the asset SaveM atch.java is to clone it and remove from it the implementation fragments corresponding to M odif yM atches.

Challenge 1.c: Facilitating derivation choices

What might be the selection factors and indicators that help software engineers to make the derivation choices? What is the cost to perform each asset level operation? Respectively, which scenario provides the least expensive derivation cost?

Several scenarios might be available to achieve the derivation, for instance, based on what a software engineer can decide to derive p 4 either by cloning p 2 and removing from the clone the code fragments related to M odif yM atches, or by cloning p 3 and extracting the code fragments related to DeleteM atches from p 2 and integrate it in the clone. One selection factor could be her preference to work with p 2 (that she is more familiar with) or p 3 (that is the recent derived product) . Further, some of the assets corresponding to the products of a possible scenario may require only to be cloned without being modified since they are mapped only to the required features. Other assets require to be cloned and modified in order to remove implementation fragments corresponding to unrequired features. Moreover, several asset level operations might be identified to construct the asset implementing the required features. For instance, referring to Table 1.2, there exists 3 versions of style.css, hence, an operation might consist of removing some features from a version, while another operation might consist of collecting features from several versions. Since several scenarios (combinations of products) and several asset level operations can be identified, the selection of the appropriate scenario and operations might become a difficult task. Therefore, providing valuable indicators to software engineers about the products of each scenario and the assets of each operation can facilitate their derivation choices, since they will be able to construct the derivation scenario based on their own preferences. Moreover, estimating the cost of an asset level operation and respectively the cost of a possible scenario can facilitate the selection of the operations to perform to achieve the derivation.

Challenge 2: Evolving the family of software products How to integrate the newly derived variants in the family of software products?

The derivation of new products involves the definition of new features and the construction of new assets. Integrating the newly derived products into the family of software products is necessary to allow their reuse in future derivations. Moreover, the artifacts added during derivation can enhance the derivation of more products.

Challenge 2a: Helping to structure features when adding a new variant How to update the structure of the features of the family of products to integrate the features added during the configuration? The derivation of new products comes mostly from the need of new features that were not offered by the existing products. Hence, it is important to allow software engineers to simply define those features during the configuration of a new variant. Furthermore, once the variant is integrated into the family of software products, its new features must be integrated as well. Hence, it is necessary to update the structure of the features of the family of products, and redefine the constraints that manage their selection.

Challenge 2b: Managing the addition of new products How to support the integration of the newly derived products by clone-and-own into the family of products? How to guarantee that the integration of a new product does not prohibit the derivation of existing ones?

It is important to allow a smooth and incremental integration of the newly derived products into the family of software products in order to benefit from their systematic reuse in future derivation and employ their new artifacts to derive new products. Consequently, it is necessary to determine the impact of this integration on the family of products to guarantee that evolving it by integrating new products preserves the derivation of the existing ones as well.

Contributions

In this dissertation, we address the development of a family of software products based on C&O. We focus on the segment of software engineers that are familiar with C&O and looking for support during the derivation of PVs. Thus, the main goal of this dissertation is to support software engineers in deriving new PVs based on C&O. To fulfill this goal, we propose a hybrid approach that allows on the one hand an automated derivation of existing PVs after migrating them into an SPL, and on the other hand it supports the derivation of new PVs based on C&O by providing the possible operations to perform at asset level, in order to derive the desired product. To facilitate the choice of the operations to perform during product derivation, we define correlation indicators and functions in order to estimate the cost of an operation. Hence, software engineers can rely on their own preferences and the proposed cost estimations in order to achieve the derivation. To enable SPL evolution, our approach permits the integration of the newly derived products in the established SPL. The contributions of our approach are as follows:

1. The first contribution consists of a novel light mechanism to determine mappings between features and assets, while migrating the existing PVs into an SPL. We define those mappings as correlations. Correlations serve in facilitating reuse and maintenance, since they allow to determine which assets contribute in the implementation of each feature. Meanwhile, the migration of the existing PVs into an SPL enables also their automated derivation.

2. In the second contribution, we aim to support software engineers in deriving new PVs based on C&O. Instead of imposing a single solution, we propose the possible configuration scenarios by means of operations to perform at asset level, in order to derive a new product variant. A configuration scenario provides a top-down overview, specifying the combination of products to rely on, and the features to retain or remove from them in order to construct the desired product. We assign to each configuration scenario, the operations to perform in order to accomplish the derivation. Operations consist of the actions to be made at asset level, such as removing or extracting the implementation fragments corresponding to a certain feature. We auto-generate an FM based on the identified configuration scenarios and operations. The generated FM can be configured either by choosing one of the proposed configuration scenarios, or by selecting for each required asset one of its proposed operations, regardless the configuration scenarios. Moreover, the generated FM allows a software engineer, whenever possible, to prevent operations that correspond to a product or a version of an asset that she is not familiar with.

3. The third contribution consists on providing a cost estimation of the operations to perform, and respectively the proposed configuration scenarios. In order to facilitate the choice of an operation or a configuration scenario, we define correlation indicators and functions that allow to estimate the cost of a certain operation. Software engineers can rely on the estimated cost as a valuable selection parameter while deriving a new product.

4. The fourth contribution consists of providing a reactive SPL evolution by allowing an incremental integration of the newly derived products in the SPL. This integration coincides with an incremental update of the correlations. The integration of the newly derived products into the SPL permits their automated derivation as well as the existing ones and allows the reuse of their artifacts in future derivations.

We realized our approach by developing a framework for SUpporting Clone-and-own with Cost-EstimatEd Derivation (SUCCEED). SUCCEED provides an incremental integration of PVs into an SPL and a guided derivation of new PVs based on the approach that we propose in this dissertation. We evaluated our approach on the incremental derivation of 5 products based on an initial product line of 3 products.

Organization of the Dissertation

This dissertation is organized into four parts.

Part I presents the literature review and consists of two chapters:

-In Chapter 2, we present the background in which we demonstrate the two reuse practices that we rely on to construct our approach which are Clone-and-Own and Software Product Lines. In this chapter, we point on the necessity of reuse, and we clarify the purpose of the hybrid approach that we adopt, by taking benefits and avoiding drawbacks of each of the two presented practices.

-In Chapter 3, we present the related works, and we position our work compared to them. On this basis, we identify our contributions choices.

Part II presents our approach contributions and it consists of four chapters:

-In Chapter 4, we provide our definition of an SPL and demonstrate the process of migrating PVs into it. Further, we present the mechanism of identifying correlations.

-In Chapter 5, we present the configuration process, and we demonstrate how we identify for each configuration its possible configuration scenarios and operations to perform.

-In Chapter 6, we define correlation indicators and functions that we use to estimate the cost of a certain operation, and respectively the cost of a configuration scenario.

-In Chapter 7, we present the derivation and evolution process, in which we demonstrate how we support the derivation with a constraints system allowing software engineers to select favorable configuration scenario and operations based on their own preferences and the proposed cost estimation. Furthermore, we demonstrate how a newly derived product can be integrated in the SPL and how correlations and FMs are updated.

Part III presents the SUCCEED framework and approach validation:

-In Chapter 8, we present SUCCEED, the framework that we developed to implement and test our approach.

-In Chapter 9, we evaluate our approach on a case study that consists of a product line of 8 product variants.

Part IV concludes the dissertation:

-In Chapter 10, we conclude the dissertation by summarizing its contributions and exposing the perspectives of this work.

Part I

Background and State of the Art

Software Reuse

In software industry, same as any domain in business industry, supplier interests contradict with customer interests [START_REF] Trigaux | Software Product Lines : State of the art[END_REF]. A supplier aims to deliver a product with the minimum development effort and the maximum profitability, while a customer aims to receive the product in a short period of time, providing a set of required functionalities adapted for her needs. Responding to the intensive market demands, put suppliers in front of challenges that start early at the analysis and design activities in the software development life cycle and do not end after delivering the software product. Those challenges are:

-Cost & Effort: develop the software product with the lowest cost and minimum effort.

-Quality: ensure a high software quality in terms of efficiency and effectiveness.

-Delivery: deliver the software product in a short period of time.

-Maintenance: provide a quick and smooth maintenance of the software product when needed.

In July 2017, similarily to preceding years, the Gartner Group announces that "enterprise software" spending will have the highest annual growth rate in the IT sector in 2018, with forecasts of 8.6 percent for 2018 [START_REF] Group | Gartner Says Worldwide IT Spending Forecast to Grow 2.4 Percent in[END_REF]. In fact, this indicator reflects the large amount of functionalities offered in today's enterprise software systems, to serve the progressing amount of customer requirements. Standardized mass products could not satisfy the particular requirements of all customers. Therefore, mass customisation became a need to respond to the high demand for individualized products [START_REF] Pohl | Software Product Line Engineering[END_REF].

" Mass customisation is the large-scale production of goods tailored to individual customers' needs.

[DAV87]

Although individualized products differ from each other by providing specific functionalities, they belong to the same market segment, and therefore, have a large portion of functionalities in common. The increase of customer requirements raises up several problems, due to the growth of the software size and respectively the development complexity. These problems can be identified as follows [START_REF] Trigaux | Software Product Lines : State of the art[END_REF]:

-A functionality may behave differently in various products.

-A functionality may be redeveloped in various products.

-A change to a functionality in a certain product may not be propagated to the other products implementing it.

-A change to a functionality has to be repeatedly done on the products implementing it.

To cope the challenges and avoid the problems listed above, software developers rely on software reuse defined by Kang as "the process of implementing new software systems using existing software information" [KCH + 90].

" Software reuse is the process of creating new software by reusing pieces of existing software rather than from scratch.

[KRU92]

Code reuse is a practice that software developers rely on to save time and efforts by reusing predefined methods, ready-made libraries and off-the-shelf software components. Moreover, reuse can be applied on model components, architecture components, documentation and test cases. In software development, several approaches are adopted to enforce reuse, such as Model-Driven Engineering [Sch06, AR13], Component-Based Software Development [START_REF] Jifeng | Component-based software engineering[END_REF], Service Oriented Software Engineering [START_REF] Hongyu | Component-based and serviceoriented software engineering: Key concepts and principles[END_REF] and Feature Oriented Software Development [START_REF] Kyo | Feature-oriented product line engineering[END_REF][START_REF] Kästner | Feature-oriented software development[END_REF][START_REF] Apel | Feature-Oriented Software Product Lines[END_REF]. Moreover, ad-hoc reuse practices, such as copypaste-modify and clone-and-own are adopted by several organizations to derive new product variants [ZPXZ12, DRB + 13].

" The Feature-Oriented Reuse Method concentrates on analyzing and modeling a product line's commonalities and differences in terms of features and uses this analysis to develop architectures and components.

[KLD02]

In this dissertation, we focus on adopting reuse in feature-oriented software development. In this context, practically software reuse is performed either by applying the clone-and-own approach as a convenient and quick solution for light development projects [DRB + 13, LBC16] or Software Product Line Engineering as platform-based solution for complex development projects [CN01, TH03

Clone-and-Own Approach

Definition

Clone-and-own is an approach that consists on cloning an existing product variant, then modifying it to add and/or remove some functionalities, in order to obtain a new product variant [ZPXZ12, DRB + 13, FLLHE14, LBC16]. Due to the extensive existence of open source projects and public repositories, clone-and-own became the trending favorite and natural cloning approach adopted by software developers. Although cloning is done at different software development stages, it occurs more often at the code level [DRB + 13].

" The Clone-and-Own is a common practice in families of software products consisting of reusing code from methods in legacy products in new developments.

[LBC16]

Benefits and Drawbacks

Considering clone-and-own as a software reuse approach is due to the following benefits that it provides [DRB + 13]:

-The availability of the software variants that are generally hosted on public remote or local sites.

-The simplicity of cloning an existing software variant into a new one ready for modification.

-The rapidity to perform the clone and start the modification process.

-The specified and verified functionality already implemented in the cloned product variant.

-The freedom that the software developer benefits from to make any modification, without being dependent on the product variant from which the clone was made.

Although being a time and cost saving approach, clone-and-own confronts several drawbacks [DRB + 13]:

-The lack of information about the connection between clones.

-The difficulty in propagating changes made on a product variant to other product variants, due to the lack of connection information and the inability of automatically determining the product variants that require the change.

-The repetitive tasks performed on several product variants, for example, in order to propagate a change, which makes the maintenance process very expensive and complex.

-The incertitude in identifying the product variant(s) to be considered as the source for cloning.

-The lack of reuse tracking about the artifacts existing in several clones. This information is not consolidated except in the developers mind.

Despite its drawbacks, Dubinsky et al. [DRB + 13] showed through a study, conducted on six software product lines, and realized via code cloning, that C&O is widely adopted by software developers, who consider it the simplest and natural approach for reuse. They affirm that "it accelerates development, since they use what they already have; it saves time and, therefore, it saves money" [DRB + 13]. Moreover, in their study about industrial SPLs, Dubinsky et al. affirm that, any approach that can be considered as an alternative for cloning has to provide the simplicity and availability provided by cloning.

Since it is a fact that no alternative approach is more efficient than cloning in the early development stages of a family of software products, and clone-and-own is the predominant approach adopted by software developers, we focus on adopting clone-and-own as the starting point in any solution addressing product variants development.

OBJECTIVE 2:

ADOPTING CLONE-AND-OWN AS A STARTING POINT 2.3 Software Product Lines

Definition

Standard software products lack diversification and consequently fail to satisfy customer needs [START_REF] Pohl | Software Product Line Engineering[END_REF]. Taking into account customer requirements by delivering individualized products requires a large investment from the product developer and increases the development cost. Software product lines were invented as a solution that combines platform-based development and mass customization, allowing a reduction of the development cost and a large variety of products [START_REF] Pohl | Software Product Line Engineering[END_REF].

" A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

[CN01]

Using an SPL approach, a product is not implemented from scratch. Yet, it is integrated in the SPL by exploiting its variability mechanism, reusing components and adding the missing ones [START_REF] Trigaux | Software Product Lines : State of the art[END_REF].

" Core assets are those reusable artifacts and resources that form the basis for the software product line. Core assets often include, but are not limited to, the architecture, reusable software components, domain models, requirements statements, documentation, specifications, performance models, schedules, budgets, test plans, test cases, work plans, and process descriptions.

[NCB + 07]

Software Product Line Engineering

Software Product Line Engineering (SPLE) was raised on top of a theory born in 1980s based on increasing economy of scale by adopting a constructive reuse of software artifacts.

" Product line engineering is a process that delivers reusable compo- nents, which can be reused to develop a new application for the domain.

[TH03]

As per Northrop et al. [Nor02, NCB + 07], the product line development is composed of three main activities: (as shown in Figure 2.1) -Core asset development: the core asset development activity consists on developing the core assets to be used as ingredients for product derivation. This activity takes as an input the product constraints including the commonalities and variations, the production constraints and strategy defining how the product line is going to be built, and the preexisting assets. The output of the core asset development activity is the core assets themselves, in addition to the product line scope and the production plan that defines the process to be used to derive the products.

-Product development: the product development activity takes as an input the three outputs of the core asset development activity, in addition to the individual requirements of the product to be produced. The derivation of a product can affect the output of the core asset development activity; therefore, this process is iterative. The output of this activity is the products themselves.

-Management: the core asset development and product development activities must be accompanied by technical and organizational management. The technical management activity ensures that the core assets development and the product development activities follow the process defined for the product line. The organizational management defines the structure of the company and guarantees that its organizational units are receiving the required resources to build the product line.

"

The product line scope is a description of the products that will constitute the product line or that the product line is capable of including.

[NCB + 07] Figure 2.1: Software Product Line Activities [START_REF]Sei's software product line tenets[END_REF] Several works in literature [WL99, PBV05, DSB05, LSR07, ACR09] define a SPLE as a process composed of two sub processes: domain engineering or development for reuse, and application engineering or development with reuse. The first consists on defining the core assets while the second exploits the core assets to derive products. Each sub process is divided into a problem space that represents the features describing the products of the SPL and a solution space that implements those features using a variability mechanism. Figure 2.2 shows a framework for SPLE proposed by [START_REF] Pohl | Software Product Line Engineering[END_REF].

Domain Engineering

Domain engineering consists on defining the scope of the SPL, the common and variable functionalities provided by the SPL in a reference architecture, a variability model, the reusable artefacts, and the products implemented by the SPL. As per Pohl et al. [START_REF] Pohl | Software Product Line Engineering[END_REF], domain engineering is composed of the following sub-processes:

1. Product management: determine the scope of the SPL and a product roadmap identifying the common and variable features. " Domain engineering is the process of software product line engineer- ing in which the commonality and the variability of the product line are defined and realized.

[PBV05]

Arango defines domain engineering as a process composed of three domain activites [Ara89]:

1. Domain analysis: identify reusable information to be used to specify and implement the system.

2. Infrastructure specification: define the infrastructure of the reusable components.

3. Infrastructure implementation: implement the reusable components.

Application Engineering

Application engineering consists on exploiting the reusability defined in domain engineering in terms of common and variable artifacts to derive products from the SPL.

" Application engineering is the process of software product line en- gineering in which the applications of the product line are built by reusing domain artefacts and exploiting the product line variability.

[PBV05]

Pohl et al. [START_REF] Pohl | Software Product Line Engineering[END_REF] map the domain engineering sub-processes into the following application engineering sub-processes, used to derive an application from the SPL:

1. Application requirements engineering: identify the requirements specification of a particular application. A major concern is the identification of particular application requirements that are not part of the domain requirements. This situation may impact the SPL by affecting its artifacts to integrate those requirements and their related artifacts at the SPL domain engineering level.

2. Application design: configure the required parts of the domain architecture in order to specify the application design.

3. Application realization: create the application by selecting and configuring the reusable software components provided by the domain realization sub-process at the domain engineering level.

4. Application testing: validate and verify the derived application against its requirements specification.

Benefits and Drawbacks

As per Bosch [START_REF] Bosch | Introducing agile customer-centered development in a legacy software product line[END_REF], the key of success behind SPLs is reusability. He affirms that "the key success factor of software product lines is that it addresses business, architecture, process and organizational aspects of effectively sharing software assets within a portfolio of products" [CBK + 13]. Reusing artifacts during SPLE comes up with the following benefits [START_REF] Pohl | Software Product Line Engineering[END_REF]:

-The reduction of development cost since an artifact developed once, can be reused in several software products. Although an upfront investment is expensive compared to single system development, an impressive return on investment can be gained after delivering a certain number of systems, as shown in Figure 2.3.

-The improvement of software quality since an artifact used in several products is tested and its functionalities are verified in different implementations. Moreover, a detected bug can be corrected and the correction is propagated to the products employing the artifact. Consequently, a high software quality increases the customer trust.

-The shortening of delivery time by reducing the development cycle, since many existing artifacts can be reused instead of being developed from scratch. Figure 2.4 shows that developing common artifacts makes delivery of early developed systems slow, but as long as the architecture becomes mature, time to market becomes faster.

-A better domain understanding by applying a global analysis of requirements and an architecture covering the whole domain. This can help the organization to train its personnel on using the SPL. Despite its long term efficiency, adopting a SPLE approach is a difficult decision to take and can arise the following drawbacks [START_REF] Trigaux | Software Product Lines : State of the art[END_REF]:

-A resistance to change by the organization engineers and personnel since a shift to a new approach requires mental efforts.

-The missing of a global view of the whole architecture of the product line, while it is difficult to find an employee who knows the complete application domain.

-An expensive initial investment is required to establish an SPL, since it is specific for a single domain and requires mentality evolution and a high cost in terms of time and budget.

-The delayed benefits since an SPL provides a long term return on investment.

-A difficulty of adoption of a SPLE approach by small organizations that consider it a risk to take, especially when having short term deadlines with customers. Therefore, SPLE is mainly adopted by large organizations that support a large investment.

-A difficulty in evolving the SPL when adopting a classic approach, especially if the evolution is unplanned, because an evolution is about to affect the SPL structure. As per Weiss and Lai [START_REF] Weiss | Software Product-line Engineering: A Family-based Software Development Process[END_REF], SPLE is an up-front investment that performs well for long term, due to the systematic reusability that it provides. Therefore, we consider relying on it as the optimal and sustainable solution when dealing with a large family of products.

OBJECTIVE 3: RELYING ON SOFTWARE PRODUCT LINE AS A SUSTAINABLE SOLUTION

Variability Management

Parnas addressed variability when he defined program families as "a set of programs is considered to constitute a family, whenever it is worthwhile to study programs from the set by first studying the common properties of the set and then determining the special properties of the individual family members" [START_REF] Lorge | On the design and development of program families[END_REF]. The "special properties" stand for variability. Moreover, van Gurp et al. defined variability as "the capability to change and personalize a system" [START_REF] Jilles Van Gurp | On the notion of variability in software product lines[END_REF].

" The variability of a set of software systems or products is the set of differences, described in a structured way, of some or all of their characteristics.

[AR13]

Voelter and Groher [START_REF] Voelter | Product line implementation using aspectoriented and model-driven software development[END_REF] identified two kinds of variability: negative and positive.

-Negative variability: unrequired features are deselected from a "maximal" system containing the required features and some additional ones (see Figure 2.5a).

-Positive variability: features are added to a "minimal" core to construct the desired configuration (see Figure 2.5b). It is important to distinguish between variability at the software level and at the product line level [START_REF] Metzger | Software product line engineering and variability management: achievements and challenges[END_REF]. A software variability can be determined by the ability to personalize it or configure it, while product line variability is essential to capture the variable artifacts including requirements, architecture, components and tests, in order to allow their reuse. SPLE requires to define and manage variability during domain engineering, in order to exploit it to derive a variety of products during application engineering. In SPLE, variability is expressed in variation points that are subject to support multiple variable objects called variants [START_REF] Pohl | Software Product Line Engineering[END_REF]. Several variability modeling approaches exist, such as feature models [START_REF] Schobbens | Feature diagrams: A survey and a formal semantics[END_REF], decision models [START_REF] Schmid | A comparison of decision modeling approaches in product lines[END_REF] and orthogonal variability model [START_REF] Pohl | Software Product Line Engineering[END_REF].

Feature Model

As per Kang [KCH + 90], a feature is a user-visible aspect or characteristic of the domain. In SPLE, features are considered as the prime entities of software reuse [BLR + 15], providing an abstract representation of the commonalities and variabilities between the SPL products [START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF].

" A feature is a prominent or distinctive user-visible aspect, quality, or characteristic of a software system or systems.

[HER85]

The term Feature Model (FM) was defined in the Feature-Oriented Domain Analysis (FODA) feasibility study done by Kang et al. in 1990 [KCH + 90]. A feature model is an abstract presentation of all the SPL products in terms of features. It is defined by a feature diagram and a set of constraints. A feature diagram is an hierarchical tree diagram that shows the features and the relationships between them. A feature diagram has a root feature. The relationships between features are defined as parental relationships such as mandatory, optional, or, alternative, and cross-tree constraints such as requires and excludes. A survey on the different FM semantics is presented in [START_REF] Schobbens | Feature diagrams: A survey and a formal semantics[END_REF] and [START_REF] Schobbens | Generic semantics of feature diagrams[END_REF].

" A feature model represents the standard features of a family of systems in the domain and relationships between them.

[KCH + 90] Figure 2.6a shows a feature model extracted from [START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF]. We address this sample mobile phone FM to present and explain the different components, relationships and constraints that may occur in a given FM:

-Root feature : the root feature is the feature representing the concept that describes the model and englobes all its characteristics. The feature Mobile Phone in the given example englobes the characteristics Calls, GPS and so on.

-Parental relationships :

-Mandatory: a mandatory relationship between a parent feature and a child feature means that the child feature is present in all products where the parent feature is present. The given FM example shows that all products -which are mobile phones -allow Calls functionality and have a Screen.

-Optional: an optional relationship between a parent feature and a child feature means that the child feature can optionally be present in all products where the parent feature is present. Some, but not all mobile phones in the given example support GPS.

-Alternative: an alternative relationship between a group of features and a parent feature means that only one feature of the group can be selected when the parent feature is present. A mobile phone can have one and only one screen that can be either Basic, Colour or High resolution screen.

-Or: an or relationship between a group of features and a parent feature means that one or more features of the group can be selected when the parent feature is present.

A mobile phone that supports Media can have Camera, MP3 or both.

-Cross-tree constraints:

-Requires: a requires relationship directed from a feature f1 to a feature f2 means that each product containing f1 must contain f2. A mobile phone that includes a Camera must have also a High resolution screen.

-Excludes: an excludes relationship between two features f1 and f2 means that f1 and f2 cannot be present in a same product. No mobile phone has GPS with a Basic screen. In our dissertation, we are interested in constructing a feature model, allowing the configuration of existing products by selecting the required features. Moreover, we are interested in exploring negative and positive variability in order to enable the construction of new products.

OBJECTIVE 4:

MODELING VARIABILITY THROUGH A FEATURE MODEL

Product Configuration

A configuration is a selection of a collection of features that respect the constraints imposed by the FM and generally reflect an SPL product. It is defined by Junker as "the task of composing a customized system out of generic components" [START_REF] Junker | Preference-based problem solving for constraint programming[END_REF].

" A final fully-specific feature model with no points for further cus- tomization is called a configuration of the feature model based on the selected features.

[BEG + 11]

A configuration process is done during application engineering. As per Faltings et Freuder, software developers use standardized software components that can be configured into products to respond to the customer requirements. They consider that a configuration must be correct, optimal and quickly produced in order to maintain customers [START_REF] Faltings | Configuration [Guest Editor's Introduction[END_REF].

Li et al. [START_REF] Li | Feature configuration modeling and problem solving for software product line[END_REF] define the product configuration as a design activity that takes the configuration models and the requirements as an input and outputs a configuration result oriented to the ultimate product.

According to Botterweck and Pleuss, "a product is defined by a product configuration, which resolves the variability by selecting from the given variants while considering the defined constraints. In the case of a feature model, this is done by selecting or eliminating features" [START_REF] Botterweck | Evolution of Software Product Lines[END_REF].

Figure 2.6b shows a configuration of the corresponding FM in Figure 2.6a. Selecting the feature GPS enforces an automatic deselection -if selected -of the feature Basic and disables its selection, since an exclude constraint exists between GPS and Basic. Selecting the feature Camera enforces the selection of the feature High resolution and deselects -if any is selected -and disables the features Basic and Colour, since a requires constraint exists between Camera and High resolution. We call this configuration a valid configuration, since it reflects the implementation of the selected features in one of the SPL products.

As per Czarnecki et al. "a feature model describes the configuration space of a system family" [START_REF] Czarnecki | Staged configuration using feature models[END_REF]. A configuration space is defined as the set of all possible configurations from a FM [START_REF] Martinez | Mining software artefact variants for product line migration and analysis[END_REF]. Table 2.1 shows the configuration space corresponding to the FM of Figure 2.6.

Product Derivation

Features are an abstraction of the implementation of reusable assets [START_REF] Czarnecki | Mapping features to models: A template approach based on superimposed variants[END_REF]. A product derivation is based on the product configuration and the feature mappings to the corresponding assets [START_REF] Botterweck | Evolution of Software Product Lines[END_REF].

" Product derivation is a key process in application engineering and addresses the selection and customization of assets from the product line (utilizing the provided variability) to satisfy customer or market requirements.

[DSB05]

Product derivation can lead to an automated derivation of an existing product, in case the set of required features correspond to a valid configuration. However, to respond to the arising customer requirements, negative and positive variability can be used to derive new products [START_REF] Voelter | Product line implementation using aspectoriented and model-driven software development[END_REF] (see Figure 2.5). The former is achieved by removing some unrequired features from a maximal product, that implements the required features and more. While, the latter is achieved by using a minimal core to add additional features required for the derivation and not contained in the core [START_REF] Martinez | Mining software artefact variants for product line migration and analysis[END_REF].

Summary and Contribution Decisions

In this chapter, we have seen that reuse is the solution to respond to the mass customisation necessity. Therefore, any contribution is supposed to explore reuse as much as possible to gain its efficiency. Earlier in this chapter, we presented two approaches for reuse which are C&O and SPLE, and we highlighted on the benefits and drawbacks of each. Before making our contribution choices, we compare the presented approaches according to literature, regarding the development challenges identified at the early beginning of the chapter:

-Cost & Effort: it is most likely to face a high development cost and effort in the early development phase in both C&O and SPLE, since the artifacts are usually created from scratch. According to Dubinsky et al., when C&O is adopted, the cost and effort decrease due to the quick and easy clone process, however, when the number of products becomes significant, the cost and effort to derive a new PV increase dramatically, since it becomes very difficult to determine which PV to use as the source of clone [DRB + 13]. Moreover, the required functionalities for the product to derive might be propagated into different PVs which can make the collection of the required functionalities a tedious task [START_REF] Lapeña | Towards clone-and-own support: locating relevant methods in legacy products[END_REF].

For SPLE, according to Pohl et al., the development of artifacts in domain engineering phase makes the cost and effort expensive for the starting phase, however, as long as the SPL becomes mature, the cost and effort decrease due to reusability [START_REF] Pohl | Software Product Line Engineering[END_REF].

-Quality: in C&O, software quality starts high for early delivered PVs, since clones are subject to test and corrections. However, the quality starts to decrease when a considerable number of variants is produced, especially when organizations are committed into short delivery periods. Further, quality decreases since a correction done on a variant might not be propagated to other variants, due to the missing traceability of the corrected functionality in the other variants [START_REF] Fischer | Enhancing clone-and-own with systematic reuse for developing software variants[END_REF]. On the other hand, software quality in SPLE is considered higher than C&O, since artifacts are subject to test during domain engineering and later on during application engineering before delivering the product. This quality keeps increasing as long as the SPL becomes mature since artifacts reused in several products gain more trust to PVs [START_REF] Pohl | Software Product Line Engineering[END_REF].

-Delivery: in SPLE the delivery time for the early developed products is considered very high compared with C&O due to the up-front investment of creating artifacts that can be reused by several products. The delivery time decreases in C&O due to cloning, then increases dramatically when identification of the variant to clone becomes ambiguous and the required functionalities propagated on different variants without being able to easily identifying those variants. This makes the collection process of those functionality from the existing variants a very tedious mission that delays considerably the delivery time [DRB + 13]. In SPLE, reusability of artifacts allows to maintain a low delivery time [START_REF] Trigaux | Software Product Lines : State of the art[END_REF].

-Maintenance: the maintenance effort in C&O is proportional to the number of variants produced. As long as the number of variants increases maintenance becomes difficult [START_REF] Fischer | Enhancing clone-and-own with systematic reuse for developing software variants[END_REF]. From a side, its difficult to identify the variants to propagate the maintenance in, and from other side it is expensive to repeat the same maintenance process on the identified variants that require the modification. For SPLE, it is considered much less expensive to make a maintenance since architecture of the SPL is well structured and reusable components are identified [START_REF] Pohl | Software Product Line Engineering[END_REF]. However, it is still challenging to propagate a maintenance on several products, since a functionality may behave differently in different products and therefore the maintenance must be done precisely and supplemented by testing [START_REF] Botterweck | Evolution of Software Product Lines[END_REF].

The comparison between C&O and SPLE shows that C&O performs well in early development stages, but turns into an expensive solution when the family of products delivered become rich. On the other side, SPLs are adopted due to their long term return on investment and they are considerably expensive in the early development stage.

Since, from a side C&O is the optimal approach for starting the development of a family of software products, and SPLE is a sustainable solution, an effective contribution must adopt C&O in early development stages then integrate the family of products into a systematic SPL when it starts to consolidate its foundation. Nevertheless, C&O remains essential when unplanned new products have to be derived.

OBJECTIVE 5: COMBINING CLONE-AND-OWN AND SOFTWARE PRODUCT LINE

Minimizing cost and effort can be achieved by guiding the identification of the possible sources of clone and the selection of the required assets for derivation. In fact, when identifying the assets that do not require modification, we save the derivation from lacking into an intensive cloning process. Relying on the SPL artifacts as source for cloning improves quality and trust in code, since it corresponds to code tested and subject to reuse. SPLs enable an automated derivation of existing products ensuring fast delivery. Moreover, employing C&O to derive a new product from the SPL can shorten the delivery time if the necessary guidance is offered. Maintenance within an SPL context is favorable since artifacts are used in several products, hence, integrating the newly derived products in the SPL is a must.

In Chapter 4 we demonstrate the migration process of our approach, in which we propose the migration of PVs into an SPL.

Software Product Line Adoption

Migrating from the development of single and independent software product variants using clone-and-own approach, to a structured software product line raises the following questions:

1. What is the approach to adopt for migration?

2. What are the required steps to accomplish the migration?

3. What is the accurate moment to proceed the migration?

Migration Approach

Krueger [START_REF] Krueger | Easing the transition to software mass customization[END_REF] distinguished three models for adopting software mass customization by means of a software product line, which are proactive, reactive and extractive.

-Proactive approach: the organization builds a complete SPL that takes into consideration the current and expected customer requirements that belong to the scope of the SPL. The common and variable features are identified, their corresponding assets are implemented, and the possible products are defined. This approach requires the maximum effort from the organization, because the SPL is fully created before starting the product derivation process.

-Reactive approach: the organization creates a minimal SPL to start deriving products.

The SPL is incrementally evolved in reaction to the upcoming customer requirements. The reactive approach imposes less initial effort compared with the proactive approach.

-Extractive approach: the organization uses existing product variants in order to extract the common and variant artifacts, identify the features and create a corresponding SPL. This approach allows a quick SPL adoption by the high level of software reuse that it provides.

In our approach, we are interested in migrating existing PVs developed in C&O into an SPL. Thus, we care about performing an extractive migration approach.

OBJECTIVE 6: EXTRACTIVE MIGRATION APPROACH

Migration Steps

Anwikar et al. [START_REF] Vallabh Anwikar | Domain-driven technique for functionality identification in source code[END_REF] define the migration as a process of three phases:

1. Detection phase: extract from source code information about the structure and the various functionalities implemented.

2.

Analysis phase: use the information gathered in detection phase to create new partitions that identify and separate the features.

3. Transformation phase: use the knowledge gathered in analysis phase to produce the SPL by transforming the legacy applications into separated layered modules of source code to allow artifacts reuse.

Martinez et al. [START_REF] Martinez | Mining software artefact variants for product line migration and analysis[END_REF] identify the activities required for achieving an extractive SPL adoption as follows (see Figure 3.1):

1. Feature identification and naming: Martinez considers the identification of the features implemented in the existing product variants as part of the initial activity. Despite of being possible that the software developer manually identifies the features by traversing the artifacts of the product variants, Martinez highlights on the need for a mechanism to identify those features when dealing with complex products, where functionalities are provided by different stackholders. A manual identification of the features is supplemented by a manual naming of the identified features. However, when an identification mechanism is performed, Martinez et al. offer a word cloud visualization mechanism to help software developers in naming the identified features.

2. Feature location: if features are manually identified by software developers, feature location has to be performed. This activity consists on the identification of the assets associated to each feature.

3. Feature constraints discovery: this activity consists on discovering the constraints between the identified features, in order to ensure the validity of the configurations of the FM to be created.

4.

Feature model synthesis: after identifying the features and the constraints between them, a structured FM is created, allowing the automated derivation of existing products and the ones reflecting valid configurations made on the generated FM.

5.

Reusable assets construction: the implementation elements associated to each feature are used to construct the reusable assets in order to be employed during future derivations. Al-Msie'Deen et al. [START_REF] Al-Msie'deen | Reverse Engineering Feature Models from Software Variants to Build Software Product Lines[END_REF] defined SPL adoption as a process of reverse engineering a feature model from software variants. Their approach consists of the following steps:

1. Extracting feature implementations from source code and use-case diagrams of the software variants.

2. Documenting the mined feature implementations using use-case diagrams.

3. Constructing the feature model and its constraints from the mined and documented features.

Based on the related work approaches, we synthesize three main steps to be performed in order to construct the SPL during the migration process:

1. Identifying features 2. Mapping features to assets

Constructing a feature model

In the upcoming subsections, we detail the different techniques adopted in literature to perform each step, and we identify our contribution choices regarding each step.

Identifying Features

Martinez et al. [START_REF] Martinez | Mining software artefact variants for product line migration and analysis[END_REF] consider that it is very idealistic to assume that the features implemented by the PVs are identified or can be obtained from domain knowledge prior to migration. When features are not manually identified, a technique called feature identification is performed in order to identify the features implemented by the PVs and their corresponding implementation elements [START_REF] Antoniol | Feature identification: An epidemiological metaphor[END_REF].

" Feature identification is defined as the activity of identifying the source code constructs implementing a given feature. BUT4Reuse performs feature identification if features are not identified prior to migration. The process analyzes the product variants artifacts and specifies separated blocks that stand for the identified features. The framework illustrates the common and varying blocks. It constructs the blocks separately, to be known as reusable assets and allows to associate each of them to a feature. BUT4Reuse helps domain experts in feature naming task, through the word clouds visualization functionality that it provides. The content of the identified blocks is analyzed, and a weight is given to each word corresponding to its occurrence in the block content. As represented in Figure 3.2, the word having the highest occurrence will be displayed with the largest font size, and so on.

When feature identification is performed, feature naming is required in order to assign a name for each identified feature from the analyzed artefacts. While some approaches propose automatic feature naming [DDH + 13, IRBW16], or help the domain experts in choosing the corresponding name [START_REF] Martinez | Mining software artefact variants for product line migration and analysis[END_REF], other approaches [YPZ09, AM14, MAGDC + 16] keep feature naming as a manual task. This task might be expensive, since it requires a lookup on the artifacts corresponding to each identified feature, in order to designate a meaningful naming to the features. Kästner et al. [START_REF] Kästner | Variability mining: Consistent semi-automatic detection of product-line features[END_REF] developed a tool called variability mining. The goal behind the tool is to facilitate the adoption of an extractive SPL by helping the developer to locate, document and extract the implementations of the features in a semi-automatic way. Liu et al. [START_REF] Liu | Feature oriented refactoring of legacy applications[END_REF] developed a theory based on feature oriented refactoring, which consists on decomposing a program into features. The theory identifies the relationship between features and their implementations. Approaches proposed in [START_REF] Liu | Feature oriented refactoring of legacy applications[END_REF][START_REF] Kästner | Variability mining: Consistent semi-automatic detection of product-line features[END_REF] identify feature information from a single product in contrary to [START_REF] Martinez | Mining software artefact variants for product line migration and analysis[END_REF] that concentrate on identifying features from several product variants. Several works in literature that propose to migrate PVs into an SPL [AM14, RC12], or to support C&O [START_REF] Fischer | The ecco tool: Extraction and composition for clone-and-own[END_REF][START_REF] Rubin | A framework for managing cloned product variants[END_REF][START_REF] Lapeña | Towards clone-and-own support: locating relevant methods in legacy products[END_REF], assume that features are determined by domain experts [START_REF] Fischer | The ecco tool: Extraction and composition for clone-and-own[END_REF] or extracted from requirements documentation [START_REF] Lapeña | Towards clone-and-own support: locating relevant methods in legacy products[END_REF] or use-case diagrams [START_REF] Al-Msie'deen | Reverse Engineering Feature Models from Software Variants to Build Software Product Lines[END_REF].

Feature identification techniques rely on implementation artifacts without taking into account business-level features. Moreover, the proposed feature naming techniques [Mar16, DDH + 13, IRBW16] rely on source code and implementation artifacts to extract or propose names for the identified features, which might reflect a technical not a business-level perception of the implemented features. Kang et al. define features as "the attributes of a system that directly affect end-users" [KCH + 90]. In our dissertation, we do not contribute in or employ feature identification, since we consider that features reflect the user business requirements, and therefore, they are supposed to be given by domain experts instead of being identified through automatic feature identification techniques.

OBJECTIVE 7: BUSINESS-LEVEL FEATURE IDENTIFICATION

In the migration process that we propose in Chapter 4, we assume that features implemented by each product are known prior to its migration into the SPL.

Mapping Features to Assets

Ji et al. affirm that "to effectively evolve and reuse features, their location in software assets has to be known" [START_REF] Ji | Maintaining feature traceability with embedded annotations[END_REF]. Hence, when features are identified, the next step is to locate the implementation of the features in the variant artifacts. In other words, it is about mapping the identified features to the PVs assets.

Several works in literature proposed to analyze and compare the artifacts of the product variants to identify their common and variable parts [Mar16, FLLHE14, AmSH + 13, RC12]. Thus, determining the coexistence between the features and the identified parts of the product variants allows to establish the mapping between them. The identified parts are called blocks in [START_REF] Vallabh Anwikar | Domain-driven technique for functionality identification in source code[END_REF][START_REF] Martinez | Mining software artefact variants for product line migration and analysis[END_REF], clusters in [START_REF] Yang | Domain feature model recovery from multiple applications using data access semantics and formal concept analysis[END_REF], regions or parts in [START_REF] Rubin | Combining related products into product lines[END_REF], modules in [FLLHE14, MAGDC + 16], and atomic blocks or object-oriented building elements sets in [START_REF] Al-Msie'deen | Reverse Engineering Feature Models from Software Variants to Build Software Product Lines[END_REF].

" A block is a set of implementation elements of the artefact variants that are relevant for the targeted mining task.

[MAR16]

Feature location is an activity that identifies mappings between features and assets. Dit et al. define feature location as "the activity of identifying an initial location in the source code that implements functionality in a software system" [START_REF] Dit | Feature location in source code: a taxonomy and survey[END_REF].

" Feature location techniques aim at locating software artifacts that implement a specific program functionality, a.k.a. a feature. Rubin and Chechik [START_REF] Rubin | A survey of feature location techniques[END_REF] made an overview of twenty-four feature location techniques and their underlying technologies such as Formal Context Analysis (FCA) [START_REF] Belohlavek | Introduction to formal concept analysis[END_REF] and Latent Semantic Indexing (LSI) [DDF + 90]. They show that all techniques studied and compared in their survey treat the products as individual independent entities and not as a family of related entities. Hence, they affirm that taking into consideration commonalities and variations of the related products can improve the accuracy of the adopted techniques by initially partitioning the code into unique part to the product and shared parts. Moreover, they highlight on the need of an incremental analysis of the traceability between features and asset to save the efforts of re-analyzing.

The survey made by Assunção et al. [START_REF] Klewerton | Feature location for software product line migration: a mapping study[END_REF] shows that the research about feature location techniques is on a continuous growth since 2010. The survey shows that 47% of the related techniques focus on detection phase, 43% on analysis and 10% on transformation. Most techniques consider source code artifacts as the main input, with some focus on other artifact types such as design models, requirements and documentation. The output of the proposed techniques can be divided into commonalities and variability information, feature mapping to elements, feature models, and source code reorganization.

Based on the conclusion made by Rubin et al. [START_REF] Rubin | A survey of feature location techniques[END_REF] in their survey about feature location, our approach aims to establish mappings between features and assets, by taking into consideration the entire product line instead of treating products separately to identify the mappings.

OBJECTIVE 8: GLOBAL MAPPING BETWEEN FEATURES AND ASSETS

Beside providing feature identification, Martinez et al. enable in their approach to perform directly feature location in case features are known [MZKLT14, MZM + 14, MZB + 15b, MZB + 15a, Mar16, MZB + 16, MZB + 17]. When performing feature location, their framework BUT4Reuse works on several artifact type variants such as Java projects, UML, JSON, text files, images and more. For each artifact type an adapter is required and the framework supports currently fifteen adapters. It takes as an input the existing product variants and chooses automatically the appropriate adapter corresponding for the artifact type of the variants. AL-Msie'Deen et al. [AM14, RSH + 13, SHU + 13] proposed an approach called REVPLINE that stands for REengineering Software Product Variants into Software Product LINE. REVPLINE aims to mine features from object-oriented based product variants. The approach uses Formal Concept Analysis to identify the common blocks and blocks of variations between the product variants and relies on Latent Semantic Indexing [DDF + 90] to determine the similarity between the object-oriented building elements. The approach exploits the source code of the mined features and use cases in order to provide a name and a description to the feature. This information is used then to construct the feature model of the SPL.

Fischer et al. [START_REF] Fischer | Enhancing clone-and-own with systematic reuse for developing software variants[END_REF], in the context of their approach to enhance C&O, consider that features are provided by domain experts with the product variants in which they are implemented. They define an algorithm to compare the provided PVs and identify their commonalities and variability. The identified parts called modules are categorized into base modules that refer to artifacts implementing a feature without any feature interactions, and derivation modules that refer to artifacts implementing feature interactions. Feature interaction occurs when two or more features are totally or partially implemented by a common artifact. Similarly to the approach proposed by Martinez et al. [START_REF] Martinez | Mining software artefact variants for product line migration and analysis[END_REF], this approach supports also different artifacts types, and employs the appropriate adapter corresponding for the artifact type of the variants.

" A feature interaction is a situation in which two or more features exhibit unexpected behavior that does not occur when the features are used in isolation.

[AK09]

A language-independent approach called ExtractorPL is proposed by Ziadi et al. [ZHP + 14], as a reverse engineering approach for creating an SPL from existing software variants. The approach consists on extracting the features by identifying the variability among the product variants, regrouping the identified features in a feature model, and mapping the features to their corresponding source code blocks.

The specific artifact type adapters employed in [MZB + 15b] and [START_REF] Fischer | Enhancing clone-and-own with systematic reuse for developing software variants[END_REF] perform well when the family of products consists of monoglot variants or specific adapters exist for their corresponding artifacts. In our approach, we give interest as well in polyglot variants such as web applications, that are written using different languages and consist of artifacts of different formats, where some may contain blocks of code of different languages. Therefore, we aim to introduce a language-independent mechanism to establish mappings between features and assets when polyglot variants are used, without limiting our approach to the proposed mechanism, especially when monoglot variants are integrated and specific adapters are pertinent to capture their mappings.

OBJECTIVE 9: LANGUAGE-INDEPENDENT MAPPINGS IDENTIFICATION

According to Botterweck and Pleuss [START_REF] Botterweck | Evolution of Software Product Lines[END_REF], mapping between features and the assets implementing them is required. This mapping is more complex than a one-to-one relationship, since a feature is most likely mapped to different assets. Further, the theory proposed in [START_REF] Liu | Feature oriented refactoring of legacy applications[END_REF] identifies the relationship between features and their implementations, and proves that a feature can have different implementations.

We consider that a feature can be implemented through several assets, while an asset can contribute in the implementation of several features. Therefore, a many-to-many relationship between features and assets is likely to occur. In our dissertation, we give interest to deal with similar cases. Moreover, we consider that a feature can have different implementations, due to the interaction between the feature and the other features implemented in the corresponding product. The presence of a feature in a product, and its absence in another, might affect the implementation of other features implemented by the same products due to features interactions. One of the strength points of the approaches proposed in [MZB + 15b] and [START_REF] Fischer | Enhancing clone-and-own with systematic reuse for developing software variants[END_REF] is that they take into consideration features interactions. Hence, in our approach, we are interested in capturing features interactions. + 16] define an SPL as as triple composed of specifications where features are represented in a feature model, implementations where assets are represented in a components model and traceability relationships between features and assets. They define reasoning operators to identify the state of the SPL and investigate traceability between features and assets. For instance, an SPL is valid if there exists a specification and an implementation. In another example, an implementation realizes a specification, if the implementation assets implement all and only the features of the specification. Moreover, an implementation covers a specification, if the implementation assets implement all and more than the features of the specification.

Narwane et al. [KNGDNK

In our approach, we are interested in integrating the functionalities of some operators from [START_REF] Rubin | A survey of feature location techniques[END_REF] and [KNGDNK + 16], in a context that serves the objectives of our contributions. For instance, operators such as findFD from [START_REF] Rubin | A survey of feature location techniques[END_REF] to find the features implemented by a variant, realizes and covers from [KNGDNK + 16] are necessary to fulfill the objectives of our approach.

Ji et al. [START_REF] Ji | Maintaining feature traceability with embedded annotations[END_REF] propose a lightweight code annotation approach. Their approach consists of embedding annotations about the features directly into the source code of the assets. A study of their approach on a product line of cloned product variants, shows that the cost of adding and maintaining annotations is small compared to the actual development cost. Hence, their approach provides a low-cost feature location through annotations, and reduces maintenance efforts, since annotations co-evolve with assets.

We recognize that the approach proposed by Ji et al. [START_REF] Ji | Maintaining feature traceability with embedded annotations[END_REF] is a lightweight and effective solution that maintains incremental mappings between features and assets. However, we consider that to gain the effectiveness from their approach, it must be adopted from scratch, from the moment where the assets of the first product are developed. However, in our approach, we are interested in migrating pre-developed product variants into an SPL and thus, annotating source code of several variants that share features in common can be considered tedious and error-prone. Otherwise, the proposed annotations approach can give an effective return on investment if done from scratch.

In Chapter 4 we define a language-independent mechanism to identify mappings between features and assets, and we call them correlations.

Constructing a Feature Model

A method to extract a domain feature model from existing product variants is proposed by Yang et al. [START_REF] Yang | Domain feature model recovery from multiple applications using data access semantics and formal concept analysis[END_REF]. The method uses data access semantics and Formal Concept Analysis (FCA) [START_REF] Wille | Introduction to formal concept analysis[END_REF][START_REF] Belohlavek | Introduction to formal concept analysis[END_REF] to establish the relationship between the features and their implementations. Yang et al. consider feature naming as a manual task to be done by domain experts by examining the generated features and evaluate its business meaning.

Martinez et al. [START_REF] Martinez | Mining software artefact variants for product line migration and analysis[END_REF] proposed an approach for constraints discovery that can be generalized on several artifact types. In their approach, constraints between the identified features are automatically discovered in order to allow the creation of a feature model that enables valid configurations. The feature model generated by the proposed framework BUT4Reuse, is explored using the FeatureIDE tool [TKB + 14] in order to configure new products.

Acher et al. [START_REF] Acher | multiple feature models: foundations, languages and applications[END_REF] designed a set of composition and decomposition operators to manage multiple FMs. For instance, a merge operation permits to construct a feature model by merging several ones [START_REF] Mathieu Acher | Familiar: A domain-specific language for large scale management of feature models[END_REF]. Moreover, they developed a textual language called FAMILIAR with a tool offering a practical solution to manage FMs.

In Chapter 4 we construct the SPL feature model by applying a FAMILIAR merge opera- tion [START_REF] Mathieu Acher | Familiar: A domain-specific language for large scale management of feature models[END_REF] on the feature models provided with the migrated PVs. Similarly, as presented in Chapter 7 after the integration of a newly derived product, this merge operation is used to merge the product FM with the SPL FM, to keep the latter up-to-date.

Migration Moment

As presented in Chapter 2, the large investment in terms of cost and time for building an SPL from scratch, made it an undesired option for an initial development approach. Consequently, an expensive migration to SPL adoption would be undesired too. To determine the accurate moment to migrate PVs into an SPL, we refer back to Figure 2.3 that compares the development cost between single systems and system family. Figure 2.3 shows that approximately after the development of three software systems, the product line engineering approach can provide a lower cost per system. We refer to this indicator to set the following hypothesis: Migrating PVs into an SPL is preferred to be done once the family of products starts to consolidate its foundation. We mean by this, when the family of products is composed of few products, implementing a set of functionalities, where some of them are common and others are variable. We do not set a specific number of products to determine the accurate migration moment, but we consider that once the number of products reaches three, it is recommended to migrate them into an SPL, in order to overtake the challenges confronted during C&O. A smooth and quick migration process is required, in order not to affect the productivity of the development unit.

OBJECTIVE 11: SMOOTH MIGRATION IN THE ACCURATE MOMENT

Product Derivation Support

BUT4Reuse [MZB + 15b, MZB + 16], the framework proposed by Martinez et al. generates a feature model that allows the automated derivation of the product variants migrated into an SPL. In addition, the generated FM permits an automated derivation of new variants as long as the set of selected features during the configuration of the FM does not break the FM constraints. The approach does not guarantee the derivation of a complete product, and does not provide a support to complete it.

Fischer et al. developed the ECCO approach, which stands for Extraction and Composition for Clone-and-Own [FLLHE14, FLLHE15, LHLE15, LLHE16]. They give interest to developers that initially adopt C&O to produce software variants. According to them, management and maintenance of the software variants soon becomes ineffective [START_REF] Fischer | Enhancing clone-and-own with systematic reuse for developing software variants[END_REF]. Therefore, they propose ECCO, as an approach that integrates software variants to provide a systematic reuse and helps software engineers to derive new variants by proposing the necessary hints. The proposed hints can either inform developers of the existence of surplus artifacts that have to be removed manually, or the need of reordering some artifacts in case several possible ordered were detected. The workflow of the ECCO approach is shown in Figure 3.4. First, it takes as an input the existing product variants, and the features assigned to each variant. Therefore, feature identification is considered as a manual task and the initial task performed by ECCO is feature location. This task consists on the extraction of the implementation artifacts called modules and tracing them to their corresponding features and features interactions. The traced information is used to identify the relationships between the modules called associations. A configuration of features leads to the composition which uses the associations to construct a product. If the constructed product refers to an existing variant, it is automatically generated as a complete product. Otherwise, it is considered as a composed incomplete product and requires a manual completion. A product is considered incomplete, either if some features or feature interactions did not exist earlier in existing variants, or they always appeared together in same variants, and need to be separated. During this phase, ECCO provides the software engineer with some guiding hints to finalize the product construction. Such hints can inform the software engineer for example, that some modules had never appear separately and need to be separated, or for a set of artifacts multiple ordering options are available. When a new variant is completed, it is integrated in ECCO, where it can be used in future product derivations. Despite the efficiency of the approach proposed by Fischer et al. [START_REF] Fischer | Enhancing clone-and-own with systematic reuse for developing software variants[END_REF] in enhancing and supporting the derivation of PVs based on C&O, we consider that it limits the freedom that software engineers are supposed to benefit from when adopting C&O. Their approach seeks to provide a systematic reuse by automating the derivation of product variants whenever possible. Although they allow developers to make their decisions when completing an incomplete product based on the proposed hints, they offer them a single derivation solution which is the constructed product. In other words, their approach limits developers' decisions to low level decisions, while the proposed solution is imposed on them. When the tool proposes an uncomplete product, that requires a manual completion, the software developer accomplishing this task might find in hands some proposed assets that she is not familiar with or never worked on. Hence, developers are not able to recognize how the proposed product was constructed, and to which product variants the assets collected to construct it belong. In fact, developers lose decision-making and freedom to build a new unplanned product by themselves, and thus, they lose somehow the ownership meaning of the derived product.

Lapeña et al. [START_REF] Lapeña | Towards clone-and-own support: locating relevant methods in legacy products[END_REF][START_REF] Lapeña | Improving feature location by transforming the query from natural language into requirements[END_REF][START_REF] Manuel Ballarin | Leveraging feature location to extract the clone-and-own relationships of a family of software products[END_REF][START_REF] Lapeña | Analyzing the impact of natural language processing over feature location in models[END_REF] consider that C&O consumes high amounts of time and effort. Therefore, they propose an approach called Computer Assisted Clone And Own (CACAO) to assist C&O. This approach takes as input the product variants in addition to their documented natural language requirements. The goal of the approach is to support software engineers when deriving new product variants. Hence, when a new product has to be derived, the requested documented requirements are provided. CACAO extracts keywords from the new requirements and from the existing product variants requirements using POS Tagging techniques [START_REF] Hulth | Improved automatic keyword extraction given more linguistic knowledge[END_REF]. Next, it detects which existing product variants are closer to the product ]. Finally, it determines which are the source code methods of the existing product variants, that are closer to the requested requirements, by employing Fine Grain Latent Semantic Indexing (FG-LSI). Hence, CACAO provides ranking at two levels, which are products level and methods level. The product relevancy ranking allows software developers when deriving a new product, to decide if they rely on the product variants that they are familiar with, a mixture between known and unknown variants, or non-familiar products having the highest ranking. The code relevancy ranking provides software engineers with the most relevant methods for each of the new product requirements.

We express our interest in three main contributions of the approach proposed by Lapeña et al. The support provided to software developers to help them in choosing the relevant products and methods to derive a product, by first proposing the different possible solutions, second keeping the decision-making to software developers without imposing a solution on them, and third by ranking the products and methods to help them make their decisions. On the other hand, we consider that their approach misses an additional details level, that can be achieved by providing the several combinations of products that can lead to the new product to derive, with the operations to be performed on the identified methods such as removing or extracting features from them.

In our approach, we aim to guide software engineers in deriving new products, by providing them with the different possible scenarios that they can rely on to derive the new product, and the different possible operations to perform on their assets such as removing or extracting features from them.

OBJECTIVE 12: SUPPORTING DERIVATION WITH THE POSSIBLE SCENARIOS

In Chapter 5 we demonstrate how we support the derivation of new product variants by providing for each configuration its configuration scenarios and operations to perform.

Based on the required features, many might be the scenarios that can be achieved to derive a new product. In order to tackle complexity and facilitate the choice of software engineers in selecting the relevant products and operations to perform to derive the desired product, we aim to define indicators that allow to estimate the cost of the proposed operations, thus, software engineers can rely on the estimated cost of the operations to choose the appropriate ones to construct the new product.

OBJECTIVE 13: COST-ESTIMATED DERIVATION

In Chapter 6 we define indicators that allow to estimate the cost of the operations to perform.

We provide cost-estimation to software engineers to facilitate their choice.

We consider that automated derivation can degrade ownership level and trust of developers in the newly derived products. To maintain the freedom that software developers benefit from when deriving new products based on clone-and-own, we provide them with the possible solutions and keep to them the decision-making in choosing the relevant solution. Since the number of possible solutions might be large, we aim to tackle complexity and facilitate decisions, by allowing software engineers to select the derivation scenario to construct a new product based on their own preferences.

OBJECTIVE 14: SOFTWARE ENGINEERS AS DECISION MAKERS

In Chapter 7 we demonstrate how we support software engineers in achieving the derivation of new product variants based on selection factors which are developer preferences and cost estimation.

Software Product Line Evolution

According to Botterweck and Pleuss [START_REF] Botterweck | Evolution of Software Product Lines[END_REF], SPL evolution is complex due to the variability and the interdependencies between products. A new requirement or change in a requirement may affect several products. A change affects the whole product family and the related products and the SPL remains inconsistent until change is propagated. Moreover, a large interdependency exists between assets. Therefore, SPL evolution must be addressed in a systematic way. An SPL must evolve to reflect the new and changing requirements. Therefore, the more products it derives, the more expensive it becomes.

During SPL evolution, different abstraction levels must be taken into consideration [START_REF] Schmid | A requirements-based taxonomy of software product line evolution[END_REF]:

(1) common assets defined at the SPL level, being part of all products, (2) variable assets that are part of some products and there contribution in a product is based on a variability decision and (3) product-specific assets that are part of an individual product and are not made for reuse. During evolution, assets can be added, modified and deleted. Therefore, any change can affect different products at different abstraction levels. Moreover, some assets may move from an abstraction level to another, most-likely from common to variable assets. For instance, once a new product is added and not using a common asset in its implementation, this asset becomes a variable asset. Furthermore, during their evolution, SPLs can be merged if they become similar over time [START_REF] Schmid | A requirements-based taxonomy of software product line evolution[END_REF], or an SPL can be splitted when parts of the SPL can evolve in different directions [START_REF] Svahnberg | Evolution in software product lines[END_REF].

Botterweck and Pleuss [START_REF] Botterweck | Evolution of Software Product Lines[END_REF] summarized SPL and product evolution strategies and situations presented in [START_REF] Schmid | The economic impact of product line adoption and evolution[END_REF] and [START_REF] Deelstra | Product derivation in software product families: a case study[END_REF] as:

-Proactive evolution: the proactive adoption approach, as we presented earlier, consists on proactively planning and adding requirements to the SPL during domain engineering activity. Since this approach integrates the current and expected customer requirements that belong to the scope of the SPL, it is considered as an evolution approach that can deal with market changes.

-Reactive evolution: reactive evolution is achieved by directly integrating in the SPL the new requirements that arise during product derivation. This approach is mainly adopted by model-driven SPLs [CAK + 05], in order to avoid product-specific implementations. This allows a complete derivation of products from the SPL and an immediate reuse of the newly integrated requirements in future products derivation. However, this approach requires high efforts to ensure a co-evolution of existing products in parallel with the SPL evolution.

-Branch-and-unite: the branch-and-unite approach is related to the grow-and-prune concept [START_REF] Faust | Software product line migration and deployment[END_REF]. It consists on creating a new product branch to deal with product-specific requirements before reunifying the branch(es) with the SPL after releasing the product.

-Bulk: the bulk situation occurs when a company creates several branches to evolve a product. This makes the reintegration of those branches in the SPL expensive.

-Maintenance: over time maintenance activities are performed such as bug fixing and refactoring at both SPL and product levels.

In Objective 6, we highlighted on the need of an extractive SPL adoption approach when migrating existing product variants into an SPL. Furthermore, we are interested in a reactive SPL evolution, to offer an automated integration of the newly derived products in the SPL.

OBJECTIVE 15: REACTIVE SPL EVOLUTION

As per Mitschke et al. [START_REF] Mitschke | Supporting the evolution of software product lines[END_REF] traceability facilitates the maintenance and evolution of SPLs. They focused in their work on the traceability of the evolution of the relationships between artifacts, associated features and desired products, by assigning versions to each of them. New versions are created when changing in requirements occur: "changes of the feature model can directly influence the implementation of features as well as products". Each version of an artifact is associated with a specific version of a feature and management of features dependencies. Therefore, traceability is required, to ensure that the SPL remains consistent after changes.

We are interested in providing an incremental knowledge of the mappings between features and assets all along the evolution of the constructed SPL, in order to ensure on a one side that existing products are always available and derivable from the SPL and on the other side, keep mappings between the SPL artifacts up-to-date to support the derivation of new products with correct indicators.

OBJECTIVE 16: INCREMENTAL TRACEABILITY BETWEEN FEATURES AND ASSETS

We demonstrate the incremental evolution of the correlations in Chapter 7 and we evaluate it in Chapter 9.

According to Svahnberg and Bosch [START_REF] Svahnberg | Evolution in software product lines[END_REF], the arising new products to derive may introduce conflicts with the existing SPL products. Therefore, they suggested a set of guidance in order to perform a controlled evolution of an SPL. Gomaa and Hussein [START_REF] Gomaa | Software reconfiguration patterns for dynamic evolution of software architectures[END_REF] proposed software reconfiguration patterns to reconfigure the software architecture of an SPL to support a dynamic SPL evolution. Ajila and Kaba [START_REF] Samuel | Evolution support mechanisms for software product line process[END_REF] suggested some SPL evolution mechanisms that focus on identifying the change, analyzing its impact, specifying its propagation and validating its functionality. They examined their mechanisms on three different evolution levels: architecture level, product line level and product level. Moreover, Hotz et al. [START_REF] Hotz | Configuration in Industrial Product Families: The ConIPF Methodology[END_REF] proposed the conIPF methodology, which takes into consideration the occurring requirements during product configuration on application enginerring level, and allows their integration in the SPL and the domain engineering level. Similarily, Bayer et al. [BFK + 99] presented the PuLSE framework, that allows not only SPLE, but also customizability of its components and maturity scale for structured evoluation and maintenance.

We are interested in allowing a complete reuse of the SPL artifacts in a new product derivation, by allowing any possible configuration of features to be selected by the software engineer.

OBJECTIVE 17: ALLOW A COMPLETE REUSE

We define in Chapter 5 a constraint-free FM where all SPL features are optional except root feature. We call this FM a free FM, and its purpose is to enable complete reuse.

Feature models are considered as the key to manage SPL evolution due the abstraction that they provide [START_REF] Botterweck | Evolution of Software Product Lines[END_REF]. Difference models are required to identify the changes that arise on the SPL feature model over time. Operators such as add, modify, delete and operators with richer semantics such as split are required to specify the operation performed on the feature model during a change. In the context of difference models, Schaefer et al. introduced the Delta-Oriented Programming (DOP) where they define an SPL as (1) a core module that specifies a valid product and (2) delta modules that specify changes to be applied to the core module in order to derive other products [SBB + 10]. Moreover, Acher et al. proposed differencing techniques that exploit syntactic and semantic mechanisms in order to provide differences between feature models [AHC + 12]. On the operators side, Alves et al. introduced feature model refactoring operations such as replacing a mandatory feature type with an optional, or converting an or to an alternative [AGM + 06]. Such operations permit the evolution of an SPL, since it improves its configurability. As per Neves et al. SPL evolution might be risky, since it impacts existing products when introducing new features or improvements [NBA + 15]. Therefore, they introduced safe evolution templates after analyzing different evolution scenarios. These templates can guide developers during the SPL evolution process in order to preserve the behavior of existing products. EvoPL is an approach that combines both difference models and change operators by using the abstraction provided by feature models as the main artifact to manage SPL evolution [BPPK09, BPD + 10, PBD + 12]. A feature model version is decomposed into model fragments. A fragment is composed of feature model elements that are added or removed together during an evolution step. The fragments and operators between their elements are stored in a specific feature model called EvoFM. A configuration of the EvoFM represents an evolution step, while the evolution of a FM is a set of configurations of the EvoFM. The approach proposed by Martinez et al. in [MZB + 15b] does not provide an incremental evolution, since it does not offer an integration process of the newly derived products into the SPL.

In our approach, we are interested in updating the global feature model of the SPL whenever a new product is integrated in order to maintain systematic reuse.

OBJECTIVE 18: MANAGING FEATURE MODEL EVOLUTION

In Chapter 7 whenever a new product is derived, we employ the FAMILIAR merge operation [START_REF] Mathieu Acher | Familiar: A domain-specific language for large scale management of feature models[END_REF] to merge the SPL FM with the newly integrated product FM.

Summary and Contribution Choices

In this chapter, we presented the related works that propose approaches to migrate software product variants into an SPL, support the derivation of new products and evolve an SPL.

We have shown that an extractive SPL adoption must be performed in order to integrate PVs developed based on C&O into an SPL. In this context, in order to allow products derivation, it is important to identify the features implemented in the integrated PVs, map the features to their corresponding assets and construct the SPL FM. We presented several literature approaches to identify or locate features in PVs assets. In our dissertation, we consider that features must reflect the business functionalities of the SPL PVs. Moreover, we decided to focus on the integration of polyglot systems into an SPL. In this context, we aim to adopt a mechanism that takes into consideration the entire product line instead of treating products separately to identify the mappings between features and assets.

We presented several literature works that propose approaches to support the derivation of new products either in the SPL context or C&O context. Table 3.1 represents a comparison of the key characteristics offered by three of the main related works tools which are BUT4Reuse [MZB + 17], ECCO [START_REF] Fischer | Enhancing clone-and-own with systematic reuse for developing software variants[END_REF] and CACAO [START_REF] Lapeña | Towards clone-and-own support: locating relevant methods in legacy products[END_REF]. Some approaches limit the software engineers ownership of PVs, since they automate the derivation, while others lack some operational level support. In our approach, we give interest in guide software engineers during the derivation process without imposing on them specific solutions. Therefore, we aim to propose the possible scenarios that they can rely on to derive a product, and keep decision-making on their behalf. The number of possible solutions might be large. Hence, to tackle complexity and facilitate decisions, we aim to allow software engineers to select the derivation scenario to construct a new product, based on their own preferences, i.e. by selecting the source of clone that is composed of the products that they are most familiar with. Moreover, we aim to cost-estimate the different proposed operations, so they can rely on it as an additional argument in their choice of the relevant operations to perform to achieve the derivation.

Finally, we presented different works in literature about the evolution of an SPL. We highlighted on the importance of adopting a reactive SPL evolution, in order to integrate the newly derived products in the SPL and benefit from their systematic reuse. Integrating new products involves new features and assets, hence, mappings between features and assets must be updated to take into consideration the arising changes. In our approach, we aim to provide an incremental evolution of the traceability between features and assets. Further, the integration of new products involves an update of the SPL FM. Moreover, we are interested in enabling a complete reuse, hence, providing software engineers with the ability to derive a new product implementing any set of features provided by the SPL. Figure 3.5 illustrates to which challenges the objectives of our approach are going to respond in the contribution part, which comes next.

Preamble

In this part, we propose our approach to support Clone-and-Own in a Software Product Line context and we present its main contributions. Our approach consists first on migrating existing product variants into an SPL (see Chapter 4). Hence, an automated derivation of those products can be achieved, whenever a configuration requires a set of features realized by one of them. Further, new features can be added on top of the derived product. To provide an effective reuse, we support the derivation of new variants from the existing ones. Therefore, whenever the required features are subset of an existing one, or spread on several ones, comprising new features or not, we propose the possible scenarios to achieve the derivation. More precisely, we identify the products that can be the source for reuse, the required assets that have to be cloned from those products, and the operations to perform on the cloned assets to construct the new product (see Chapter 5). Such operations specify i.e. the features to be added on or removed from the cloned asset. To determine those operations, we rely on the automated mapping identification between the SPL features and assets, that we perform after the migration of the PVs (see Chapter 4). We estimate the cost of the possible scenarios and operations to facilitate the choice between them (see Chapter 6), and we provide a constraints system to simply allow end users to make their choices based on their own preferences (see Chapter 7). Hence, in our approach, we provide a complete guidance to end users to perform the derivation, that might involve different actors, such as product architects at configuration level and software developers at development level. Thus, product architects can select the appropriate derivation scenario and software developers can construct the product according to the proposed operations. Finally, our approach allows the integration of the newly derived products in the SPL to benefit from their reuse in future derivations, as well as preserving the derivation of existing products (see Chapter 7). Figure 3.6 shows our approach overview.

Introduction

In this chapter, we address Challenge 1.a that we presented in the introduction of this dissertation. This challenge indicates, when developing a family of software products, the necessity of mapping the features of PVs to the assets implementing them. We highlighted in Chapter 3 on the importance of managing variability by identifying and categorizing the features implemented by the PVs of the family of software products. This step is supposed to allow for example to determine what are the products that implement a set of required features, or if there exists a product that implements exactly all and no more than the required features. Thus, it is a step-forward to allow reuse of existing PVs. Another important issue consists in establishing mappings between features and assets. When the assets that are used to implement a certain feature are identified, it becomes possible to allow their reuse when constructing a new PV. We respond to Challenge 1.a by achieving the following objectives:

In this dissertation, we focus on feature-oriented software development where software reuse is practically performed using C&O or SPLE (Objective 1).

C&O is a practice adopted by many organizations to develop a family of software products since it offers rapidity, simplicity and independence [DRB + 13]. Despite that C&O is considered as an efficient reuse practice, it loses its efficiency when the number of managed PVs becomes enormous, because it lacks a systematic methodology for reuse [START_REF] Fischer | Enhancing clone-and-own with systematic reuse for developing software variants[END_REF].

A successful alternative to C&O is the adoption of an SPL development approach. When adopting an SPL approach, variability is managed efficiently, since features are categorized into common and variable features, and dependencies and constraints between them are identified [START_REF] Pohl | Software Product Line Engineering[END_REF]. Variability is often expressed using a feature model [START_REF] Lee | Concepts and guidelines of feature modeling for product line software engineering[END_REF]. A configuration of an FM allows to simply recognize which products implement a set of required features, and reuse existing products whenever the required features are entirely implemented by one of them. Moreover, the development architecture adopted in SPLE consists of creating reusable assets in domain engineering [START_REF] Clements | Software Product Lines : Practices and Patterns[END_REF], which enables reuse not only at product level but also at assets level.

Despite that SPLs allow to manage variability and enable reuse, they are considered as an expensive up-front investment [START_REF] Pohl | Software Product Line Engineering[END_REF]. In practice, artifacts have to be defined and developed in domain engineering before being explored in application engineering to derive products. Many are the organizations that cannot take such an expensive investment in terms of resources and time at the early beginning of the family of products development, therefore, they tend instead to adopt simple practices such as C&O.

In this dissertation, we propose a hybrid approach for developing and managing a family of software products, in which we aim to explore the benefits provided by both C&O and SPLs. We give our attention to organizations that adopt C&O as their initial development approach. Since such organizations are used to or convinced in adopting C&O, we give interest on retaining the fact that PVs are constructed by cloning (Objective 2). On the other hand, since in C&O variability is not managed and mappings are not established, we give interest in adopting SPL (Objective 3). Hence, as an initial step in our approach, we consider migrating PVs developed based on C&O into an SPL in order to manage their variability and facilitate their reuse (Objective 5). We perform this migration through an extractive approach (Objective 6).

We are interested in constructing an FM to allow the configuration of products by selecting the required features (Objective 4). Moreover, features must reflect the business-level functionalities implemented by the SPL products. Thus, in our approach we assume that a feature model representing the features implemented by each product variant is assigned to it, prior to its migration into the SPL (Objective 7).

We propose an automated mappings discovery between the features and the assets of the constructed SPL (Objective 8). Our approach takes into consideration the entire product line instead of treating products separately to identify the mappings. We call the mappings "correlations" since they define the correlation level between the artifacts of the SPL. Since we are interested in polyglot systems, the mappings discovery mechanism that we propose is languageindependent (Objective 9). We highlighted earlier on the fact that a feature might have different implementations due to features interactions. Moreover, a many-to-many relationship between features and assets is likely to occur. Hence, we take feature interactions into account when setting up the mappings discovery mechanism (Objective 10).

Finally, we assume that once the family of products starts to have its very few products, it becomes favorable to migrate them into the SPL (Objective 11). We do not impose this criteria, however, we consider it as a recommendation. Meanwhile, we guarantee in our approach a smooth and quick migration process that do not affect the development productivity. We define the migration process of our approach as an extractive process that is characterized by the following activities:

Product Line Definition

Migrating PVs into an SPL consists in providing the implementation files of the PVs and specifying the features that they implement. In our approach, we consider that features of a PV are known prior to migration process. We make this choice since we consider that a feature must represent a business-level functionality.

As a general definition, we define a Software Product Line SPL as a family of polyglot software products that share a set of identified features implemented through a set of assets. Our definition of an SPL fits into the classic SPL definition of Clements and Northrop [START_REF] Clements | Software Product Lines : Practices and Patterns[END_REF]. In our approach, we aim to manage the set of features shared between the software products, and identify the assets that implement them.

Feature Model Generation

In order to manage the features of the SPL, and since we aim to deal with business-level features, we consider that, for each software product, the features that it implements are given. In addition, prior to the migration of the software products, our approach imposes the representation of the features implemented by each of them in the form of a feature model. We impose this requirement, in order to respect the coherence of the overall structure of the features implemented by the SPL. In this context, an approach proposed by Ziadi et al. [ZFdSZ12, ZHP + 14, Mar16] can be used to automatically identify the migrated products features and generate the SPL FM, in situations where feature identification is required.

Definition 4.2.1 (Feature) :

We define a feature f , identified by its name, as an abstraction of a business functionality.

Definition 4.2.2 (Feature Model) :

We define a feature model f m as a triple id, {f 1 , ...f n }, struct , where id is the identifier of the feature model, {f 1 , ...f n } is the set of features that belong to it, and struct is the structure of the feature model, representing in a tree structural format the features and the constraints between them. We note the set of features F (f m) = {f 1 , ...f n }.

In our approach, the structure of a feature model respects the notations and semantics [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] of a classic feature model that was first introduced in the FODA method [KCH + 90].

Given a product p, its feature model has no variability, since it represents the configuration of the product which represents simply the features that it implements. A global FM represents the collection of features provided by the SPL and the constraints between them. Indeed, a configuration via this FM allows the derivation of the migrated PVs. In our approach, we employ the merge operation provided by FAMILIAR language [ACLF13] to construct the global FM of the SPL. We apply the merge operation on the FMs of the PVs to obtain the SPL FM.

Definition 4.2.3 (Restrictive FM) :

We call the generated feature model a restrictive FM, since it restricts but also guarantees a valid configuration and an automated derivation of the exact set of products provided by the SPL.

Products and Assets Extraction and Storage

We define the SPL products by means of the migrated PVs. For each PV an SPL product is defined. In order to identify the SPL assets, they must be extracted from the implementation artifacts of the PVs. Since PVs have features in common, they are supposed to have assets in common too. A feature might be implemented by several assets. In addition, an asset might share the implementation of several features. Consequently, the presence of a feature in a PV and its absence in another PV often produces two versions of a same asset in two different PVs. Thus, for some assets, several versions can be identified in the migrated PVs.

In our approach, we perform language independent feature location, in contrary to most approaches in literature [START_REF] Al-Msie'deen | Reverse Engineering Feature Models from Software Variants to Build Software Product Lines[END_REF][START_REF] Fischer | Enhancing clone-and-own with systematic reuse for developing software variants[END_REF][START_REF] Martinez | Mining software artefact variants for product line migration and analysis[END_REF], that perform a language-specific feature location, by employing artifact-type based algorithms to extract assets. In polyglot PVs, files of different formats exist. In addition, some files might be written using several languages. For instance, a Java Server Page (JSP) file, such as match.jsp form the running example (see Table 1.2), might contain HTML, Java, CSS blocks of code, and others. Thus, employing language-specific feature location techniques for polyglot PVs might be ineffective and errorprone.

Example 2: Applying the FAMILIAR merge operation to construct the SPL FM Below are the FMs of the running example PVs in FAMILIAR language. A FAMILIAR merge operation generates the SPL FM. Since we are interested in polyglot PVs, we set the granularity of the assets to be identified at file level. In other words, each extracted file from a PV corresponds to an asset. Since several versions of a file might be extracted, several versions of an asset might exist. Therefore, when extracting the assets, we distinguish different versions, and for each product we identify which version was used. Thus, we call assets the identified files and asset instances their corresponding versions. An asset represents an abstraction of one or more files having the same name in one or more PVs, noted as instance(s) of the asset.

Definition 4.2.4 (Asset Instance) :

We define an asset instance a i of an asset a as a pair instanceN o, implementation , where instanceN o is the instance number (version) of the asset instance, and implementation is its corresponding implementation file.

A new asset instance of an asset is identified, when a file existing in another product has the same name with a different content.

Definition 4.2.5 (Asset) :

We define an asset a as a pair name, {a 1 , ..., a n } , where name is the name of an implementation file and {a 1 , ..., a n } is the set of instances of the asset a, which are the different implementation versions of the file. We note AI(a) = {a 1 , ..., a n }.

Asset name and file name: We designate by asset name and file name, the relative path of the file in concern, including its exact name, within the project that it belongs to. However, for simplicity and to make the examples comprehensive, we represent files and assets throughout the dissertation by their exact name excluding the path. For example, in our approach match.jsp refers to W ebContent/match/match.jsp.

Definition 4.2.6 (Product) :

We define a product p as a triple name, f m, {a i j , ..., a n m } . A product p is identified by its name, a feature model f m referencing the features that it implements and a set of asset instances that it exploits to fulfill its implementation. We note f m(p) = f m to refer to the feature model of p, and AI(p) = {a i j , ..., a n m } to refer to the asset instances exploited by p.

The products of the SPL are defined by means of the migrated PVs. We consider products as the main elements of an SPL, since they embody the features and the assets of the SPL. Products are founded by their asset instances and their relationship with assets are identified via their asset instances. Definition 4.2.7 (Product implements features) : Given a product p, p implements a set of features noted as

F (p) = F (f m(p)).
We can now define formally an SPL as follows: Definition 4.2.8 (Software Product Line SPL) : We define a Software Product Line SPL as a set of products {p 1 , ..., p n }.

-We note the SPL products P (SPL) = {p 1 , ..., p n }.

-We note the SPL features F (SPL) = ∪ p j ∈P (SPL) (F (p j )) = {f 1 , ..., f x }.

-We note the SPL assets A(SPL) = {a | ∀a i ∈ ∪ p j ∈P (SPL) (AI(p j )), a i ∈ AI(a)} = {a 1 , ..., a z }.

As we work only with one SPL, we denote P (SPL) as P, F (SPL) as F and A(SPL) as A.

Definition 4.2.9 (Artifact) :

An artifact is used in the development of software systems. In our approach we limit its definition to the following: an artifact is a feature, an asset or an asset instance participating in the development of SPL.

Definition 4.2.10 (Product employs assets and exploits asset instances) : Given a product p, p employs a set of assets noted as A(p) and for each asset a j ∈ A(p), p exploits one of its instances a i j ∈ AI(a j ) to fulfill the implementation where

A(p) = {a j | a j ∈ A, ∃a i j ∈ AI(p), a i j ∈ AI(a)}.
Definition 4.2.11 (Feature implemented by products) : Given a feature f , the set of products that f is implemented in is noted as P (f ) = {p ∈ P, f ∈ F (p)}, where P (f ) ⊆ P.

Definition 4.2.12 (Asset employed by products) :

Given an asset a, the set of products that a is employed by is noted as P (a) = {p ∈ P, a ∈ A(p)}, where P (a) ⊆ P.

Definition 4.2.13 (Asset instance exploited by products) : Given an asset instance a i the set of products that a i is exploited by is noted as P (a i ) = {p ∈ P, a i ∈ AI(p)}, where P (a i ) ⊆ P.

Property 4.2.1 (SPL facts) : Given a product p, an asset a and a feature f , we can demonstrate that: Since an asset is identified based on a file path, given a product p ∈ P, for each asset a employed by p, only one of its instances is exploited by p. A product verifies uniqueness of asset instances if ∀a ∈ A(p), ∃!a i ∈ AI(p), a i ∈ AI(a).

-a ∈ A(p) ⇔ p ∈ P (a) -f ∈ F (p) ⇔ p ∈ P (f )

Example 3: Running example extracted assets and instances

In the running example PVs, the match.jsp asset represents a "Java Server Page" that displays a match information. The same implementation of the corresponding file is used in all PVs. Thus, only 1 instance was identified for it. On the other hand, the asset style.css represents a style sheet file that is employed by several web pages. Therefore, different implementations of this asset are available. Thus, 3 instances were identified for it. Table 4.2 shows the assets and corresponding instances, identified in the products of the SPL.

Correlations Identification

In order to identify the mappings among the SPL artifacts, we define "correlations". A correlation 1 indicates the coexistence between a feature and an asset, or between a feature and an asset instance. An asset is a global abstraction of a partial or a total implementation of one or more features, since a feature implementation can be spread into several assets, and similarly, an asset can include implementation fragments of different features. Therefore, we are interested in identifying the correlation between a feature and an asset, in order to determine the coexistence between them in the SPL products. On the other hand, an asset instance realizes one of the asset implementations in one or more SPL products. Therefore, we are interested in identifying the correlation between a feature and an asset instance.

In our approach, instead of mapping a feature or set of features (features interaction) to an implementation block, which can be composed of fragments of several assets, we map each feature to the set of assets that supposedly contribute in its implementation. We call those mappings correlations. Hence, a feature might be correlated to several assets, and an asset might be correlated to several features as well.

Definition 4.3.1 (Correlation) :

We designate the SPL correlations C(SPL) noted as C as the set of correlations that handles the coexistence between features and assets, and between features and asset instances in the SPL products. Therefore, we define two subsets of correlations:

1. Feature to Asset correlations, and 2. Feature to Asset Instance correlations.

A correlation between a feature f and an asset a holds if the following constraints are valid:

-For each product p j that implements f , p j employs a (exploits any of its instances) -There does not exist an asset instance a i exploited by p j and by another product p k that does not implement f In Figure 4.4, we demonstrate when a feature to asset correlation is identified. Given a feature f 3 and an asset a 3 , in the first situation (see Figure 4.4a), there exists an equivalence correlation f 3 ⇔ a 3 , since p 1 and p 2 are the only products that implement f 3 and employ a 3 . In the second situation (see Figure 4.4b), there is only an implication correlation f 3 ⇒ a 3 , since p 1 and p 2 implement f 3 and employ a 3 , while there exists a product p 3 that employs a 3 without implementing f 3 . In the third situation (see Figure 4.4c), no correlation holds between f 3 and a 3 , because p 3 does not implement f 3 and exploits the same instance a 1 3 of a 3 exploited by p 1 that implements f 3 . 4.3 shows the correlations between the features and the assets of the running example. If we refer to Table 1.1 and Table 1.2, we can see that the three products implement the feature M anageM atches and employ the asset match.jsp, therefore, M anageM atches ⇔ match.jsp. On the contrary, for each product implementing the feature M odif yM atches, which are p 1 and p 2 , the asset SaveM atch.java is employed, but p 3 employs SaveM atch.java and does not implement the feature M odif yM atches. Therefore, there does not exist an equivalence correlation between M odif yM atches and SaveM atch.java. However, M odif yM atches ⇒ SaveM atch.java because p 3 does not exploit the same instance of SaveM atch.java exploited by p 1 and p 2 . As a counter example, there is no implication between M odif yM atches and match.jsp, since p 3 that does not implement M odif yM atches exploits the same instance of match.jsp exploited by both p 1 and p 2 that implement M odif yM atches. Given an asset a, the set of features that a is in correlation with is noted as

F (a) = {f | f ∈ F, c(f, a)}. Definition 4.3.

(Asset instance correlated features) :

Given an instance a i of an asset a, the set of features that a i is in correlation with is noted as

F (a i ) = {f | f ∈ F, c(f, a i )}.
Definition 4.3.7 (Feature correlated assets) : Given a feature f , the set of assets that f is in correlation with is noted as

A(f ) = {a | a ∈ A, c(f, a)}.
Definition 4.3.8 (Feature correlated asset instances) : Given a feature f and an asset a j , the set of instances of a j that f is in correlation with is noted as AI(f /a j ) = {a i j | a i j ∈ AI(a j ), c(f, a i j )}. The set of instances of all assets that f is in correlation with is noted as AI(f ) = ∪ a j ∈A(f ) (AI(f /a j )).

Product Line Validation

In this section, we identify some structural requirements that must be satisfied during migration process in order to create the SPL.

As defined earlier, a product is identified by its name. However, when migrating PVs, a software engineer might attempt to provide two products having the same name. Thus, this attempt is considered as an anomaly that must be detected and rejected.

R1: each product in SPL must have a unique name, where ∀p j ∈ P,

p k ∈ P | name(p j ) = name(p k ).
When a PV is migrated into the SPL, an FM representing the features that it implements is assigned to it. In our approach, we employ the union merge operation provided by FAMILIAR, in order to generate the restrictive fm. FAMILIAR imposes that the root features of the input feature models match as a rule to accomplish the operation [START_REF] Acher | multiple feature models: foundations, languages and applications[END_REF]. Therefore, the provided PVs FMs must have a proper structure where all of them have the same root feature. R2: each product must have a feature model respecting the FODA notations and semantics and all products have to share at least one common feature which is the root feature of the SPL, where ∀(p j , p k ) ∈ P, ∃

f root | f root ∈ F ∧ f root ∈ F (p j ) ∧ f root ∈ F (p k ).
In our approach, we consider that products must be distinguished at business-level. Therefore, no two products are allowed to implement exactly the same features.

R3: we prohibit that two products in the SPL implement exactly the same set of features, regardless if their implementation is identical or not. Thus, ∀p j ∈ P, p k ∈ P | F (p j ) = F (p k ).

Since no two products are accepted if they implement the same features, respectively, no two products are supposed to have the same implementation. Furthermore, if two products implement different features, they are supposed to have different implementations (different asset instances). Therefore, in our approach, we enforce that no two products should have the same asset instances. R4: we prohibit that two products in the SPL have exactly the same implementation. In other words, no two products should have exactly the same asset instances. Thus, given two products (p j , p k ) ∈ P if they employ the same assets, they might exploit some, but definitely not all the same asset instances. Thus, if

A(p j ) = A(p k ) ⇒ AI(p j ) = AI(p k ).
Based on R3 and R4, a product is accepted for migration if there does not exist another product that implements the same features or exploits exactly the same set of assets.

If a product p j implements a set of features that is subset of the set of features implemented by another product p k , and the assets employed by p j are not part of the ones employed by p k , then each product is employing a different set of assets to implement the same features. Therefore, this is considered as an anomaly that produces uncorrelated artifacts.

R5: given two products (p j , p k ) ∈ P, if p k implements all the features implemented by p j and more, p k must employ all the assets employed by p j and -not necessarily but most likelymore. Thus, if

F (p j ) ⊂ F (p k ) ⇒ A(p j ) ⊆ A(p k ).
Property 4.4.1 (Complete SPL) : An SPL is complete, if all validation requirements are satisfied and each of its artifacts participates in at least one correlation.

In our approach, the migration process is accomplished if the SPL to be generated is a complete SPL.

Product Line Limitations

Architecture as a keystone of the SPL: Extraction of assets, and respectively asset instances is done based on their corresponding file name and the path under which they are located in the PV(s) from which they are extracted. Therefore, a change in folder structure, or in the name of a file in a certain PV implies the identification of a new asset for the file in concern, which causes an inconsistency in the SPL structure and an identification of spurious correlations. Thus, the extraction of the SPL assets is dependent on the architecture of the PVs. Similarly, the features of the SPL are extracted from the PVs FMs. Therefore, any change in FMs affects the identified features, and respectively the SPL correlations.

Asset instance uniqueness:

Since assets are identified by the path and the name of the file to which they refer, and an asset instance is a version of the file existing in one or more PVs, then, it is not possible to have two instances of the same asset in a product. A product can exploit only one asset instance of a certain asset.

Theoretically identified correlations:

The identified correlations are discovered based on the theory that we defined in this chapter, by analyzing the variability between the PVs artifacts. Despite that we aim to reach the highest precision in the identified correlations, our approach does not guarantee that all identified correlations are certain, because variability between PVs might be identified by means of a set of features and not a single feature. For instance, if a set of features CF = {f 1 , ..., f n } consists of the common features between all SPL products, and a set of assets CA = {a1, ..., a m } is the set of common assets between all SPL assets, our approach generates an equivalence correlation between each feature f j ∈ CF and each asset a j ∈ CA, however, nothing guarantees in practice that each f j ∈ CF is in correlation with each asset a j ∈ CA and vice versa. Similarly, if a set of features P F = {f 1 , ..., f n } is implemented by a product and not others, each asset a j of the set of asset P A = {a 1 , ..., a m } employed to implement the features will be in correlation with each feature f j ∈ P F , however, nothing guarantees this in practice. Despite that the correlations identified by our approach may not guarantee a high precision when few PVs are initially migrated, our approach ensures a continuous refinement of the correlations that gain precision over time with each integration of a new product in the SPL.

Example 6: Example of uncorrelated asset if R5 violated

In this example, we illustrate a situation in which an asset has no correlations due to the violation of the requirement R5.

In this situation, we have two PVs, as shown in Table 4.5, p x implements the features welcome and news, and p y implements the features welcome, news and contact. Table 4.6 shows the assets and their corresponding instances exploited by the products. 4.7 shows the correlations between the features and the assets, and as shown, the asset index.html has no correlations. This occurred because index.html was not employed by p y where we have home.html instead. Since the features implemented by p x are subset of the ones implemented by p y , all assets employed by p x were supposed to be employed by p y . Apparently, both index.html in p x and home.html in p y implement the welcome feature while they have different names. R5 was set to detect such situations and prevent the construction of an incomplete SPL.

Ad-hoc algorithm to identify correlations:

In our approach, we defined our own ad-hoc algorithm to identify mappings instead of relying on formal classification algorithms such as Formal Concept Analysis (FCA). However, we relied on our algorithm because we are interested in identifying feature correlations at both asset and asset instance level. Moreover, the constraints imposed by our algorithm allow to identify less correlations compared to FCA algorithm, which gives a higher level of correctness to the SPL correlations.

Summary

In this chapter, we responded to the first challenge addressed in the dissertation. By migrating PVs into the SPL, we enabled variability management and allowed the automated derivation of the products from the SPL. In addition, we identified the mappings between the SPL artifacts in terms of correlations.

To allow the derivation of the migrated PVs from the SPL, the restrictive FM is generated from the FMs of the migrated PVs. The restrictive FM permits the configuration of the SPL features in order to reuse the SPL products.

The identified correlations represent the mappings between the SPL features and assets and respectively between the features and the asset instances. These correlations are supposed to facilitate the reuse of SPL artifacts in order to create new products. We explain this process throughout the upcoming chapters.

The PVs to be migrated must respect some structural requirements, in order to make sure that their migration will result in a complete SPL. A complete SPL guarantees that the structure of the composed SPL is correct, and each artifact has at least one correlation.

Managing variability and allowing the automated derivation of the migrated PVs are important steps towards reuse. However, investing in the SPL products artifacts in order to derive new products that are not provided by the SPL is essential. Customers are about to request new requirements on a frequent basis, thus, new products are supposed to be derived on a continuous basis. In the next chapter, we address this need, and present our approach in supporting software engineers in deriving new software products.

CHAPTER 5

Introduction

The main goal when adopting SPLs is reuse [START_REF] Trigaux | Software Product Lines : State of the art[END_REF]. Reuse is an essential need when developing a family of software products. An organization that has developed a family of software products aims to target new customers that belong to the same market segment, in order to increase its profits. Thus, reusing the ready-made software products to respond to the needs of the new customers increases the orgranization profits. By enabling reuse, SPLs decrease development costs and time to market and increase software quality [START_REF] Pohl | Software Product Line Engineering[END_REF]. Moreover, an organization must deal with the continuous market demands and technology changes that involve the development of new software products [START_REF] Heider | A case study on the evolution of a component-based product line[END_REF]. Since the new products respond to the same market segment, they are supposed to implement some features that are already implemented by the existing products. Therefore, instead of redeveloping the assets corresponding to those features, software engineers seek to reuse the existing products artifacts and develop only the assets required to implement the new features. For this purpose, the products implementing the required features have to be determined and mappings between features and the assets contributing in their implementation have to be identified. In the previous chapter, we proposed in our approach a mechanism to identify those mappings, and we called them correlations.

Prior to the derivation of a product variant, the SPL feature model has to be configured, in order to select the features required for the derivation. Further, some new features that are not offered by the existing PVs might be required. Hence, in this chapter, we address Challenge 1.b of this dissertation, by presenting how we support the configuration process, that is a preliminary step before deriving a product variant. As well, we address Challenge 2.a in terms of allowing the addition of new features during the configuration. Our approach supports the derivation of new products and allows the derivation of existing ones as well. We identify four possible situations that can arise. A software engineer might proceed with a valid configuration, by selecting a set of features that are implemented exactly by an existing product. Hence, an automated derivation of the corresponding product has to be done. Figure 5.1a illustrates this situation. A second situation occurs when the configuration is valid, but still new features have to be added. Hence, in our approach, we enable the addition of new features directly during the configuration. Similarly to the previous situation, the corresponding product is provided, however, a manual completion is required to add the new features and thus, create a new product. Figure 5.1b illustrates this situation. Another situation might occur, in which the software engineer selects a set of features that are part of the implementation of an existing product or spread on several products. Hence, the configuration is invalid, since no existing product implements all and only the required features. Therefore, a new product has to be constructed. In this situation, we aim to support the derivation of the possible scenarios and operations to perform in order to derive the new product. We call the product to derive the "desired product". Figure 5.1c illustrates the third situation. Finally, a software engineer might select features corresponding to an invalid configuration, but also adds new features. Same as previous situation, we aim to support the derivation with the possible scenarios and operations and let software engineer add the new features. Figure 5.1d illustrates the fourth situation. To enable invalid configurations, we generate a free FM that corresponds to a constraint-free version of the restrictive FM. Therefore, the selection of any possible combination of features during a configuration is now possible (Objective 17). Further, we suggest the possible scenarios by means of operations to perform at asset level, that software engineers can rely on to derive the desired product (Objective 12). Several scenarios might be possible to derive a certain product, and several operations might be possible at each asset level. Therefore, instead of proposing a single solution, we propose to software engineers the possible scenarios and operations. Hence, we guide the derivation without automating it or imposing a specific solution (Objective 14). Thus, we keep decision-making for software engineers that construct the products on their own.

Configuration

When a software engineer decides to derive a product, she has to identify the required features, in order to figure out if there exists a product that implements entirely those features. This process is done systematically when configuring the FM of an SPL, that we call in our approach restrictive FM. However, the restrictive FM limits the configuration to the exact set of products offered by the SPL. We highlighted earlier on the importance of developing new software products, in order to satisfy the arising market demands. A new product might require the implementation of new features that were not offered by the SPL products. Thus, in our approach, we are interested in supporting organizations in growing their product line by developing new products. Therefore, we enable the integration of new features in the SPL, by defining them through the configuration of a new product.

Definition 5.2.1 (Configuration) :

We define a configuration cf as a triple id, {f j , ..., f n }, {f x , ..., f z } where id is the identifier of the configuration. The set of features {f j , ..., f n } are the features required to build the desired product and offered by the SPL, while {f x , ..., f z } are the new features required to build the desired product and not offered by the SPL. We note {f j , ..., f n } as EF (cf ), where EF (cf ) ⊆ F stands for existing features and {f x , ..., f z } noted as N F (cf ) ⊂ F stands for new features.

During the configuration of an FM, we identify three categories of features:

-Required existing feature: a selected feature implemented by one or more products of the SPL and required for the derivation of the desired product.

-Unrequired existing feature: an unselected feature implemented by one or more products of the SPL and not required for the derivation of the desired product.

-Required new feature: a selected feature that is not implemented by any of the SPL products, but required for the derivation of the desired product.

Inspired from [KNGDNK + 16], we determine the following properties, that specify the relationship between a configuration and a SPL product: Property 5.2.1 (Product contributes in configuration) : An SPL product p ∈ P contributes in a configuration cf if p implements at least one feature required by cf , thus EF (cf ) ∩ F (p) = {φ}. In other words, ∃f j ∈ F (p), f j ∈ EF (cf ).

Property 5.2.2 (Product realizes a configuration) :

An SPL product p ∈ P realizes a configuration cf if all and only the features required by cf are implemented by p, thus if EF (cf ) = F (p). In other words, ∀f j ∈ EF (cf ),

f j ∈ F (p) ∧ f k ∈ F (p), f k / ∈ EF (cf ).

(Product covers a configuration) :

An SPL product p ∈ P covers a configuration cf if all features required by cf are implemented by p, but p implements in addition some features that are not required by cf , thus if EF (cf ) ⊂ F (p). In other words, ∀f j ∈ EF (cf ),

f j ∈ F (p) ∧ ∃f k ∈ F (p), f k ∈ EF (cf ).
Figure 5.2 shows an SPL example that consists of four products and illustrates the features implemented by each product. Given a configuration cf k where EF (cf k ) = {f 4 , f 7 }, we can say that: 1. Is there a product in SPL that realizes the configuration, or do we have to break the constraints imposed by the restrictive FM in order to achieve the configuration?

-p 1 contributes in cf k , since EF (cf k ) ∩ F (p 1 ) = {f 4 }. -p 2 covers cf k , since EF (cf k ) ⊂ F (p 2 ), where {f 4 , f 7 } ⊂ {f 1 , f 2 , f 3 , f 4 , f 5 , f 6 , f 7 }. -p 3 covers cf k , since EF (cf k ) ⊂ F (p 3 ), where {f 4 , f 7 } ⊂ {f 4 , f 6 , f 7 }. -p 4 realizes cf k , since EF (cf k ) = F (p 4 ) = {f 4 , f 7 }.
2. Does the SPL offers all the features required by the desired product? Or there exists some new required features that are not offered by the SPL products?

3. If new features are required, how can a software engineer express the need of new features during the configuration and how those features can be added to the SPL FM?

Selecting a set of features that do not correspond to a valid configuration is not possible via the restrictive FM. A configuration via the restrictive FM is restricted by the constraints that define the variability between its features. Therefore, the only possible configurations that can be made through restrictive FM are the ones for which there exists a product that realizes the configuration. On the other side, in order to introduce new features required by the desired product, we enable the addition of new features through a configuration made on a restrictive FM. Thus, despite that the restrictive FM allows an automated derivation of the SPL products, it does not permit the configuration of new ones, except the ones that involve the addition of new features on top of a product that realizes the configuration.

Free Feature Model Generation

Since a restrictive FM does not allow to break the constraints imposed by the SPL variability, we define a free FM in which a software engineer can select a set of features that does not correspond to a valid configuration.

Definition 5.2.2 (Free FM) :

A free FM is a constraint-free feature model that includes all the features of a restrictive FM where all features are optional except the root feature, without defining any constraint.

Example 7: Running example Restrictive and Free FMs

As shown below, the free FM of the running example has all its features optional and no constraints between them, although it respects the structure of the restrictive FM. In other words, a software engineer can select any combination of features from the free FM to configure a new product, with a one condition that, if a feature is selected its parent feature is automatically selected.

Configuration Modes

We defined for an SPL two FMs: restrictive FM and free FM. In derivation process, we define respectively two configuration modes -restrictive and free -where each employs its corresponding FM, to allow a software engineer to perform a configuration, in order to derive a product. Regardless the FM in use to configure a product, we enable the definition of new features at the configuration level, so that, software engineers can add new features to create new products, whenever those features are not provided by the SPL.

Restrictive Mode

A restrictive mode employs the restrictive FM, which restricts a configuration to a set of features that correspond to an existing product. Therefore, it allows the automated derivation of existing products. Moreover, since we enabled the definition of new features at the configuration level, software engineers are able to define features in restrictive mode, and therefore, derive new products that their required existing features are realized by a product in the SPL.

Free Mode

A free mode employs the free FM which is a constraint-free FM, that allows the selection of any set of features, since all features are optional. Therefore, free mode allows the derivation of a new product by collecting features from one or several existing products, in addition to the possibility of adding new features that are not provided by the SPL.

Configuration Scenarios

When a software engineer selects a set of features in restrictive mode, either the configuration is valid, and thus, the set of required existing features is realized by one and only one product, or the configuration is invalid, and thus, the configuration is to be performed in free mode. If the set of required existing features is not realized by a single product, then, there might exist a product that covers this configuration, or there might exist a combination of products, where each product contributes in the configuration and the combination by itself realizes or covers the configuration. Therefore, we call a configuration scenario, a possible scenario to achieve a configuration. Indeed, a configuration can be achieved by several configuration scenarios.

Definition 5.4.1 (Configuration scenario) :

We define for each configuration cf j a set of configuration scenarios {cs 1 (cf j ), ..., cs n (cf j )} noted as CS(cf j ), where a configuration scenario cs i (cf j ) is defined as a pair { p k , {f q , ..., f s } }, {f x , ..., f z } , where { p k , {f q , ..., f s } } is a combination of products that can be reused to achieve the configuration and {f x , ..., f z } is N F (cf ) if any. A product is candidate for a configuration scenario if it implements at least one of the features of EF (cf ). Further, for each combination, the unrequired features {f q , ..., f s } implemented by a candidate product p k are identified.

Property 5.4.1 (Products of a configuration scenario) : Given a configuration scenario cs i (cf j ) of a configuration cf j , the combination of products participating in cs i (cf j ) are noted as P (cs i (cf j )).

Possible Configuration Scenarios

Since several scenarios might be determined for a certain configuration, we identify the possible configuration scenarios to achieve a configuration as follows:

Integrality: A configuration cf j can be achieved by integrality (S1 in Figure 5.4) if there exists a configuration scenario cs i (cf j ) that consists of a product in the SPL that realizes the Restriction: A configuration cf j can be achieved by restriction (S2 in Figure 5.4) if there exists a configuration scenario cs i (cf j ) that consists of a product in the SPL that covers the set of required existing features selected in the configuration. Restriction can arise in free mode.

Integral composition: A configuration cf j can be achieved by integral composition (S3 in Figure 5.4) if there exists a configuration scenario cs i (cf j ) that consists of a combination of products in the SPL where each product contributes in the configuration, and the combination realizes the set of required existing features selected in the configuration. Integral composition can arise in free mode.

Restrictive composition: A configuration cf j can be achieved by restrictive composition (S4 in Figure 5.4) if there exists a configuration scenario cs i (cf j ) that consists of a combination of products in the SPL where each product contributes in or covers the configuration, and the combination covers the set of required existing features selected in the configuration. Restrictive composition can arise in free mode.

Extension: A configuration cf j can be achieved by extension (S5 in Figure 5.4) if there exists a configuration scenario cs i (cf j ) that consists of a product in the SPL that realizes the set of required existing features selected in the configuration, and the configuration has in addition some selected required new features. Extension can arise in restrictive mode. An extension is an integrality with required new features.

Restrictive extension: A configuration cf j can be achieved by restrictive extension (S6 in Figure 5.4) if there exists a configuration scenario cs i (cf j ) that consists of a product in the SPL that covers the set of required existing features selected in the configuration, and the configuration has in addition some selected required new features. Restrictive extension can arise in restrictive mode. A restrictive extension is a restriction with required new features.

Extensive composition: A configuration cf j can be achieved by extensive composition (S7 in Figure 5.4) if there exists a configuration scenario cs i (cf j ) that consists of a combination of products in the SPL where each product contributes in the configuration, and the combination realizes the set of required existing features selected in the configuration, and the configuration has in addition some selected required new features. Extensive composition can arise in free mode. An extensive composition is an integral composition with required new features.

Restrictive extensive composition: A configuration cf j can be achieved by restrictive extensive composition (S8 in Figure 5.4) if there exists a configuration scenario cs i (cf j ) that consists of a combination of products in the SPL where each product contributes in or covers the configuration, and the combination covers the set of required existing features selected in the configuration, and the configuration has in addition some selected required new features. Restrictive extensive composition can arise in free mode. A restrictive extensive composition is a restrictive composition with required new features.

Given the SPL shown in Figure 5.2 that consists of four products, we demonstrate on some configurations made in both restrictive and free mode, the possible configuration scenarios that we presented above.

Restrictive mode configuration scenarios:

Let cf 5 a new configuration, where EF (cf 5 ) = {f 1 , f 2 , f 3 , f 4 } and N F (cf 5 ) = {φ}. The product p 1 realizes cf 5 since F (p 1 ) = EF (cf 5 ). Thus, cs 1 (cf 5 ) = { p 1 , {φ} }, {φ} (integral- ity).
Let cf 6 a new configuration, where EF (cf 6 ) = {f 4 , f 7 } and N F (cf 6 ) = {f 8 }. The product p 4 realizes cf 6 since F (p 4 ) = EF (cf 6 ). Thus, cs 1 (cf 6 ) = { p 4 , {φ} }, {f 8 } (extension).

Whenever exists a product p j that realizes a configuration cf k where F (p j ) = EF (cf k ), the only configuration scenario to be considered for this configuration is the integrality that is achieved by

p j if N F (cf k ) = {φ} or the extension if N F (cf k ) = {φ}.

Free mode configuration scenarios

Let cf 7 a new configuration, where EF (cf 7 ) = {f 1 , f 2 , f 3 , f 4 , f 7 } and N F (cf 7 ) = {φ}.
No product in SPL realizes cf 7 . However, several configuration scenarios are possible for cf 7 :

cs 1 (cf 7 ) = { p 2 , {f 5 , f 6 } }, {φ} (restriction).

cs 2 (cf 7 ) = { p 1 , {φ} , p 2 , {f 5 , f 6 } }, {φ} (restrictive composition).

cs 3 (cf 7 ) = { p 1 , {φ} , p 3 , {f 6 } }, {φ} (restrictive composition).

cs 4 (cf 7 ) = { p 1 , {φ} , p 4 , {φ} }, {φ} (integral composition).

cs 5 (cf 7 ) = { p 2 , {f 5 , f 6 } , p 3 , {f 6 } }, {φ} (restrictive composition).

cs 6 (cf 7 ) = { p 2 , {f 5 , f 6 } , p 4 , {φ} }, {φ} (restrictive composition).

cs 7 (cf 7 ) = { p 1 , {φ} , p 2 , {f 5 , f 6 } , p 3 , {f 6 } }, {φ} (restrictive composition).

cs 8 (cf 7 ) = { p 1 , {φ} , p 2 , {f 5 , f 6 } , p 4 , {φ} }, {φ} (restrictive composition).

cs 9 (cf 7 ) = { p 2 , {f 5 , f 6 } , p 3 , {f 6 } , p 4 , {φ} }, {φ} (restrictive composition).

cs 10 (cf 7 ) = { p 1 , {φ} , p 2 , {f 5 , f 6 } , p 3 , {f 6 } , p 4 , {φ} }, {φ} (restrictive composition).

Let cf 8 a new configuration, where EF (cf 8 ) = {f 1 , f 2 , f 3 } and N F (cf 8 ) = {f 9 , f 10 }. No product in SPL realizes cf 8 . However, several configuration scenarios are possible for cf 8 :

- When a configuration is achieved in free mode, where no product realizes it, the products or combinations of products that realize or cover the required existing features are identified via configuration scenarios. Most likely, several configuration scenarios are found for a certain configuration. Thus, a software engineer has to chose the "appropriate" configuration scenario to derive the desired product. However, the question is: "how to determine the appropriate configuration scenario?".

cs 1 (cf 8 ) = { p 1 , {f 4 } }, {f 9 , f 10 } (restrictive extension). -cs 2 (cf 8 ) = { p 2 , {f 5 , f 6 , f 7 } }, {f 9 , f 10 } (restrictive extension). -cs 3 (cf 8 ) = { p 1 , {f 4 } , p 2 , {f 5 , f 6 , f 7 } }, {f 9 , f 10 } (restrictive extensive composition).
One might consider a restrictive composition more expensive in terms of time and development efforts compared to restriction, since restrictive composition involves more products. Also, logically someone might consider a restrictive composition involving n products more expensive than a restrictive composition involving n -1 products. Moreover, one might consider a restriction more expensive than an integral composition, since restriction requires the removal of some features. On the contrary, someone else might consider integral composition more expensive than restriction, by considering that removal of some features is less expensive than integrating assets from several products to derive a new product. As demonstrated, it is ambiguous for us to determine what is the "appropriate" configuration scenario to derive a desired product, if the choice has to be taken according to the products and features involved in the configuration scenario. However, the software developer who developed the product variants is the one responsible to determine the "appropriate" solution, since she knows better the code and how the software variants are composed. Therefore, we aim to suggest to end users the possible solutions and let them be the decision makers.

Derivation Operations

The implementation of the SPL products is achieved via their asset instances. Thus, to help software engineers to determine the "appropriate" configuration scenario, we must take into consideration the operations required to derive a desired product according to the asset instances exploited by the products involved in each configuration scenario. This process has to be realized through the following steps:

1. Identify the assets required to implement the desired product.

2. Determine the possible operations to perform on each asset, in order to obtain an asset instance that fulfills the implementation of the desired product features.

3. Map each configuration scenario to its corresponding operations.

These steps involve the examination of the correlations identified between the features and the assets as well as their instances. Definition 5.5.1 (Required assets for derivation) : An asset a is required for deriving a desired product, if there exists at least a feature f such as, f is in correlation with a and f is one of the required existing features of the configuration cf built to achieve the derivation of the desired product. Hence, we note the required assets of cf as A(cf ), where A(cf

) = {a | ∃f ∈ EF (cf ), c(f, a)} .
For each identified required asset, several operations might be possible to produce an asset instance that serves for the implementation of the required features of the configuration.

1. An asset instance has to be cloned, 2. then modified if necessary to remove implementation fragments corresponding to some features that it implements and unrequired by the configuration, 3. and if there still exists some required features that are not implemented by the cloned instance, their implementation fragments must be extracted from the other instances of the asset and integrated in the clone.

The resulting asset instance of each required asset has to implement the set of features F (a) EF (cf ). Thus, we identify three types of actions that might be taken over the instances of a required asset in order to produce the desired instance:

1. Clone and Retain (CRT ): clone an asset instance and retain it as it is, without modifying its implementation.

2. Clone and Remove (CRM ): clone an asset instance, and remove from it the implementation fragments corresponding to the features that it is in correlation with but are not required by the configuration.

3. Extract and Add (ET A): extract from an asset instance the implementation fragments of some features required by the configuration, and add them to a cloned instance under construction. An ET A action is used only as a subsequent to a CRT or CRM action in order to complete the construction of a cloned instance with extracted implementation fragments.

Definition 5.5.2 (Action) :

An action ac is defined as a triple type, a i , {f j , ..., f n } , where type corresponds to one of the types defined above: {CRT, CRM, ET A}. For CRT and CRM actions, a i corresponds to the asset instance to clone. For an ET A action, a i corresponds to an asset instance to extract from. Whereas, {f j , ..., f n } corresponds to the set of features to remove from a i if the action is CRM , or to extract from a i if the action is ET A, while it is an empty set for a CRT action.

Hence, the resulting asset instance for a required asset is produced by cloning an asset instance exploited by a product of the configuration scenario using a CRT or CRM action, removing the implementation fragments corresponding to the unrequired features in case of a CRM action, and extracting the remaining required features from other instances using an ET A action, if any.

Example 9: Some actions on a configuration from running example

Based on Example 8, EF (cf 4 ) = {M anageM atches, AddM atches, DeleteM atches} and according to Table 4.3, the asset SaveM atch.java is in correlation with the features M anageM atches, AddM atches and M odif yM atches. Thus, the asset SaveM atch.java is required and the resulting instance has to integrate implementation fragments corresponding EF (cf 4 ) F (SaveM atch.java) = {M anageM atches, AddM atches}. The resulting instance might be a possible result of a CRT action, which consists of cloning the instance SaveM atch.java 2 that is in correlation with {M anageM atches, AddM atches} and retaining it as it is. Another possible result can be obtained using a CRM action applied on instance SaveM atch.java 1 by cloning it and removing the implementation fragments corresponding to the unrequired feature M odif yM atches.

It is required sometimes to make several actions in order to obtain the needed asset instance. This occurs when a CRT or CRM action is accompanied with one or more ET A actions on several instances of the asset, in order to create a new instance. We call this set of actions as "operations".

Definition 5.5.3 (Operation) :

We define an operation as the set of actions needed to produce the desired asset instance. Thus, an operation op is a triple a, {ac 1 , ..., ac n }, a i , where a ∈ A(cf ) is the required asset, and {ac 1 , ..., ac n } noted as AC(op) is the set of actions to be made to obtain the desired asset instance a i .

We categorize the possible operations to perform into three groups:

-Concludable operations: an operation is considered concludable if it is composed of one and only one CRT action. Hence, it is not supposed to require efforts except a clone of its corresponding asset instance.

-Substitutional operations: an operation is considered substitutional if there exists an asset instance in SPL that is in correlation with all and only the features required for the asset instance that it is supposed to produce. Therefore, a substitutional operation is a kind of alert that warns a software developer that there already exists an asset instance exploited by a product that is not part of the configuration scenario, and that asset instance implements the exact set of required features. This situation occurs on the first operation corresponding to the asset SaveM atch.java presented in Table 5.1.

-Constructive operations: an operation is considered constructive if it aims to deliver a new asset instance that is not provided by the SPL. Hence, it requires some efforts from a software developer to produce the asset instance.

Example 10: Some operations on a configuration from running example

Given the asset style.css of the running example, and based on configuration cf 4 introduced in Example 8, we identify the possible operations to perform at the level of the asset style.css, in order to obtain the desired instance:

op 1 = style.css, { CRM, style.css 1 , {M odif yM atches} , ET A, style.css 2 , {DeleteM atches} }, style.css 4 consists of cloning the asset instance style.css 1 and removing from it the implementation fragments corresponding to the feature M odif yM atches, then extracting the implementation fragments corresponding to the feature DeleteM atches from style.css 2 and adding them to the clone, in order to obtain the desired instance style.css 4 .

op 2 = style.css, { CRM, style.css 2 , {M odif yM atches} }, style.css 4 consists of cloning the asset instance style.css 2 and removing from it the implementation fragments corresponding to the feature M odif yM atches in order to obtain the desired instance style.css 4 .

op 3 = style.css, { CRT, style.css 3 , {φ} , ET A, style.css 2 , {DeleteM atches} }, style.css 4 consists of cloning the asset instance style.css 3 , then extracting the implementation fragments corresponding to the feature DeleteM atches from style.css 2 and adding them to the clone, in order to obtain the desired instance style.css 4 .

Table 5.1 shows the possible configuration scenarios corresponding to the configuration cf 4 and their possible operations to perform.

Once operations are identified, they are mapped to the configuration scenarios. For each configuration scenario, several operations are assigned. Precisely, at the level of each required asset, one or several operations might be possible to construct the desired instance of the asset. Therefore, to achieve the derivation of a new product variant, a software developer is provided with all possible configuration scenarios, and all possible operations that can be performed at asset level. For each required asset, only one operation has to be selected.

Summary

In this chapter, we presented how we support the configuration of a product variant prior to its derivation in two configuration modes. A configuration made in restrictive mode allows an automated derivation of an existing product or the derivation of a new product based on the integration of new features into an existing one. A configuration made in free mode allows the derivation of a new product. We guide this derivation by providing the possible configuration scenarios and the operations to perform at each required asset level in order to construct the asset instances of the desired product.

Since several configuration scenarios are possible and several operations might be identified at an asset level, we keep the choice of the appropriate configuration scenario and operations to the software developer who is supposed to be familiar with product variants and their source code. In this upcoming chapter, we introduce an additional parameter to support the product derivation by estimating the cost of the operations to perform and globally the cost of each configuration scenario. In chapter 7, we explain how we suggest to end users the possible configuration scenarios and operations, in a way that facilitates on them the selection of the appropriate ones according to their own preferences.

Introduction

In the previous chapter, we proposed two configuration modes to support the configuration prior to the derivation of a product variant. We presented how we provide the possible configuration scenarios and operations to perform to fulfill the derivation. We highlighted earlier on the importance of assigning the decision to make to the software engineers who are supposed to be familiar with the SPL product and their source code, so they can choose the appropriate configuration scenario and operations for derivation. Despite that, a configuration might have a large number of possible configuration scenarios on the one side and each required asset might have a large number of possible operations on the other side. As presented in Challenge 1.c, this multiplicity of choices can turn the software engineers decisions difficult. For this purpose, we supply our approach with an estimation of the cost of the operations to perform and the cost of each configuration scenario, that we introduce in this chapter (Objective 13). This cost estimation is supposed to be an additional argument that supports software engineers in selecting a configuration scenario and the operations to perform at asset level to achieve the derivation of the desired product.

In this chapter, we demonstrate the cost estimation only on the excerpt of assets of the running example to keep the explanation simple. We note that the product variants of the running example employ more assets than the ones presented in Table 1.2, and applying the cost estimation functions on the excerpt of assets produces different cost values, however, it gives analogical results to the whole running example.

Cost-Estimation

Action Type Weight

The cost of an operation is estimated based on the actions that it is composed of. In case of a CRT action, an asset instance has to be cloned without being modified, therefore, no cost has to be allocated. In case of a CRM action, an asset instance has to be cloned and implementation fragments corresponding to one or more features must be removed from the cloned instance. Similarly, for an ET A action, implementation fragments corresponding to one or more features must be extracted from an instance and integrated in the cloned instance. Therefore, for both CRM and ET A a cost has to be allocated. We assume that an ET A action costs 50% additional efforts compared to a CRM action, since it consists in adding the extracted fragments to the clone after their extraction.

Definition 6.2.1 (Action type weight) :

We define an action type weight denoted aw, where aw = 0 for CRT , aw = 1 for CRM and aw = 1.5 for ET A.

Correlation Degree

We estimate the cost of removing or extracting a feature based on the following global assumption:

"as much as the correlation degree between a feature and an asset instance is high, the removal or extraction of the feature from the asset instance becomes hard".

We define correlation degree based on the following assumptions:

-As much as the number of features that an asset instance is in correlation with (F (a i ))

increases, the correlation degree between the asset instance and any of those features decreases. Hence, the impact of the feature

f ∈ F (a i ) is proportional to 1 ÷ |F (a i )|.
-As much as the number of assets that a feature is in correlation with (A(f )) increases, the correlation degree between the feature and any of those assets decreases. Hence, the impact of an asset a ∈ A(f

) is proportional to 1 ÷ |A(f )|.
-As much as the number of instances of an asset that a feature is in correlation with increases, in relation to the overall number of instances of the asset (AI(f /a)), the correlation degree between the feature and the asset increases. Hence, the number of instances of a that f is in correlation with, in relation to the overall number of instances of a corresponds to |AI(f /a)| ÷ |AI(a)|.

Definition 6.2.2 (Correlation degree) :

We define a correlation degree between a feature f and an asset instance a i as:

cd(f, a i ) = 1 |F (a i )| × 1 |A(f )| × |AI(f /a)| |AI(a)|
Example 11: Asset instance correlated features from running example

Referring to Table 4.4, we compute the number of features that each asset instance is in correlation with: |F (a i )|. The cost of an action is defined as the sum of the correlation degrees of the features that have to be removed or extracted from the asset instance of this action, multiplied by the action type weight aw.

Let ac = type, a i , {f j , ..., f n } , cost(ac)

= fn f j (cd(f j , a i ) × aw)
Example 12: Feature correlated assets from running example

Referring to Table 4.3, we compute the number of assets that each feature is in correlation with: |A(f )|. The cost of an operation is defined as the sum of the cost of all its actions.

Let op = a, {ac 1 , ..., ac n }, a i , cost(op) = n j=1 cost(ac j )
Example 17: Operations cost from running example

Referring to the operations of the configuration cf 4 of the running example listed in Table 5.1 and the examples listed above, we compute the estimated cost of the the running example operations of the configuration cf 4 .

Configuration Scenario Cost

To determine the cost of a configuration scenario, we have to take into consideration the operations available at each required asset level. Since several operations are possibly identified at each required asset level, we consider only the operation having the lowest cost for each asset when computing the cost of a configuration scenario. Definition 6.2.5 (Configuration Scenario cost) :

The cost of a configuration scenario is defined as the sum of the estimated cost of the operations having the lowest cost at each asset level.

Let cs = {op 1 , ..., op n }, cost(cs) = n j=1 cost(op j )
Example 18: Configuration scenario cost from running example Referring to Table 6.7, we compute the estimated cost of the the running example configuration scenarios of the configuration cf 4 . Table 6.8: Configuration cf 4 configuration scenarios estimated cost Configuration scenario cost(cs i (cf 4 )) cs 1 (cf 4 ) 0.1666 cs 2 (cf 4 ) 0.1666 cs 3 (cf 4 ) 0.0625 cs 4 (cf 4 ) 0.0625

It is possible to have several configuration scenarios with the same estimated cost. A situation that most likely occurs is when the products involved in a configuration scenario are subset of the ones involved in the other configuration scenario. Therefore, the operations having the lowest cost at each asset level are similar for those configuration scenarios and their overall cost is equal. Further, another situation that occasionally occurs is when two configuration scenarios have the same cost without having their involved set of products subset of each other. To facilitate the selection of a configuration scenario in such situations, we prioritize the configuration scenarios having the same cost as follows:

Given two configuration scenarios cs 1 and cs 2 , where cost(cs 1 ) = cost(cs 2 ). The configuration scenario cs 1 is given a selection priority over cs 2 if one the following conditions is true:

1. P (cs 1 ) ⊂ P (cs 2 ) 2. |AM (cs 1 )| < |AM (cs 2 )|
where P (cs i ) is the set of products involved in a configuration scenario and AM (cs i ) is the number of required assets in cs i that require a modification. Thus, software engineers can rely on this proposed prioritization, to select a configuration scenario when several ones have the same estimated cost.

Example 19: Configuration scenarios having same cost

Referring to Table 6.8 of the running example, cs 1 (cf 4 ) and cs 2 (cf 4 ) have the same cost, however, cs 1 (cf 4 ) is composed of one product (p 2 ) which is a subset of the products from which cs 2 (cf 4 ) is composed (p 1 and p 2 ). Similarly, cs 3 (cf 4 ) and cs 4 (cf 4 ) have the same cost, however, cs 3 (cf 4 ) is composed of two product (p 2 and p 3 ) which are subset of the products from which cs 4 (cf 4 ) is composed (p 1 , p 2 and p 3 ).

Summary

In this chapter, we presented an additional argument to support software engineers when deriving a new product variant. This arguments consists of a cost estimation of the proposed configuration scenarios and their corresponding operations. Providing the estimated cost of the operations facilitates the selection of an operation when several operations are possible to construct an asset instance. Similarly, it facilitates the selection of a configuration scenario when several ones are proposed. Therefore, a software developer can rely on the estimated cost of the configuration scenarios as an additional parameter to make her decisions during product derivation.

Introduction

We focused throughout our approach on keeping decision making during product derivation on behalf of software engineers. We are interested in guiding software engineers without imposing a solution on them to accomplish the derivation (Objective 14). In Chapter 5 of this dissertation, we explained how we identify the possible configuration scenarios and operations to perform to derive a desired product. Hence, software engineers must have the complete freedom to select the solution that they consider suitable for derivation, based on their own preferences. Therefore, we aim to conserve the ownership feature of the Clone-and-Own approach, since software engineers rely on our guidance to build the desired product on their own. We strengthened our support in Chapter 6, by estimating the cost of the possible operations and respectively the cost of the possible configuration scenarios. Thus, to derive the desired product, a software engineer can select the appropriate configuration scenario and operations and rely on the estimated costs as an additional argument of support.

In this chapter, we address Challenge 2.b by explaining how product derivation can be accomplished and how the SPL can be evolved after the derivation, by integrating the derived product into it. Hence, we adopt a reactive SPL evolution (Objective 15). To evolve the SPL, when integrating a new product variant, we perform an automated and incremental update of the SPL correlations. This step involves further, an update of the correlation indicators that we introduced in Chapter 6, in order to keep the cost estimation values consistent. Moreover, we address Challenge 2.a to re-structure the features after adding a new product. Hence, to enable the selection of the newly added features in the future configurations, we re-generating the SPL restrictive FM and free FM (Objective 18). The SPL evolution process is presented in Figure 7.1.

Product Derivation

Derivation FM

Several configuration scenarios might be possible to derive a new product variant. Respectively, for each required asset, several operations might be proposed, where only one has to be chosen. We mentioned earlier that we are interested in allowing software engineers to select either a configuration scenario and operations corresponding to it, or select operations from different configuration scenarios. Furthermore, we aim to provide software engineers with additional arguments, to allow them to select a configuration scenario and operations based on their own preferences. Such arguments concern the products involved by each configuration scenario and the asset instances involved in each operation. When software engineers know a configuration scenario is composed of which products, and an operation requires which asset instances, they will be able to make selections based on their own preferences. The proposed variability at configuration scenarios, products, operations and asset instances levels necessitates the existence of a constraints system that controls the selection. For this purpose, we define a derivation FM, which is built according to the corresponding configuration.

Definition 7.2.1 (Derivation FM) :

We define a derivation FM as a constraint system represented in a feature model, offering a controlled selection of the operations to perform to achieve a derivation.

A generated derivation FM uses a classic FM formalism, but serves only in supporting the selection of the operations. The structural features of a derivation FM are the proposed configuration scenarios of a configuration, their corresponding products, the required assets, the possible operations to perform at each asset level and their corresponding asset instances. Configuration scenarios are considered as optional features, as long as more than one scenario is proposed. Similarly, their corresponding products are considered optional, except products that are part of all configuration scenarios are mandatory. The required assets are mandatory, since for each one of them an operation has to be selected. The operations corresponding to a required asset are represented as an alternative group of features, where only one operation for a required asset has to be selected. Respectively, if only one operation is proposed for a certain asset, it is represented as a mandatory feature. The asset instances of an asset are represented as an or group of features, since more than one instance can be required by a selected operation. If an instance is required by all possible operations of its asset, it is represented as mandatory. Similarly, if only one instance is proposed it is represented as mandatory. The constraints between the derivation FM features are constructed as follows:

-A configuration scenario implies an operation or an or group of operations (when a configuration scenario proposes more than one operation for a required asset).

-An operation implies an asset instance or an and group of asset instances (when an operation requires more than one asset instance for a required asset).

-An asset instance implies a product or an or group of products (when the asset instance is exploited by more than one product).

Definition 7.2.2 (Derivation scenario) :

We define a derivation scenario of a given configuration cf noted as ds(cf ), as the set of operations selected from the derivation FM to derive the desired product.

Selecting the operations to perform from derivation FM is a time-saving practice, since i.e. if a configuration scenario is selected, its corresponding operations and asset instances remain selectable, while the other ones are automatically disabled. Similarly, when an operation is selected, its corresponding asset instances are selected and its adjacent operations are deselected.

Example 20: Running example derivation FM

The generated derivation FM of the configuration cf 4 of the running example is shown in Figure 7.2. It represents the four possible configuration scenarios as optional features and there corresponding products. Since product p 2 is needed in the four configuration scenarios, it is a mandatory feature. For the assets DeleteM atch.java and match.jsp, since there exists one possible operation that requires one asset instance, their corresponding operation and asset instance are mandatory. The assets style.css and SaveM atch.java have several possible operations, therefore, their possible operations are represented within an alternative group, enforcing the selection of only one operation. On the other side, their asset instances are represented within an or group, since an instance might be required by more than one operation. The asset instance style.css 2 is mandatory, since it is required by all the three possible operations of the asset style.css. The features "ConfigurationScenario", "Products", "Assets", the features corresponding to the assets names "DeleteMatch.java", "style.css", "match.jsp", "SaveMatch.java", and the features starting with "Operations_" and "Instances_" are structural level features.

Selection Factors

Our approach allows the selection of a configuration scenario and operations based on three factors: numbers and indicators, developer preferences and cost estimation.

Numbers and indicators

Software engineers can rely on numbers and indicators to select an appropriate configuration scenario. For instance, they might be interested in selecting the configuration scenario involving the least number of products or the configuration scenario that has the least number of operations that require an asset modification.

Example 21: Selection based on numbers and indicators

When achieving the configuration cf 4 of the running example, a software developer might be interested in selecting the configuration scenario cs 1 since it is composed of the least number of products (only p 2 ), or the configuration scenario cs 3 having the least number of operations that require a modification of assets.

Developer Preferences

We also allow software developers to select the suitable scenario or operations to perform based on their personal preferences, according to their experience in developing the SPL product variants. A software developer might be interested in selecting the configuration scenario that is composed of the products that she is most familiar with. Moreover, the generated derivation FM allows to filter the operations based on the deselection of some undesirable products. Further, the derivation FM allows to filter operations by deselecting undesirable instances of assets whenever possible, such as old or untrusted instances. Thus, the constraints system allows not only to take the developer preferences into consideration, but also to reduce the number of decisions to be taken that simplifies the construction of the derivation scenario.

Example 22: Selection based on developer preferences

When achieving the configuration cf 4 of the running example, a software developer might be interested in working with configuration scenario cs 3 that involves p 3 , which is a recently developed product, instead of working with cs 1 that involves p 1 , which became an old product.

Cost Estimation

The second factor is to provide an estimated cost in terms of development effort and time for each operation and respectively for each configuration scenario. The cost estimation proposed in Chapter 6 is an additional selection indicator that software developers can rely on. For instance, a software developer might select the configuration scenario having the least estimated cost. Similarly, she might select the operation having the least cost at each asset level, in order to compose the derivation scenario. Moreover, a software engineer has the possibility to select operations that do not necessarily belong to the same configuration scenario, as long as she selects one operation for each required asset. For instance, she can select the operations having the lowest estimated cost for all required assets, regardless if the operations belong to the same configuration scenario or not.

Example 23: Selection based on cost estimation

When achieving the configuration cf 4 of the running example, a software developer might select the configuration scenario cs 3 (cf 4 ) that has the least estimated cost (see Table 6.8) and is composed of less products compared to cs 4 (cf 4 ) having the same estimated cost. In this same concept, she might prefer the selection of the operation ET A, style.css 2 , {DeleteM atches} for the asset style.css, since it has the least estimated cost (see Table 6.7) from the three possible operations of style.css.

Product Line Evolution

Despite that the main goal of our approach is to guide the derivation of new product variants from the SPL, we consider that it is essential to permit the reuse of the newly derived products in future derivations. On the one side, a newly derived product variant can be requested in future, hence, it must be integrated in the SPL, in order to be offered as one of the available ready-made product variants. On the other side, the features introduced by the newly derived products might be requested in future by other products, and therefore, their injection in the SPL feature models improves reuse. Similarly, the newly constructed asset instances resulting from the derivation are necessary to accomplish the implementation level of the injected features, as well as the existing ones.

The product line evolution is achieved through the following activities:

1. Product variant integration 2. Correlations and correlation indicators update 3. Feature models re-generation It is important to mention that, product line evolution is necessary, only when a configuration is not achieved by integrality. In other words, a product resulting from a valid configuration is already provided by the SPL, and hence, does not require a product line evolution. Otherwise, a configuration made in restrictive mode and introducing new features, or made in free mode, produces a new product that is not offered by the SPL, and hence, requires a product line evolution to integrate it.

Product Variant Integration

Once a software developer composes the derivation scenario of the desired product, she is provided with the implementation files (asset instances) corresponding to the selected operations in the derivation scenario. At this level, the configuration FM is memorized, including if any, the new features added during configuration. Once the software developer fulfills the implementation of the desired product, the integration can be achieved. A product variant integration consists first of the addition of a new product p j in the SPL products P. Second, it consists in an automated identification of the newly added assets (if any) and asset instances.

Example 24: Integration of product p 4 of the running example

The product p 4 shown in Table 7.1 is the result of the configuration scenario cf 4 . The integration of product p 4 in SPL led to the identification of a new asset instance style.css 4 . Whenever a configuration leads to the derivation of a new product variant that is not provided by the SPL, the feature models of the SPL (restrictive and free) require an update, regardless if the product variant introduces new features or implements a set of features that are not realized by an existing variant. As mentioned earlier, when a selected set of features during a configuration do not correspond to a valid configuration, the selected features are saved in a configuration FM, in order to be used to update the SPL feature models once the corresponding product is integrated.

To re-generate the restrictive FM, we perform a FAMILIAR merge operation [START_REF] Mathieu Acher | Familiar: A domain-specific language for large scale management of feature models[END_REF] on the restrictive FM and the newly derived product FM, to obtain an updated restrictive FM, that integrates the configuration of the integrated product.

An update of the SPL restrictive FM implies a re-generation of the free FM, in order to remain consistent. However, the free FM is a constraint-free FM with all features optional except the root feature. Therefore, a re-generation of the free FM is performed only if the integrated product variant introduces new features that were not offered by the SPL prior to its derivation.

Correlations and Correlation Indicators Update

Integrating a new product variant into the SPL requires an update of the correlations between features and assets and between features and asset instances, in order to keep the correlations consistent with the SPL artifacts changes. Consequently, an update of correlations implies an update of the correlation indicators that are used during cost estimation. Example 26: Free FM eventual re-generation Since the derivation of product p 4 of the running example did not introduce new features that were not provided by the SPL, the free FM does not require a re-generation. However, if we consider a new product p 5 that introduces a new feature Stats, which is not offered by SPL, the integration of p 5 would require a re-generation of the free FM.

Correlations Update

We provide an automated and incremental update of the SPL correlations. Correlations updates eventually touch the features implemented, assets employed, and asset instances exploited by the integrated product variant.

At feature to asset correlations level, three possible situations might occur:

-An addition of a new correlation.

-A removal of an existing correlation.

-A transformation of an equivalence correlation into an implication correlation.

At feature to asset instance correlations level, two possible situation might occur:

-An addition of a new correlation.

-A removal of an existing correlation.

The following rules must be applied in the given order.

An addition of a feature to asset correlation occurs in two conditions:

1. If the integrated product implements a new feature nf that was not implemented by any other product of SPL and employs a new asset na that was not employed by any other product, then a new feature to asset equivalence correlation is added: nf ⇔ na.

Consequently, a new feature to asset instance correlation is added between nf and na 1 , where na 1 is exploited by the integrated product and corresponds to the first asset instance of an.

2. If the integrated product implements a new feature nf that was not implemented by any other product of SPL and employs an existing asset ea that was already employed by another product, and the integrated product exploits a new asset instance ea n of ea that was not exploited by any other product, then a new feature to asset implication correlation is added: nf ⇒ ea. Consequently, a new feature to asset instance correlation is added between nf and ea n .

A removal of a feature to asset correlation occurs in the following condition:

1. If there exists a correlation between an existing feature ef and an existing asset ea, and the integrated product implements ef without employing ea, the correlation c(ef, ea) is removed. Consequently, since none of the instances of ea is exploited by the integrated product, all feature to asset instance correlations between ef and the asset instances of ea are removed.

A transformation of an equivalence correlation to an implication correlation at a feature to asset correlation level occurs in only one condition:

1. If there exists an equivalence correlation between an existing feature ef and an existing asset ea, and the integrated product does not implement ef but still employs ea, and a new instance ea n of ea is exploited by the integrated product, then, the equivalence correlation ef ⇔ ea is transformed into an implication correlation ef ⇒ ea. Consequently, a new correlation is added between ea n and each existing feature that ea is in correlation with and implemented by the integrated product.

Example 27: Running example correlations update

Referring to Table 7.1, the integration of the product p 4 in the SPL of the running example led to the addition of the following feature to asset instance correlations between the newly added asset instance style.css 4 and the features implemented by p4. The added correlations of Table 7.2 involve an update of the correlation indicators of the running example. We represent the added or updated entries of the correlation indicators tables in bold in the tables shown below. An entry for the asset instance style.css 4 is added to the asset instance correlated features table (Table 7.3) which is correlated to 3 features (the ones implemented by p 4 ). 4 3 DeleteM atch.java 1 1

The feature correlated assets (Table 6.2) does not require any update since the integration of product p 4 did not require any update of correlations between features and assets.

The addition of a new instance of style.css is reflected by the updated entry of this asset in the instances of assets (Table 7.4). The addition of the new correlations presented in Table 7.2 implies an update of their corresponding entries in the features correlated asset instances (Table 7.5). The updates of the correlation indicators illustrated above affect the correlation degrees, as shown in Table 7.6. New entries corresponding to the correlations between the added asset instance style.css 4 and the features in correlation with are added. In addition, some entries corresponding to the other instances of style.css and the features in correlation with where updated. An update of a correlation implies an update in correlation indicators. The correlation degree between a feature f and an asset instance a i noted cd(f, a i ) is affected by four indicators that must be updated, in order to reflect the update on the correlation degree. These indicators are:

-The number of features correlated to the asset instance |F (a i )|. This indicator is affected by the addition or removal of a correlation between the asset instance a i and any feature.

-The number of assets correlated to the feature |A(f )|. This indicator is affected by the addition or removal of a correlation between the feature f and any asset.

-The number of instances of the asset |AI(a)|. This indicator is affected by an addition of a new instance of the asset a.

-The number of instances of the asset that the feature is in correlation with |AI(f /a)|. This indicator is affected by an addition or a removal of correlations between the feature f and the instances of the asset a.

Product Line Re-Definition

The migration process presented in Chapter 4, can occur during the lifetime of the product line. When refactoring shared assets is needed, or redefining existing feature models and their structure, software engineers can decide to re-create the product line by relaunching the migration process. Since this process is automated, it can done at any time without affecting the productivity. It is then a support for evolution of the SPL.

Summary

With this chapter, we conclude the contribution part of our dissertation. Our contribution consisted on guiding the derivation of new product variants from an SPL based on C&O and evolving the SPL by integrating the newly derived variants into it. After defining the SPL and migrating its products and their artifacts in Chapter 4, we presented how we support the configuration of a desired product in Chapter 5, by identifying the possible configuration scenarios and operations to perform to achieve the derivation. In Chapter 6, we provided a cost estimation for the configuration scenarios and operations.

In this chapter, we presented how we support the derivation of the desired product, as a subsequent step after the configuration. Once the software engineer selects the required features for the desired product, we propose by means of a derivation FM the possible configurations and operations to perform at asset level. Hence, a software engineer selects the appropriate configuration scenario and operations based on indicators and number, her personal preferences and the cost estimation provided. We provide a reactive SPL evolution by integrating the newly developed PVs. A product variant integration consists of an automated identification of the new artifacts, an auto re-generation of the restrictive and free FMs and an automated and incremental update of the correlations and correlation indicators. Therefore, the new variants and their corresponding artifacts become subject to reuse in future derivations.

Part III Implementation and Validation

Introduction

In this chapter, we describe the implementation of our approach. We implemented our approach by developing a framework called SUCCEED that stands for SUpporting Clone-andown with Cost-EstimatEd Derivation. SUCCEED allows to migrate a set of product variants into an SPL to support the configuration and derivation of a new variant and to permit an enrichment of the SPL with the newly derived variants. The time this dissertation was written, SUCCEED was partially implemented with a graphical user interface, while other modules of its implementation where available only with a command line interface. Hence, we aim to provide in future a complete graphical user interface support for SUCCEED that covers all its modules. SUCCEED is developed using Java technology, based on a Java web service, and the graphical interface consists of a web application developed mainly using JavaScript AngularJS framework.

Migration Process

Product Line Initialization

In order to integrate existing PVs, the name of the SPL to be created and the path under which it will be located are specified by a software engineer. Under this path, SUCCEED specifies a git repository [START_REF] Chacon | Pro Git, Second Edition[END_REF], in which the migrated product variants will be pushed.

Ignoring files from being tracked is a useful functionality provided by git. SUCCEED allows to specify the files and directories to be ignored, such as specific type of files and external libraries, which do not belong to the product line artifacts.

Product Variants Supply

The existing product variants to be migrated are given as an input to SUCCEED. For each PV, a unique name has to be assigned to it, and the repository in which its artifacts are located has to be specified. In addition, an FM representing the features that it implements has to be provided. A git branch [START_REF] Chacon | Pro Git, Second Edition[END_REF] is created for each migrated PV, and the product name is assigned to the branch name. The implementation files corresponding to a PV are committed within its branch. As a result, the product line repository will consist of n branches and n commits (one commit per branch) where n is the number of existing product variants. The adopted git structural definition of the SPL enables a simple retrieval of an existing product, whenever it is required by a configuration. Moreover, it provides an independent evolution of each variant within its branch, when this evolution consists of a maintenance of the implementation code and not an update of the variant at specification level (features).

Restrictive FM supply

After supplying the PVs with their corresponding FMs, a global FM of the product line is generated by SUCCEED, as the FAMILIAR merge [START_REF] Mathieu Acher | Familiar: A domain-specific language for large scale management of feature models[END_REF] of the PVs FMs. This is what we call in our approach the restrictive FM. The restrictive FM provides an abstract representation of the supplied PVs in terms of business features. It has to allow the configuration of the exact set of the migrated PVs. A structural defect in the provided FMs of the PVs or of the restrictive FM prevents the initialization of the SPL. For instance, this might result of PVs not having a common root feature in their corresponding FMs.

Free FM generation

To enable configurations that break the constraints imposed by the restrictive FM, the free FM has to be generated. We defined an algorithm that applies the following operations on a copy of the restrictive FM:

1. Remove all constraints 2. Remove a group (or, alternative) and connect its children features directly to the parent of the group as optional features 3. Transform a mandatory feature into an optional feature (except for the root feature)

Since the free FM has all its features optional (except the root) and has constraints, any set of selected features including the root can be selected during configuration, allowing a complete reuse at features level.

Assets and asset instances identification

From the product variant base, SUCCEED identifies the common artifacts of several products, those that are unique and those that exhibit variations. We characterize as "assets", the file path of the artifacts and as "asset instances" the artifacts themselves (implementation files). Thus to the same asset can correspond to several asset instances (implementations).

Algorithm 1 describes the mechanism that we adopt to define the SPL products and extract assets and their corresponding asset instances from the PVs. The algorithm loops over the implementation files of each PV. For each PV we define a corresponding product in SPL. For each file in a PV, if it does not exist an asset in SPL assets (A) that has the same path name as the file, a new asset is created and the path name of the file is assigned to it. Then, a new asset instance is created, an instance number 1 is assigned to it, in addition to the path corresponding to its implementation file. The asset instance is registered as an instance of the asset (being the first in this case), and registered as one of the instances exploited by the product created during the current iteration. As well, the asset is registered as one of the SPL assets. Otherwise, if there exists an asset having the same path name, an additional test is done to check if one of its instances has the same implementation of the file. We consider that two implementations are equal if their content is similar, regardless if their string values are equal [START_REF] Chacon | Pro Git, Second Edition[END_REF]. If so, the identified instance is appended to the list of asset instances exploited by the product. Otherwise, a new instance is created, assigned a new instance number (computed from the number of instances that the asset already has), in addition to the path corresponding to its implementation file. As well, the asset instance is appended to the instances of the identified asset, and to the asset instances exploited by the product. for all f ile ∈ f iles(pv) do instanceN o(a i ) ← 1 A.append(a)

Correlations Identification

Algorithm 2 represents how correlations are identified. After identifying the SPL products P, features F collected from the products FMs, assets A and their corresponding instances, SUCCEED identifies the SPL correlations C. As presented in Algorithm 2, for all assets A, for each a ∈ A, we loop on all features of F. A correlation between an asset a and a feature f holds each product implementing f employs a and each product employing a implements f , hence if P (a) = P (f ), or if each product implementing f employs a, hence P (a) ⊂ P (f ) and for each instance a i of a exploited by a product implementing f , a i is not exploited by any product that is not implementing f . When a correlation holds, if P (a) = P (f ) the correlation type is an equivalence, otherwise it is an implication. Each feature to asset correlation c(f, a) is appended to the SPL correlations C. For each identified feature to asset correlation, the instances of the asset must be evaluated to determine if they are in correlation with the feature. A feature to asset instance correlation holds if there already exists a feature to asset correlation c(f, a), and there exists at least a product that implements f and exploits a i . Moreover, each feature to asset instance correlation is appended to the SPL correlations C.

If an artifact (feature, asset, or asset instance) has no correlations, the SPL is not considered complete. For this reason, SUCCEED displays a warning informing that the tool does not guarantee the support and evolution of the SPL. if P (a) = P (f ) then C.append(c(f, a))

12:

for all a i ∈ AI(a) do

13: if ∃ p, f ∈ F (p), a i ∈ AI(p) then 14: new c(f, a i ) 15:
C.append(c(f, a i )) end for 20: end for

Configuration Process

SUCCEED provides two configuration modes. Figure 8.1 shows a configuration in restrictive mode and Figure 8.2 shows a configuration in free mode. When a new configuration is initiated, the default configuration mode is restrictive mode. In a restrictive mode, mandatory features are selected automatically and cannot be deselected, as shown in Figure 8.1 i.e. features Rounds, Stages, Groups, Standing. In contrary, optional features, such as P layers, Replays, Calendar and N ews, are by default unselected, and can be selected (i.e. Calendar and N ews) or deselected (i.e. Replays). A deselection of a parent feature, implies a deselection of its children features. Further, depending on the cross-tree constraints of the restrictive FM, a selection of a feature might imply an automatic selection or deselection of other features in the FM configuration i.e. if no product implements both P layers and Replays, selecting the feature P layers will automatically deselects the feature Replays.

Switching from restrictive mode to free mode during a configuration can be made with a single click. A first-time switch from restrictive to free mode takes the actual state of the configuration in restrictive mode as an initial state during the free mode. In other words, all selected features are selected in free mode, and all deselected features are deselected in free mode. Since no mandatory features in free mode except the root feature, all features can be deselected. As shown in Figure 8.2, the feature Rounds i.e. which is initially a mandatory feature in restrictive mode can be deselected in free mode since it became an optional feature. Similarly to restrictive mode, if a parent feature is deselected its children features are automatically deselected, hence, deselecting Rounds will automatically deselect Stages, Groups and Standing. In contrary to restrictive mode, no constraints are present in free mode, hence, selecting or deselecting a feature affects only its children features. Since all features except root are optional in free mode, we provide two button actions to facilitate the selection/deselection of features. The first option allows to auto-select all unselected features, and the second allows to auto-deselect all unselected features. Hence, a software engineer can either select all required features and use the auto-deselect action to deselect all other unrequired features, or deselects all unrequired features and use the auto-select action to select all required features. Recall that those two actions are available only in free mode.

Switching back to restrictive mode is again possible. This action saves the actual state of the free mode and switches back to the last state of the restrictive mode before the switch made to free mode. Thus, a current configuration can have two independent flows in each mode.

One of the important functionalities that we introduced in our approach is the possibility of adding new features during the configuration. This functionality is available in both restrictive and free mode. A new feature can be added only as a child for a selected feature i.e. as show in Figure 8.1 a child feature cannot be added for the feature P layers which is currently unselected neither for the feature Replays which is currently deselected. A feature added in restrictive mode is not added automatically in free mode, except for the first-time switch from restrictive to free mode. Similarly no two features can have the same name. It is possible to add a feature in restrictive mode and adding it with the same name later on in free mode, however, it is prohibited to add two new features with same name in same mode, or also adding a new feature with the name of an existing one. A feature added during a configuration is not visible in other configurations. It becomes visible only if the configuration was achieved by a derivation of a new product and the product is integrated into the SPL.

The configuration process is accomplished by selecting all the required features, deselecting all the unrequired ones and adding the new features if any. Once done, the configuration is saved and the selected features are memorized. In addition, the new features added to the configuration are memorized. Next is the derivation process where operations to perform to derive the desired product are to be selected.

Derivation Process

The derivation process is dependent on the configuration process. If the configuration is done in restrictive mode, this means that an existing product implements all and only the required existing features for the desired product. Hence, SUCCEED proposes the implementation files of this product as a solution and mentions the need of integrating the new features added during configuration, if any, in the proposed files. Hence, if new features have to be added, our approach does not provide any guidance concerning which assets are suspect to modification to integrate the new features.

If the configuration is done in free mode, SUCCEED proposes the possible configuration scenarios and operations, in addition to their corresponding estimated costs, based on the generated derivation FM. Figure 8.3 shows the SUCCEED interface corresponding to the derivation FM of the running example. Recall that the derivation FM is automatically generated according to the automatically identified configuration scenarios and operations as a subsequent step to the configuration process.

According to Figure 8.3, the interface displays the four possible configuration scenarios of the running example with their corresponding estimated cost, where only one configuration can be selected. Recall that the default estimated cost corresponding to each configuration scenario, prior to operations selection, is the sum of its lowest cost operation for each required asset. This value might be updated upon the selection of operations, i.e. in case an operation having a higher cost was selected for a required asset. A flag icon (see configuration scenario cs 3 ) is displayed next to the recommended configuration scenario, the one having the lowest estimated cost. The configuration scenarios cs 3 and cs 4 have the same estimated cost, since the operations having the lowest cost at each asset level are similar for both. However, cs 3 is given the recommended configuration scenario title, because its products are subset of the ones of cs 4 .

Product p 2 is displayed as mandatory, because all the proposed operations require an asset instance exploited by p 2 . Deselecting an optional product implies an automatic deselection of the asset instances exploited only by it, in addition to the operations that use those instances. For example, deselecting p 1 implies a deselection of instance style.css 1 which is not exploited by another product, and a deselection of the first operation of style.css which uses this instance.

For an asset having one operation, the operation is displayed as mandatory, similarly to the instances that it uses. The assets match.jsp and DeleteM atch.java are two examples of this situation.

Once a configuration scenario is selected, all operations that do not correspond to it are automatically deselected. For example, if cs 3 is selected, the first operation of style.css is automatically deselected since it uses the instance style.css 1 that is not implemented by any of the products p 2 and p 3 of cs 3 . Furthermore, the operations composed of a single CRT action corresponding to the selected configuration scenario are automatically selected since their estimated cost is 0. For instance, when cs 3 is selected, the CRT operation of SaveM atch.java is automatically selected, and consequently, its selection implies an automatic deselection of the first operation of SaveM atch.java, since only one operation can be selected per asset. Moreover, if more than one operations are proposed for a required asset, and one the proposed operations is a single CRT operation, an exclamation mark icon is displayed near the other proposed operations for the asset, to represent a warning that there already exists an asset instance implementing all and only the required existing features. The first operation proposed for SaveM atch.java represents this situation, where this operation proposes the construction of a new instance, that is supposed to be similar to the already existing instance SaveM atch.java 2 . Furthermore, deselecting an asset instance implies an automatic deselection of the operations that use the deselected asset instance. For example, deselecting style.css 1 for considering it an old undesired instance for derivation, implies an automatic deselection of the first operation of style.css that uses this instance.

Finally, for each required asset, one operation has to be selected. Recall that the operations selection can be made regardless the configuration scenarios they belong to, by selecting operations that belong to different configuration scenarios.

Evolution Process

Once the derived product is constructed, it has to be integrated in SUCCEED in order to permit its systematic reuse and respectively the reuse of its artifacts for deriving new variants.

To integrate the derived product, its implementation files are provided. Hence, a new branch is created in the git repository that contains the SPL products, where the name of the product is used as the branch name. The provided implementation files are committed within the created branch.

The integration of a new product implies an automated discovery of new assets and asset instances, and an automated update of the SPL correlations and correlation indicators, as explained in Chapter 7. The identification of a new file (a file that was not employed by any other existing product) in the provided implementation files of the derived product, leads to the identification of a new asset and a new instance corresponding to it. The identification of new instances of an asset is done by performing a diff operation to compare a certain file with the existing instances having the same name.

To permit the reuse of the integrated product and its corresponding artifacts in future derivations, SUCCEED performs an automated update of the restrictive and free FMs as explained in Chapter 7. Consequently, the features added during the configuration of the integrated product if any, become visible in new configurations. Further, the selection of the set of features implemented by the integrated product refers now to a valid configuration that implies an automated derivation of the newly integrated product.

Summary

In this chapter, we presented an overview of the SUCCEED framework that implements our approach. The SUCCEED framework covers the life cycle of our approach. It first allows the migration of existing product variants into an SPL. Second, it permits the generation of new configurations in both restrictive and free modes. Third, it supports the derivation with the possible configuration scenarios and operations, as well as their estimated cost. Finally, it enables the enrichment of the SPL with the newly derived products.

Nowadays, not all modules of SUCCEED are supported with a graphical user interface. Therefore, we aim to provide graphical interface to the command line interface modules of the approach and connect its modules in a standalone framework.

Introduction

We validate our approach in this chapter based on experiments made on a case study consisting of a family of 8 product variants. We measure and analyze indicators corresponding to the configuration, derivation and integration of new product variants, in order to evaluate the effectiveness of our approach. In addition, we present in this chapter some limitations of our approach and threats to validity.

Validation

Experiments

We achieved the validation by analyzing statistical information that we collected upon the configuration and the incremental derivation of 5 new variants and their incremental integration in the case study SPL that consists initially of 3 variants. By incremental derivation and integration, we mean that each newly derived variant is integrated in the SPL, the SPL restrictive and free FMs are auto re-generated and the correlations are updated prior to the derivation of another variant. Hence, each newly derived variant becomes a support element during the upcoming derivation. The SPL comprises when it has its 8 PVs a total of 93 features, 271 assets and 296 asset instances with an average of 66 features, 214 assets and 4.7KLOCs per PV. Table 9.1 shows the number of features added during each configuration and the number of assets and asset instances added to the SPL after the derivation of the PV corresponding to each configuration. In order to evaluate the effectiveness of our approach, we measured and analyzed significant indicators (see Figure 9.3) concerning the number of configuration scenarios and operations of the 5 configurations of the case study. The 8 PVs of the case study correspond to a family of Web applications developed to post news, media, and results of a soccer competition 1 . Each PV consists of a restful web service written in Jersey, a database structure built in MySQL, and client-side Web interfaces written in HTML, CSS and JavaScript frameworks including AngularJS, JQuery, UI-Router, Bootstrap and others. Table 9.2 shows the main features implemented by the 8 product variants. the latter implements M atch f acts and also M atch stats, which corresponds to the statistical tables displayed below the match facts (see Figure 9.1b and Figure 9.2b). Further, since product p 7 does not implement the feature N ews, the "News" item is not part of its menu. On the contrary, product p 8 implements the feature N ews (see Figure 9.2c) and the item "News" is part of its menu.

Results analysis

As shown in Figure 9.3a, the number of configuration scenarios per configuration increases considerably whenever the family of software products becomes richer. This is due to the injection of the newly derived products in the SPL, that become candidates for derivation of other products. Respectively, Figure 9.3b shows that the average number of products involved in a configuration scenario increases too. Identifying the possible configuration scenarios for a given configuration is time-consuming if done manually, especially when the SPL becomes mature, since it is proportional to the number of products that partially implement the required features. Our approach resolves this difficulty by automating the identification of the possible configuration scenarios. When the number of products involved in a configuration scenario becomes elevated, software engineers aim to prioritize the possible configuration scenarios based on preferences over products, i.e. by preferring configuration scenarios that involve the products that they are most familiar with. The generated derivation FM provided by our approach satisfies this need by allowing software engineers to filter the possible configuration scenarios by deselecting undesired products. Figure 9.3c shows that the number of required existing assets per configuration is high for the case study with an average of 88%. In other words, each newly derived product is constructed by reusing around 88% of the SPL assets. This indicator reflects the degree of reuse that SPLs can offer in general and our approach in particular. Identifying the required assets for a product derivation can be a tedious and time-consuming task when done manually, especially when the SPL consolidates a large amount of assets. Our approach copes this problem by providing an automated discovery of the required assets for derivation.

Despite that the number of required assets can be large, the number of assets to modify might be few, same as shown in Figure 9.3d, where for the case study the average number of assets to modify is only 2%. This indicator might widely vary in other case studies, depending on the variability level it provides, as well as the features interaction level, reflected in the way in which the assets are constructed. Regardless if the number of assets to modify is low or high, software engineers have to identify between the required assets, which ones are to be modified to achieve the derivation. This step is expensive if done manually, since it requires a content check of the asset instances of each required asset. In contrary, our approach automatically identifies the assets that require modification, based on the automatically defined operations at each asset level. Hence, software engineers recognize which asset instances have to be cloned and retained for derivation without being modified and which asset instances require to be cloned and modified. Figure 9.3e shows that the average number of operations per asset for each configuration is very low in this case study. This is due to the low number of assets to modify, where for most assets the only proposed operation consists of a single clone and retain (CRT) action. For the assets that have several proposed operations, the provided cost estimation at operation level facilitates the choice of a favorable operation. Moreover, the selection of a favorable operation can be made based on the asset instances involved in the operation, since the derivation FM specifies the asset instances of each operation.

Finally, the elevated number of possible configuration scenarios makes difficult the choice of a favorable scenario for derivation. However, the cost estimation provided by our approach can facilitate the choice of a favorable scenario. Figure 9.3f shows that the coefficient of variation between the estimated cost of the configuration scenarios ranges between 36% and 99% with an average of 64%. This means that the variation between the estimated cost of the configuration scenarios is elevated, which can facilitate the choice of a favorable scenario. Moreover, the elevated coefficient of variation reflects that if software engineers select the configuration scenarios having the lowest estimated cost, they are supposed to save a considerable amount of time and effort during derivation.

Overtaking Challenges

Challenge 1.a consisted on identifying mappings between features and assets. The average number of assets to modify per configuration scenario (see Figure 9.3d) decreases as long as new products are integrated in the SPL. This is due to the purification of the identified correlations. Since correlations are updated each time a new variant is integrated in the SPL, they get a better level of precision, and therefore, the estimated number of products to modify decreases and the proposed operations become more precise.

Challenge 1.b consisted on identifying the possible configuration scenarios and asset level operations. Our experiments on the case study verified that all possible configuration scenarios and operations where identified and since this step is automated by our approach, it saves a large amount of time compared to a manual identification process.

Challenge 1.c consisted on facilitating the choice of configuration scenarios and asset level operations. Figure 9.3a shows that the number of possible configuration scenarios increases accordingly to the maturity of the SPL. This reflects the necessity of facilitating their selection. As shown in Figure 9.3f, the coefficient of variation between the estimated cost of the possible configuration scenario is high, which facilitates the selection. Moreover, the user preferences options that we proposed contribute in facilitating the selection.

Challenge 2.a consisted on helping the definition of new features when adding new variants and structuring the SPL features after integration. Table 9.1 shows that 25 features where added to derive product p 6 . Moreover, those features where reused in the derivation of the new products (p 7 and p 8 ).

Finally, Challenge 2.b consisted on integrating the newly derived products into the SPL. As shown in Figure 9.3a and Figure 9.3b, the new products where used as part of the proposed configuration scenarios for future derivations. As well, the new features that they implemented where reused in the derivation of new products.

Limitations

A limitation of our approach is that it is dependent on the architecture of the developed SPL. A change in structure or naming of the SPL artifacts affects the identified correlations. However, adhering to the proposed operations during product derivation avoids such inconsistencies. Further, our approach permits to reconstruct the SPL in case a refactoring is needed, without extra efforts or loss of information.

Another limitation is that asset instances are identified at file level, while several related works when performing feature identification or feature location [START_REF] Fischer | Enhancing clone-and-own with systematic reuse for developing software variants[END_REF][START_REF] Martinez | Mining software artefact variants for product line migration and analysis[END_REF], map features to implementation blocks of several files. Such techniques can be complementary to our approach, since we consider that guidance is the most meaningful when provided at file level. Moreover, our approach does not propose any guidelines regarding the modification of code fragments inside files. Therefore, the adapters employed in [START_REF] Fischer | Enhancing clone-and-own with systematic reuse for developing software variants[END_REF] and [START_REF] Martinez | Mining software artefact variants for product line migration and analysis[END_REF] to identify the blocks of artifacts can be used to provide this guidance, especially when the files of the migrated products correspond to artifact types to which adapters are provided. Similarly, the hints proposed by [START_REF] Fischer | Enhancing clone-and-own with systematic reuse for developing software variants[END_REF] when product completion is required to achieve the derivation improve the guidance that can be proposed.

Finally, in our approach we did not take into consideration organizational factors such as coordination between development team members, development phases, criteria selection and prioritization, product release, and customer feedback [BBS11, BWW + 18]. Similarly, we did not integrate international distortions in our approach when defining our cost estimation functions [START_REF] Magazinius | Investigating intentional distortions in software cost estimation-an exploratory study[END_REF]. We consider such factors beyond the core of our approach, especially when our approach aims only to provide guidance without imposing derivation solutions.

Threats to Validity Conclusion Validity

In our experiments, and based on the polyglot nature of the software products we are working on, we concluded that increasing number of products in the SPL increases the number of possible configuration scenarios (see Figure 9.3a). However, in some architectures where features are not propagated on several products, this conclusion might become wrong. Whereas, in our experiments we did not identify a relationship between the average number of products in a configuration scenario (see Figure 9.3b) and the average number of possible operations per asset (see Figure 9.3e). Despite that the graph indicators show this relationship for the case study, we consider that it might not be the case for other case studies.

Internal Validity In our case study, we considered that one of the reasons of the elevated number of required assets (see Figure 9.3c) is due to the architecture of polyglot systems, where feature interaction is elevated. However, other unidentified factors might also affect the number of required assets, especially for case studies of different architectures employing different artifact types.

Construct Validity

The experiments were made on a case study that we developed. Indeed, due to our limited time and resources, we could not achieve experiments on industrial case studies, to measure the effectiveness of our approach on real industrial situations. If done, it can bring valuable indicators that show the variation between the time spent by software engineers to manually accomplish tasks such as identifying configuration scenarios, required assets, assets to modify and operations, compared to the automation that our approach provides of those tasks.

External Validity It is clear that the order in which the configurations and respectively the derivation and integration of new products are made produces different outputs of the experiments results. Our approach guarantees for the experiments that we made, that no matter what is the order in which the products are derived and integrated in the SPL, the final state of the SPL in terms of features models, identified artifacts and correlations is the same. Since we did not perform experiments on all kinds of software families, we are not able to validate that our assumption can always be true. Similarly, the outcome of our experiments corresponds to the structure of the case study, hence, another case study having different architecture such as monoglot systems, and using other artifact type such as images, might produce different results.

Summary

In this chapter, we validated our approach on a real case study to demonstrate its effectiveness. The indicators of Figure 9.3 reveal the importance of providing the necessary support to software engineers to accomplish the derivation of new products. Our approach automates several time-consuming and tedious tasks, such as the identification of the possible configuration scenarios and required assets, the identification of the assets that require modification, and the operations to perform to achieve the derivation. Moreover, our experiments show that the generated derivation FM for each configuration facilitates the choice of the favorable configuration scenario and operations, by providing an environment allowing software engineers to make their choices based on their own preferences and based on the cost estimation of the configuration scenarios and operations.

Finally, we presented in this chapter some limitations of our approach in addition to the conclusion, internal, construct and external threats to validity.

Conclusion

In this dissertation, we proposed an approach to support the derivation of unplanned product variants in a software product line context using clone-and-own practice. The proposed approach allows the integration of existing product variants into a software product line. Moreover, it supports the derivation of new product variants using clone-and-own, by proposing the possible scenarios and operations to achieve the derivation. This support is strengthened by a cost estimation of the possible scenarios and operations and a constraints system guiding software engineers to perform the derivation based on their own preferences. Furthermore, the proposed approach enables the integration of the derived products into the software product line, to permit their reuse in future derivation.

Our approach addresses software families developed in a feature-oriented development context using clone-and-own, where the functionalities implemented in product variants are expressed as business-level features. To allow a systematic reuse of product variants, our approach offers an automated integration of existing product variants into a software product line. This process is accompanied with an automated and controlled construction of a feature model called restrictive FM, to enable the configuration and automated derivation of the existing product variants.

Since arising customer requirements and technology changes necessitate the development of new products, our approach fulfills this need by allowing the derivation of new product variants from the constructed product line. Therefore, our approach allows the definition of new features during the configuration of the restrictive FM, whenever the features required for a new product consist of a set of features realized by an existing product and some new features not implemented yet. However, if the required features are not realized by a single product, the restrictive FM does not permit their selection, regardless if they contain new features or not. For this purpose, another feature model is generated, as a constraint-free version of the restrictive FM, where all features except root feature are optional. Indeed, this feature model called free FM allows the configuration of new products, by selecting a set of features that is not realized by a single existing product, with the possibility of defining new features throughout the configuration as well.

In order to reuse artifacts from existing products to derive a new one, the products implementing the required existing features, and respectively the assets that accomplished their implementation have to be identified. Therefore, we defined an automated mechanism to identify mappings between the product line artifacts. Mappings are called correlations, and correlations are established between features and assets on the one side, and between feature and asset instances on the other side. Asset instances correspond to the versions of the assets.

Relying on the identified correlations, and according to the features selected in a configuration, our approach automatically determines the possible configuration scenarios and respectively operations to perform, in order to achieve the derivation of a new product. Operations correspond to actions to take over asset instances, in order to construct the necessary asset instances for the derivation. Such actions can be a clone of an existing instance, with the possibility of adding or removing implementation fragments corresponding respectively to required or unrequired features. A configuration scenario is a set of products that constitutes a source to achieve the derivation of a new product. Hence, to support software engineers in achieving the derivation, our approach proposes its possible configuration scenarios and operations. We strengthen our support by generating a constraints system for each configuration, in order to facilitate the selection of a configuration scenario and operations. This constraints system is constructed as a feature model that we call derivation FM. The features of the derivation FM are the configuration scenarios, their products, their operations and their corresponding assets and asset instances, while the constraints correspond to the dependencies between them. Hence, the generated derivation FM allows software engineers to select the favorable configuration scenario and operations based on their own preferences i.e. by selecting the configuration scenario that requires the least number of operations imposing a construction of a new asset instance, or the configuration scenario composed of the products that they are most familiar, or the operations involving the asset instances that they worked on.

Since the number of possible configuration scenarios and operations to achieve a product derivation can be elevated, we defined a cost-estimation function to estimate the cost in terms of efforts and development time that might be required to perform an operation. Respectively, the operations estimated cost allows to estimate the cost of configuration scenarios. Thus, we provide software engineers with the cost estimation as an additional argument that they can rely on to select their favorable configuration scenario and operations.

After the derivation of a new product, to allow its reuse in future derivations, our approach permits its automated integration in the product line. Hence, our approach enables the evolution of the product line, by integrating new products and respectively, by automatically updating the correlations and auto re-generating the restrictive and free FMs.

We implemented our approach by developing a framework called SUCCEED that stands for SUpporting Clone-and-own with Cost-EstimatEd Derivation. SUCCEED provides graphical user interfaces, which allow to migrate a set of product variants into a product line, support the configuration and derivation of a new variant, and the enrichment of the product line with new products.

We validated our approach based on experiments made on a real case study consisting of 8 product variants, by performing an incremental derivation and integration of 5 variants into a product line composed initially of 3 variants. The results revealed the importance of our approach in providing the necessary support to software engineers to accomplish the derivation of new products. Experiments showed that our approach supports and simplifies the derivation by automating several time-consuming and tedious tasks, by facilitating the choice of the favorable configuration scenario and operations and by providing an environment allowing software engineers to make their choices based on their own preferences and based on the proposed cost estimations.

In our approach, we consider software engineers as the main decision-makers. Hence, we support them with valuable elements to derive new products by themselves, without imposing on them a specific or automated derivation solution. By this, we preserve the "own" strength point of the clone-and-own approach, where software engineers own their code since they know the source of the clones and how it was constructed.

Perspectives

In our perspectives, we aim to validate our approach on more sophisticated systems of different architectures such as industrial case studies. Further, we aim to measure the effectiveness of our approach in terms of efforts and time saving, when compared to the classic clone-and-own approach. Such experiments should allow to determine valuable indicators that show the variation between the time spent by software engineers to manually accomplish derivation tasks compared to the automation that our approach provides of those tasks.

We consider our approach as complementary to several related works. Therefore, as future work, we are interested for example in integrating the techniques used by [START_REF] Fischer | Enhancing clone-and-own with systematic reuse for developing software variants[END_REF] and [MZB + 15b], to identify mappings between features and assets of monoglot product variants, but preserving the clone-and-own decisions on behalf of software engineers.

Finally, we give interest in integrating our approach in a wider development context, in which we take into consideration organizational factors and international distortions when defining our cost estimation functions, such as coordination between development team members, development phases, criteria selection and prioritization, product release and customer feedback [BBS11, MBF12, BWW + 18].

TABLE OF OBJECTIVES

CHAPTER 1 INTRODUCTION 1 . 1 2 1. 2 7 1. 5

 1112275 Contents Context and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organization of the Dissertation . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 1 . 1 :

 11 Figure 1.1: Main interfaces of the running example variants

2 . 3 . 4 . 5 .

 2345 Domain requirements engineering : collect and document common and variable requirements of the SPL. Domain design: define the architecture of the SPL that provides a high-level structure of all the products by means of a variability model. Domain realization: design and implement the reusable software components. Domain testing: validate the reusable components and verify the implementation of the requirements that they are supposed to implement.

Figure 2 . 2 :

 22 Figure 2.2: Software Product Line Engineering Framework [PBV05]

Figure 2 . 3 :

 23 Figure 2.3: Costs for developing n kinds of systems as single systems compared to product line engineering [PBV05]

Figure 2 . 4 :

 24 Figure 2.4: Time to market with and without product line engineering [PBV05]

Figure 2 . 5 :

 25 Figure 2.5: Negative and positive variability [VG07]

Figure 2 . 6 :

 26 Figure 2.6: A sample feature model and a configuration [BSRC10]

Figure 3 . 1 :

 31 Figure 3.1: Relevant activities during extractive SPL adoption for leveraging artefact variants [Mar16]

[ AG06 ]

 AG06 Martinez et al. developed a framework for extractive SPL adoption called BUT4Reuse that stands for Bottom-Up Technologies for Reuse [MZB + 17, Mar16, MZB + 16, MZB + 15b, MZB + 15a, MZKLT14, MZM + 14]. The framework achieves the process presented in Figure 3.1.

Figure 3 . 2 :

 32 Figure 3.2: Word clouds visualization functionality for feature naming [Mar16]

  location techniques were conducted by Rubin and Chechik [RC13b], Dit et al. [DRGP13] and Assunção et al. [AV14] representing and comparing the different techniques available in the domain.

OBJECTIVE 10 :

 10 CAPTURING FEATURES INTERACTIONSRubin et al. proposed a merge-refactoring framework for managing cloned product variants [RC12, RKBC12, RC13a, RCC13]. They highlighted on the necessity of representing the implemented functionalities of the product variants as features and they identified a set of operators to manage and maintain such products either by sharing features between them or by representing them in an SPL.

Figure 3 . 3 :

 33 Figure 3.3: The ECCO workflow [FLLHE15]

Figure 3 . 4 :

 34 Figure 3.4: The ECCO version control system workflow [Lin16]

Figure 3 . 5 :

 35 Figure 3.5: Challenges and objectives

Figure 3 . 6 :

 36 Figure 3.6: Approach overview

Figure 4 .

 4 Figure 4.1 summarizes the migration process of our approach. Existing PVs are migrated into an SPL by means of their provided artifacts and feature models. The SPL feature model is generated and correlations (mappings) between features and assets are identified. The generated FM allows the automated derivation of the integrated PVs.

Figure 4 . 1 :

 41 Figure 4.1: Migration process

1 .

 1 Structuring the SPL (a) Generating the SPL feature model (b) Extracting and storing products and assets 2. Identifying the correlations between features and assets

Example 1 :

 1 Product variants implementation files and feature modelsThe running example PVs with an excerpt of their corresponding implementation files and the FMs representing the features they implement are shown in Table4.1.

Listing 4 . 1 :

 41 Running example PVs FMs in FAMILIAR language fm_p1 = FM (ManageMatches: AddMatches ModifyMatches;) fm_p2 = FM (ManageMatches: AddMatches ModifyMatches DeleteMatches;) fm_p3 = FM (ManageMatches: AddMatches;) Listing 4.2: FAMILIAR merge operation over PVs FMs fm_spl = merge sunion fm * Listing 4.3: SPL FM generated from FAMILIAR merge operation fm_spl: (FEATURE_MODEL) ManageMatches: AddMatches [ModifyMatches] [DeleteMatches]; (DeleteMatches -> ModifyMatches);As shown in the figure below, the feature M anageM atches is the root feature. The feature AddM atches is mandatory, since it is implemented by all PVs, while the features M odif yM atches and DeleteM atches are optional since they are implemented in some but not all PVs. The constraint DeleteM atches ⇒ M odif yM atches is identified since each product implementing the feature DeleteM atches implements also the feature M odif yM atches.

Figure 4 . 2 :

 42 Figure 4.2: Running example SPL global FM

Figure 4 .

 4 Figure 4.3 shows the SPL model diagram. Algorithm 1 in Chapter 8 explains how the assets and their instances are extracted from the migrated PVs implementation files, and how the SPL products are identified.

Definition 4 . 3 . 2 (

 432 Feature to Asset Correlation) :A correlation between a feature f and an asset a noted as c(f, a) ∈ C holds, ifP (f ) ⊂ P (a) ∧ ∀a i ∈ AI(P (f )), a i / ∈ AI(P (a) \ P (f )) Definition 4.3.3 (Correlation Type) :We define two correlation types (CT): {equivalence, implication}, where the type t of a correlation is noted as t(c(f, a)). A correlation c(f, a) is an equivalence (noted f ⇔ a) if P (f ) = P (a), otherwise it is an implication (noted f ⇒ a).

3 Figure 4 . 4 :

 344 Figure 4.4: Examples of feature to asset correlation

Figure 4 .

 4 Figure 4.5 shows the correlations model diagram.

Figure 4 . 5 :

 45 Figure 4.5: Correlations model diagram

Example 5 :

 5 Running example feature to asset instance correlationsAs shown in Example 4, the correlation c(M odif yM atches, SaveM atch) holds. Consequently, the correlation c(M odif yM atches, SaveM atch 1 ) holds, since SaveM atch 1 is exploited by p 1 and p 2 that implement M odif yM atches. In contrary, the correlation c(M odif yM atches, SaveM atch 2 ) does not hold, since the product p 3 exploiting SaveM atch 2 does not implement M odif yM atches. The correlations between the features and the asset instances of the running example are shown in Table4.4.

( a )

 a Figure 5.1: Derivation process

Figure 5 . 2 :

 52 Figure 5.2: An SPL example

Figure 5 . 3 :

 53 Figure 5.3: Running example Restrictive and Free FMs

Figure 5 . 4 :

 54 Figure 5.4: Possible scenarios to achieve a configuration

Example 8 :

 8 Running example configuration of a new productGiven the products of the running example and their corresponding features as shown in Table1.1. Let cf 4 a new configuration, where EF (cf 4 ) = {M anageM atches, AddM atches, DeleteM atches} and N F (cf 4 ) = {φ}. No product realizes cf 4 , however, several configuration scenarios are possible: -cs 1 (cf 4 ) = { p 2 , {M odif yM atches} }, {φ} (restriction) -cs 2 (cf 4 ) = { p 1 , {M odif yM atches} , p 2 , {M odif yM atches} }, {φ} (restrictive composition) -cs 3 (cf 4 ) = { p 2 , {M odif yM atches} , p 3 , {φ} }, {φ} (restrictive composition) -cs 4 (cf 4 ) = { p 1 , {M odif yM atches} , p 2 , {M odif yM atches} , p 3 , {φ} }, {φ} (restrictive composition)

Figure 7 . 1 :

 71 Figure 7.1: SPL evolution process.

Figure 7 . 2 :

 72 Figure 7.2: Running example cf 4 derivation FM

Example 25 :

 25 FAMILIAR merge operation to re-generate SPL restrictive FM Below are the FMs of the running example SPL and product p 4 in FAMILIAR language. A FAMILIAR merge operation re-generates the SPL restrictive FM. Listing 7.1: Restrictive FM in FAMILIAR language before merge fm_spl = FM (ManageMatches: AddMatches [ModifyMatches] [DeleteMatches]; DeleteMatches -> ModifyMatches;) Listing 7.2: FM of product p 4 fm_p4 = FM (ManageMatches: AddMatches DeleteMatches;) Listing 7.3: FAMILIAR merge operation over SPL restrictive FM and FM of p 4 fm_spl = merge sunion fm_spl fm_p4 Listing 7.4: Re-generated restrictive FM from FAMILIAR merge operation fm_spl: (FEATURE_MODEL) ManageMatches: AddMatches [ModifyMatches] [DeleteMatches];

Algorithm 1

 1 Assets extraction and products definitionInput: P V {f iles} a set of Product Variants Output: A a set of Assets, P a set of Products 1: Initialize: A = {}, P = {} 2: for all pv ∈ P V do

5 :

 5 if ∃ (a ∈ A name(a) = name(f ile)) then

Algorithm 2 3 : 5 :

 235 Correlations identification Input: P Products of SPL, A Assets of SPL, F Features of SPL Output: C Correlations of SPL 1: Initialize: C = {} 2: for all a ∈ A do for all f ∈ F do 4: if [P (a) = P (f )] [P (a) ⊂ P (f ) ∧ ∀a i ∈ AI(P (f )), a i / ∈ AI(P (a) \ P (f ))] then new c(f, a) 6:

Figure 8 . 1 :Figure 8 . 2 :

 8182 Figure 8.1: An example of a configuration in restrictive mode

Figure 8 . 3 :

 83 Figure 8.3: Running example derivation process in SUCCEED

Figure 9 . 1 and

 91 Figure 9.1 and Figure 9.2 show some graphical interfaces of products p 7 and p 8 . Product p 7 corresponds to the Champions League 2016 competition, while product p 8 corresponds to EURO 2016 competition. Since feature M atches is implemented by both p 7 and p 8 , their corresponding interfaces look similar (see Figure 9.1a and Figure 9.2a). The interface displaying match details defers between p 7 and p 8 , since the former implements feature M atch f acts while

  (a) Matches interface of product p 7 (b) Match details interface of product p 7

Figure 9 . 1 :

 91 Figure 9.1: Case study graphical interfaces of product p 7

Figure 9 . 2 :Figure 9 10 . 1

 929101 Figure 9.2: Case study graphical interfaces of product p 8

O. 1

 1 Reuse in feature-oriented software development . . . . . . . . . . . . . . . . . . . O.2 Adopting clone-and-own as a starting point . . . . . . . . . . . . . . . . . . . . . O.3 Relying on software product line as a sustainable solution . . . . . . . . . . . . . O.4 Modeling variability through a feature model . . . . . . . . . . . . . . . . . . . . O.5 Combining clone-and-own and software product line . . . . . . . . . . . . . . . . O.6 Extractive migration approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . O.7 Business-level feature identification . . . . . . . . . . . . . . . . . . . . . . . . . O.8 Global mapping between features and assets . . . . . . . . . . . . . . . . . . . . . O.9 Language-independent mappings identification . . . . . . . . . . . . . . . . . . . O.10 Capturing features interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . O.11 Smooth migration in the accurate moment . . . . . . . . . . . . . . . . . . . . . . O.12 Supporting derivation with the possible scenarios . . . . . . . . . . . . . . . . . . O.13 Cost-estimated derivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . O.14 Software engineers as decision makers . . . . . . . . . . . . . . . . . . . . . . . . O.15 Reactive SPL evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . O.16 Incremental traceability between features and assets . . . . . . . . . . . . . . . . O.17 Allow a complete reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . O.18 Managing feature model evolution . . . . . . . . . . . . . . . . . . . . . . . . . .

Table 1 .

 1 1: Running example product variants with their corresponding features

	Product	Feature ManageMatches AddMatches ModifyMatches DeleteMatches
	p 1
	p 2
	p 3

Table

Table 1 .

 1 2: Running example product variants with an excerpt of their corresponding assets

	Product Asset version
		match.jsp 1
	p 1	SaveMatch.java 1
		style.css 1
		match.jsp 1
	p 2	SaveMatch.java 1 style.css 2
		DeleteMatch.java 1
		match.jsp 1
	p 3	SaveMatch.java 2
		style.css 3

  , PBV05].

	2.2. Clone-and-Own Approach	Chapter 2. Background
	OBJECTIVE 1:
	REUSE IN FEATURE-ORIENTED SOFTWARE DEVELOPMENT

Table 2 .

 2 1: A configuration space corresponding to the FM of Figure 2.6

	Configuration	Mobile Phone	Calls	GPS	Screen	Basic	Colour	High resolution	Media	Camera	MP3
	1
	2
	3
	4
	5
	6
	7
	8
	9
	10
	11
	12
	13
	14

  Summary and Contribution Choices . . . . . . . . . . . . . . . . . . . . . .

			RELATED WORK
	Contents
	3.1 Software Product Line Adoption . . . . . . . . . . . . . . . . . . . . . . . .
	3.1.1	Migration Approach . . . . . . . . . . . . . . . . . . . . . . . . .
	3.1.2	Migration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . .
		3.1.2.1	Identifying Features . . . . . . . . . . . . . . . . . . . .
		3.1.2.2	Mapping Features to Assets . . . . . . . . . . . . . . .
		3.1.2.3	Constructing a Feature Model . . . . . . . . . . . . . .
	3.1.3	Migration Moment . . . . . . . . . . . . . . . . . . . . . . . . . .
	3.2 Product Derivation Support . . . . . . . . . . . . . . . . . . . . . . . . . .
	3.3 Software Product Line Evolution . . . . . . . . . . . . . . . . . . . . . . .
	3.4

Table 3 .

 3 1: A comparison of the key characteristics of the main related work tools

	Tool

Table 4 . 1 :

 41 Running example product variants with their implementation files and feature models

	Product File version	Feature Model
		match.jsp 1
	p 1	SaveMatch.java 1
		style.css 1
		match.jsp 1
	p 2	SaveMatch.java 1 style.css 2
		DeleteMatch.java 1
		match.jsp 1
	p 3	SaveMatch.java 2
		style.css 3

Table 4 .

 4 2: Running example relationships between assets, asset instances and product variants

	Asset	Instance	Product p 1 p 2 p 3
	match.jsp	1
	SaveMatch.java	1 2
		1
	style.css	2
		3
	DeleteMatch.java	1

Figure 4.3: SPL model diagram

Table 4 .

 4 3: Correlations between features and assets of the running example

	Feature	CT Asset

ManageMatches ⇔ match.jsp AddMatches ⇔ match.jsp ManageMatches ⇔ SaveMatch.java AddMatches ⇔ SaveMatch.java ModifyMatches ⇒ SaveMatch.java ManageMatches ⇔ style.css AddMatches ⇔ style.css ModifyMatches ⇒ style.css DeleteMatches ⇒ style.css DeleteMatches ⇔ DeleteMatch.java

Table 4 .

 4 4: Correlations between features and asset instances of the running example

	Feature	Asset instance
	ManageMatches match.jsp 1
	AddMatches	match.jsp 1
	ManageMatches SaveMatch.java 1
	AddMatches	SaveMatch.java 1
	ModifyMatches SaveMatch.java 1
	ManageMatches SaveMatch.java 2
	AddMatches	SaveMatch.java 2
	ManageMatches style.css 1
	AddMatches	style.css 1
	ModifyMatches style.css 1
	ManageMatches style.css 2
	AddMatches	style.css 2
	ModifyMatches style.css 2
	DeleteMatches	style.css 2
	ManageMatches style.css 3
	AddMatches	style.css 3
	DeleteMatches	DeleteMatch.java 1
	Definition 4.3.5 (Asset correlated features) :

Table 4 .

 4

	5: Product variants with their corresponding features
	welcome news contact
	p x
	p y

Table 4 .

 4 6: Product variants with their corresponding asset instances

	Product Asset instance
	p x	index.html 1 news.html 1
		home.html 1
	p y	news.html 1
		contact.html 1

Table

Table 4 .

 4

	7: Correlations between features and assets
	Feature CT Asset
	welcome ⇔ news.html
	news	⇔ news.html
	contact	⇔ home.html
	contact	⇔ contact.html

Table 5 .

 5 1: Possible configuration scenarios of cf 4 with their possible operations Configuration scenario cs 1 (cf 4 ) = { p 2 , {M odif yM atches} }, {φ} Asset Operations match.jsp match.jsp, { CRT, match.jsp 1 , {φ} }, match.jsp 1 SaveM atch.java SaveM atch.java, { CRM, SaveM atch.java 1 , {M odif yM atches} }, SaveM atch.java 2 style.css style.css, { CRM, style.css 2 , {M odif yM atches} }, style.css DeleteM atch.java DeleteM atch.java, { CRT, DeleteM atch.java 1 , {φ} }, DeleteM atch.java 1 Configuration scenario cs 2 (cf 4 ) = { p 1 , {M odif yM atches} , p 2 , {M odif yM atches} }, {φ} Asset Operations match.jsp match.jsp, { CRT, match.jsp 1 , {φ} }, match.jsp 1 SaveM atch.java SaveM atch.java, { CRM, SaveM atch.java 1 , {M odif yM atches} }, SaveM atch.java 2 Configuration scenario cs 3 (cf 4 ) = { p 2 , {M odif yM atches} , p 3 , {φ} }, {φ} Configuration scenario cs 4 (cf 4 ) = { p 1 , {M odif yM atches} , p 2 , {M odif yM atches} , p 3 , {φ} }, {φ} Asset Operations match.jsp match.jsp, { CRT, match.jsp 1 , {φ} }, match.jsp 1 SaveM atch.java SaveM atch.java, { CRM, SaveM atch.java 1 , {M odif yM atches} }, SaveM atch.java 2 SaveM atch.java, { CRT, SaveM atch.java 2 , {φ} }, SaveM atch.java 2 style.css style.css, { CRM, style.css 1 , {M odif yM atches} , ET A, style.css 2 , {DeleteM atches} }, style.css 4

	Asset	Operations
	match.jsp	match.

style.css style.css, { CRM, style.css 1 , {M odif yM atches} , ET A, style.css 2 , {DeleteM atches} }, style.css 4 style.css, { CRM, style.css 2 , {M odif yM atches} }, style.css DeleteM atch.java DeleteM atch.java, { CRT, DeleteM atch.java 1 , {φ} }, DeleteM atch.java 1 jsp, { CRT, match.jsp 1 , {φ} }, match.jsp 1 SaveM atch.java SaveM atch.java, { CRM, SaveM atch.java 1 , {M odif yM atches} }, SaveM atch.java 2 SaveM atch.java, { CRT, SaveM atch.java 2 , {φ} }, SaveM atch.java 2 style.css style.css, { CRM, style.css 2 , {M odif yM atches} }, style.css style.css, { CRT, style.css 3 , {φ} , ET A, style.css 2 , {DeleteM atches} }, style.css 4 DeleteM atch.java DeleteM atch.java, { CRT, DeleteM atch.java 1 , {φ} }, DeleteM atch.java 1 style.css, { CRM, style.css 2 , {M odif yM atches} }, style.css style.css, { CRT, style.css 3 , {φ} , ET A, style.css 2 , {DeleteM atches} }, style.css 4 DeleteM atch.java DeleteM atch.java, { CRT, DeleteM atch.java 1 , {φ} }, DeleteM atch.java 1

Table 6 .

 6 1: Running example asset instance correlated features

	Asset Instance	|F (a i )|
	match.jsp 1	2
	SaveM atch.java 1	3
	SaveM atch.java 2	2
	style.css 1	3
	style.css 2	4
	style.css 3	2
	DeleteM atch.java 1	1

Table 6 .

 6 2: Running example feature correlated assets Example 13: Instances of assets from running example Referring to Table 1.2, we compute the number of instances of each asset of the running example: |AI(a)|. Example 14: Feature correlated asset instances from running example Referring to Table 4.4, we compute the number of instances of each asset correlated with each feature of the running example: |AI(f /a)|. Example 15: Correlation degrees from running example Referring to Table 4.4å and the examples listed above, we compute the correlation degrees between the running example features and asset instances.

	Feature	|A(f )|
	M anageM atches	3
	AddM atches	3
	M odif yM atches	2
	DeleteM atches	2
	Table 6.3: Running example instances of assets
	Asset	|AI(a)|
	match.jsp	1
	SaveM atch.java	2
	style.css	3
	DeleteM atch.java	1

Table 6 .

 6 5: Correlation degrees between features and asset instances of the running exampleReferring to Table6.5, we compute the estimated cost of the the running example actions of the configuration cf 4 .

	Feature	Asset instance	cd(f, a i )
	ManageMatches match.jsp 1	0.1666
	AddMatches	match.jsp 1	0.1666
	ManageMatches SaveMatch.java 1	0.1111
	AddMatches	SaveMatch.java 1	0.1111
	ModifyMatches SaveMatch.java 1	0.0833
	ManageMatches SaveMatch.java 2	0.1666
	AddMatches	SaveMatch.java 2	0.1666
	ManageMatches style.css 1	0.1111
	AddMatches	style.css 1	0.1111
	ModifyMatches style.css 1	0.1111
	ManageMatches style.css 2	0.0833
	AddMatches	style.css 2	0.0833
	ModifyMatches style.css 2	0.8333
	DeleteMatches	style.css 2	0.0416
	ManageMatches style.css 3	0.1666
	AddMatches	style.css 3	0.1666
	DeleteMatches	DeleteMatch.java 1 0.5000

Definition 6.2.4 (Operation cost) :

Table 6 .

 6 7: Configuration cf 4 operations estimated cost Operation cost(op) match.jsp, { CRT, match.jsp 1 , {φ} }, match.jsp 1 0.0000 SaveM atch.java, { CRM, SaveM atch.java 1 , {M odif yM atches} }, SaveM atch.java 2 0.0833 SaveM atch.java, { CRT, SaveM atch.java 2 , {φ} }, SaveM atch.java 2 0.0000 style.css, { CRM, style.css 1 , {M odif yM atches} , ET A, style.css 2 , {DeleteM atches} }, style.css 4 0.1736 style.css, { CRM, style.css 2 , {M odif yM atches} }, style.css 4 0.0833 style.css, { CRT, style.css 3 , {φ} , ET A, style.css 2 , {DeleteM atches} }, style.css 4

0.0625 DeleteM atch.java, { CRT, DeleteM atch.java 1 , {φ} }, DeleteM atch.java 1 0.0000

Table 7 .

 7 1: Product p 4 asset instances

	Product Asset version
		match.jsp 1
	p 4	SaveMatch.java 1 style.css 4
		DeleteMatch.java 1
	7.3.2 Feature Models Re-generation

Table 7 .

 7 2: Added correlations after integration of product p 4

	Feature	Asset instance
	ManageMatches style.css 4
	AddMatches	style.css 4
	DeleteMatches	style.css 4

Table 7 .

 7

	3: Updated running example asset instance correlated features after integration of
	product p 4
	Asset Instance	|F (a i )|
	match.jsp 1	2
	SaveM atch.java 1	3
	SaveM atch.java 2	2
	style.css 1	3
	style.css 2	4
	style.css 3	2
	style.css

Table 7 .

 7 4: Updated running example instances of assets after integration of product p 4

	Asset	|AI(a)|
	match.jsp	1
	SaveM atch.java	2
	style.css	4
	DeleteM atch.java	1

Table 7 .

 7 5: Updated running example features correlated asset instances after integration of product p 4

	Feature	Asset	|AI(f /a)|
	M anageM atches match.jsp	1
	AddM atches	match.jsp	1
	M anageM atches SaveM atch.java	2
	AddM atches	SaveM atch.java	2
	M odif yM atches SaveM atch.java	1
	ManageMatches style.css	4
	AddMatches	style.css	4
	M odif yM atches style.css	2
	DeleteMatches	style.css	2
	DeleteM atches	DeleteM atch.java	1

Table 7 .

 7 6: Updated correlation degrees between features and asset instances of the running example after integrating product p 4

	Feature	Asset instance	cd(f, a i )
	ManageMatches match.jsp 1	0.1666
	AddMatches	match.jsp 1	0.1666
	ManageMatches SaveMatch.java 1	0.1111
	AddMatches	SaveMatch.java 1	0.1111
	ModifyMatches	SaveMatch.java 1	0.0833
	ManageMatches SaveMatch.java 2	0.1666
	AddMatches	SaveMatch.java 2	0.1666
	ManageMatches style.css 1	0.1111
	AddMatches	style.css 1	0.1111
	ModifyMatches style.css 1	0.0833
	ManageMatches style.css 2	0.0833
	AddMatches	style.css 2	0.0833
	ModifyMatches style.css 2	0.0625
	DeleteMatches	style.css 2	0.0625
	ManageMatches style.css 3	0.1666
	AddMatches	style.css 3	0.1666
	ManageMatches style.css 4	0.1111
	AddMatches	style.css 4	0.1111
	DeleteMatches	style.css 4	0.0833
	DeleteMatches	DeleteMatch.java 1 0.5000

Table 9 . 1 :

 91 Metrics of 5 sequential configurations to derive new PVs Configuration cf 4 cf 5 cf 6 cf 7 cf 8

	Number of features added by the configuration	0	0 25	0	0
	Number of Assets added after derivation	0	0	8	0 24
	Number of Asset instances added after derivation	3	1 11	1 25

Table 9 .

 9 2: Main features of case study product variants Features Products p 1 p 2 p 3 p 4 p 5 p 6 p 7 p 8

	Competition
	Matches
	Rounds
	Teams
	Players
	News
	Match facts
	Match stats

The implementation files of the PVs of the running example are available on the following git repository link: https://github.com/eddyghabachi3s/SoccerManager

1.3. Challenges Chapter 1. Introduction

1.5. Organization of the Dissertation Chapter 1. Introduction

2.1. Software Reuse Chapter 2. Background

2.3. Software Product Lines Chapter 2. Background

2.4. Summary and Contribution DecisionsChapter 2. Background

Correlation: a mutual relationship or connection between two or more things (Oxford Dictionary)

The case study products do not correspond to the running examples products, which were demonstrated throughout the dissertation.

9.5. Summary Chapter 9. Approach Validation (a) Matches interface of product p 8

9.5. Summary Chapter 9. Approach Validation (b) Match details interface of product p 8

10.1. Conclusion Chapter 10. Conclusion and Perspectives

10.2. Perspectives Chapter 10. Conclusion and Perspectives

. I also thank my colleagues, Cécile Camilleri who gave me access to Rockflows framework, Philippe Collet and Sebastien Mosser who provided me with theirs advises. Thanks to Franjieh El Khoury, who supported me with her guidance and knowledge, reviewed my work, and encouraged me throughout my research period, and Badih Baz, who supported me and believed in my capabilities. Thanks for the National Center for Scientific Research in Lebanon (CNRS-L) and the PHC Cedre Program doctoral scholarships.

Thanks to the jury members for their precious opinions and for everyone reading this dissertation.

LIST OF ABBREVIATIONS