• Aucun résultat trouvé

T

he general goal of this thesis is to support re-engineering product variants into SPLs. Towards that goal, we studied the problem of finding traceability links between features and their imple-menting source code elements in context of product variants. Then, we addressed how to use such traceability links for the following tasks concerning that goal.

1. Supporting change impact analysis at feature level.

2. Contributing to build Software Product Line Architecture (SPLA).

Traceability links between features and their implementing source code elements are essential for understanding source code of product variants, and then reusing features (resp. their implementa-tions) for developing new products taking advantage of SPLE. Such traceability is also necessary for facilitating and automating new product derivation from SPL’s core assets when the re-engineering process is completed. Information Retrieval (IR) techniques are used widely for identifying such traceability links. These techniques deal with product variants as separated and independent enti-ties. However, commonality and variability across product variant should be exploited to improve the process of finding such traceability links.

The implementing source code elements of features obtained from product variants may need to be changed for adapting SPLE context by adding or removing requirements (resp. their source code elements) to meet new needs of customers. In this case, feature-level Change Impact Analysis (CIA) is needed to determine feature(s) that may be impacted for a given change proposal before the change is implemented. It is helpful to conduct change management from a SPL manager’s point of view for economic consideration related to the re-engineering process. Feature-level CIA is seldom

135

136 Chap 8. Conclusion and Future Work

considered. Most survey approaches performs CIA at the source code level with a few approaches completed at requirement and design levels.

The development of SPLA from scratch is a costly task because it represents an infrastructure to derive components not only for one architecture but also for all architectures of SPL’s products. As a result, existing product variants should be reused as much as possible to support reverse engineer-ing SPLA by extractengineer-ing components and organizengineer-ing these components as mandatory and members of variation points. This organization represents an important step toward this reverse-engineering task. In the literature, reverse engineering SPLA from product variants has not been considered and surveyed approaches follow forward engineering way for SPLA development.

8.1 Summary of Contributions

To summarize, the contributions of this thesis are as follows:

IR-feature location in a collection of product variants

We proposed an approach to locate feature implementations in a collection of product variants.

The proposed approach is based on IR. In the approach, we improved the effectiveness of IR-feature location by: (i) reducing IR search spaces (IR-feature and source code spaces) where IR are applied. This is performed by analyzing commonality and variability across product variants using formal concept analysis. (ii) reducing the abstraction gap between feature and source code levels. This is performed by introducing the concept of code-topic as an intermediate level. In our experimental evaluation, we showed that our approach outperforms the conven-tional application of IR as well as the most recent and relevant work on the subject, in terms of the widely used metrics for evaluation:precision, recallandF-measure.

Feature-level change impact analysis: based on feature location

We proposed an approach for studying the impact of changes made to the source code of fea-tures obtained from product variants based on formal concept analysis. This approach helps to conduct change management from a SPL’s manager point of view, as the feature is an agreement among all stakeholders (including managers) about what the system should do. This allows a SPL’s manager to decide which change strategy should be executed, as there is often more than one change that can solve the same problem. Two metrics are suggested for such change man-agement: IDM and CAM. The former is used to measure the degree to which a given feature can be affected. The latter is used to compute the changeability of all features obtained from product variants. Our approach mainly leverages the identified traceability links between fea-ture and source code classes to detect and study change impact at the feafea-ture level for changes made at the source code level. Such traceability links propagate the impact of source code changes at the feature level to be studied on that level. In our experimental evaluation, we proved the effectiveness of our approach in terms of the most commonly used metrics on the subject (precision, recallandF-measure).

Toward reverse engineering SPLA from product variants: based on feature location

We proposed an approach towards for reverse engineering Software Product Line Architec-ture (SPLA) from product variants. In this reverse engineering task, we focused on

identify-8.2. Direct Perspectives 137

ing mandatory components and variation points of components as an important step toward this architecture. This organization of components represents the commonality and variabil-ity in SPLA, which is driven by commonalvariabil-ity and variabilvariabil-ity at the feature level. Our proposed approach represents the second application of feature location that help us to determine the implementation of feature groups from where components are extracted. Also based on fea-ture location, we established traceability links between feafea-tures and extracted components to bind variability at the architecture level (SPLA). We proposed a set of algorithms to determine this commonality and variability in terms of features of a given set of product configurations.

According to the experimental evaluation, the efficiency of these algorithms mainly depends on the available product configurations and feature descriptions. If we have a large number of configurations with high diversity and precise feature descriptions, our approach achieves high precision and recall of identified mandatory features (commonality) and variation points of features (variability), and hence this leads to identify relevant mandatory components and variation point of components.

8.2 Direct Perspectives

In this section, we discuss some possible extensions of our current work and issues that are not han-dled.

Experiments with large number of case studies:

The performance of our proposed approaches depends on the availability of well-documented product variants in terms of feature descriptions and truth ground links between features and their implementing source code elements, which are difficult to collect. Thus, we plan to extend our evaluation by conducting more experiments to better test our approaches.

Supporting different granularities of source code:

In our work, we assume that a feature is implemented at source code level by classes. However, a feature can be implemented by different low source code granularities (such as, methods, statement), especially in case of small-scale systems. Thus, we plan to extend our approaches to work on granularity below class level, e.g. methods.

Extracting feature model:

We plan to extend our proposed algorithms to identify commonality and variability in terms of features across product variants in order to extract feature models. The current algorithms de-termine only mandatory features and feature groups but we need to dede-termine the hierarchical organization of these features to extract the feature model.

Feature interactions:

“A feature interaction is a situation in which the composition of multiple feature implementa-tions leads to emergent behavior that does not occur when one of them is absent” [Apelet al., 2011]. The emergent behavior can be undesirable and cause failures in SPLs. Feature inter-actions occur during the product derivation process to combine different features together for generating SPLs. We plan to detect undesired feature interactions during product derivation process.

138 Chap 8. Conclusion and Future Work